5月安卓手機好評榜：魅族20 Pro奪冠
性能榜和性價比榜之后，我們來看最后的安卓手機好評榜，數據來源安兔兔評測，收集時間2023年5月1日至5月31日，僅限國內市場。第一名：魅族20 Pro好評率：97.50%不得不感慨魅族老品牌還
現在有一個架構圖如下所示：
圖片
在這種情況下，咱們的數據庫仍然是單機部署。根據一些云廠商的基準測試結果，使用4核8GB的機器運行MySQL 5.7時，大約可以支持每秒500個事務（TPS）和每秒10,000個查詢（QPS）。然而，現在運營團隊正在準備雙十一活動，并且公司計劃在全渠道推廣中繼續投資，這顯然會導致查詢量突然增加的問題。因此，今天我們將探討如何通過主從分離來應對查詢請求的增加。
實際上，許多系統都面臨著讀取操作遠多于寫入操作的情況，讀寫請求的數量差距可能達到幾個數量級。
這并不難理解，因為瀏覽朋友圈的請求肯定比發布朋友圈的請求多，而在線商店中，一個商品的瀏覽量肯定遠遠超過下單量。因此，我們首先考慮如何使數據庫能夠處理更多的查詢請求，而為此，首先需要將讀取流量和寫入流量分開，這就是我們所說的主從讀寫分離。
實際上，這是一種流量分流的策略，可以將其比作道路交通控制，其中一個有四個車道的主干道中有三個車道供領導和外賓使用，而另一個車道供一般市民使用，以確保領導和外賓能夠優先通過。這個策略是一種常規做法，即使在大型項目中，也是應對數據庫突發讀取流量增加的有效方法。
在我目前的項目中，我們曾經遇到前端流量突然增加導致從數據庫副本負載過高的問題，數據庫管理員首先擴展了從數據庫，這樣讀取流量就分散到多個從數據庫上，從而降低了從數據庫的負載。接下來，開發團隊再考慮如何在數據庫層之上采取措施來處理這一流量。
通常，在主從讀寫分離機制中，我們復制一個數據庫的數據到一個或多個其他數據庫服務器上，并將原始數據庫稱為主庫，其主要任務是處理數據寫入操作，而復制到的目標數據庫稱為從庫，主要用于支持數據查詢操作。主從讀寫分離涉及兩個關鍵技術點：首先，數據的拷貝，這稱為主從復制；其次，在主從分離的情況下，如何屏蔽應用訪問數據庫時的變化，以使開發人員感覺就像在使用單一數據庫一樣。
讓我用不同的表達方式來解釋MySQL的主從復制過程。MySQL的主從復制是依賴于二進制日志（binlog）的技術。二進制日志記錄了MySQL上的所有數據變化，并以二進制形式保存在磁盤上的日志文件中。主從復制的目標是將主庫中的binlog數據傳輸到從庫上，通常這個過程是異步的，也就是說，主庫上的操作不需要等待binlog同步完成。
主從復制的過程如下：首先，從庫連接到主庫時會創建一個I/O線程，用于請求主庫上的binlog數據，并將接收到的binlog信息寫入一個名為"relay log"的日志文件中。與此同時，主庫也會創建一個"log dump"線程來將binlog數據發送給從庫。此外，從庫還會創建一個SQL線程，用于讀取"relay log"中的內容，并在從庫上進行回放，從而實現主從庫的數據一致性。
這種主從復制方式的優點在于，它使用了獨立的"log dump"線程，這是一種異步方式，避免了對主庫的主要數據更新流程產生影響。此外，從庫在接收到binlog信息后，并不會直接寫入從庫的實際存儲中，而是將數據寫入"relay log"，這可以避免寫入從庫存儲的延遲，從而減少主從庫之間的數據同步延遲。
圖片
主從復制是一種在性能考慮下實現的數據庫同步機制，其中主庫負責數據寫入，而從庫負責數據讀取。主庫的寫入操作通常不會等待主從同步完成就返回結果，這意味著在極端情況下，如主庫上的binlog數據還未來得及刷新到磁盤時發生磁盤損壞或機器掉電，可能會導致binlog數據丟失，進而引起主從數據不一致的問題。盡管這種情況出現的概率很低，對于互聯網項目來說是可以接受的。
一旦進行了主從復制，就可以實現寫請求只寫主庫，讀請求只讀從庫的策略。這意味著即使寫請求鎖定了表或記錄，也不會影響讀請求的執行。此外，在讀流量較大的情況下，可以部署多個從庫來共同處理讀流量，這被稱為"一主多從"部署方式，可以用來應對高并發讀取流量，比如在您的垂直電商項目中。
此外，從庫還可以用作備份庫，以防止主庫發生故障導致數據丟失。然而，需要注意的是，增加從庫的數量并不是無限制的，因為隨著從庫數量的增加，主庫需要處理更多的IO線程和log dump線程，這可能會對主庫的資源消耗和網絡帶寬造成影響。通常情況下，一個主庫最多可以連接3到5個從庫。
盡管主從復制提供了許多好處，例如負載均衡和容錯性，但它也有一些缺點，包括引入部署復雜性和可能導致主從同步延遲。這種延遲有時會對某些業務產生影響，例如在微博發布中，主從同步延遲可能會影響后續異步操作的正常流程，如將微博信息發送給審核系統。
圖片
這個問題解決的思路有很多，核心思想就是盡量不去從庫中查詢信息，純粹以上面的例子來說，我就有三種解決方案：
最終，我會傾向于選擇數據冗余方案，因為它相對簡單，但可能會導致消息的大小增加以及消息傳輸的帶寬和時間成本的增加。緩存方案適用于新增數據的情況，但需要小心處理數據一致性。查詢主庫方案是一種可行的備選方案，但需要謹慎使用以避免對主庫造成過大的壓力。
主從同步延遲是一個容易被忽略的問題，特別在排查問題時。有時候，當我們遇到從數據庫中無法獲取信息的奇怪問題時，我們可能會首先懷疑代碼中是否有一些邏輯會導致數據被刪除。但隨著時間的推移，我們又發現之前丟失的數據突然又能夠查詢到，這通常是主從同步延遲導致的問題。因此，我們通常將從庫的數據落后時間作為一個關鍵的數據庫性能指標來監控和設置警報。正常情況下，數據同步延遲應該在毫秒級別，一旦延遲達到秒級別，就需要觸發警報，以及時發現和解決潛在的問題。
第一類中間件，以淘寶的TDDL（Taobao Distributed Data Layer）為代表，通常以代碼形式嵌入到應用程序內部運行。可以將它視為數據源的代理，它管理著多個數據源，每個數據源對應一個數據庫，可以是主庫也可以是從庫。當應用程序發起數據庫請求時，這種中間件會將SQL語句路由到特定的數據源進行處理，然后返回處理結果。
這種中間件的優點在于它的簡單和易用，而且沒有額外的部署成本，因為它與應用程序一起運行，適合運維能力較弱的小團隊使用。然而，它的缺點在于缺乏多語言支持。目前，這類主流解決方案如TDDL和早期的網易DDB，它們都是用Java開發的，無法支持其他編程語言。另外，版本升級也需要使用方主動更新，相對較為困難。
第二類中間件方案是單獨部署的代理層，代表性的有早期的阿里巴巴開源項目Cobar、基于Cobar開發的Mycat、360開源的Atlas，以及美團開源的基于Atlas開發的DBProxy等等。這些中間件獨立部署在專用服務器上，業務代碼可以像使用單一數據庫一樣與它交互，盡管實際上它內部管理著多個數據源。當應用程序發起數據庫請求時，這些中間件會對SQL語句進行必要的改寫，然后將其發送到指定的數據源。它們通常使用標準的MySQL通信協議，因此可以很好地支持多種編程語言。
由于這些中間件是獨立部署的，因此比較容易進行維護和升級，適合具有一定運維能力的大中型團隊使用。然而，它們的缺點在于所有SQL語句需要跨越兩次網絡：從應用到代理層，然后從代理層到數據源，因此在性能方面可能會有一些損耗。
圖片
這些中間件，對你而言，可能并不陌生，但是我想讓你注意到是，在使用任何中間件的時候一定要保證對于中間件有足夠深入的了解，否則一旦出了問題沒法快速地解決就悲劇了。
需要明確的要點主要有：
這種思想和技術在許多存儲組件中都有應用，如Redis使用主從復制實現讀寫分離，Elasticsearch中的索引分片可以被復制到多個節點，HDFS中的文件會被復制到多個DataNode。盡管不同組件對復制的一致性和延遲要求不同，但這種設計思想是通用的，對于理解和學習其他存儲組件非常有幫助。
本文鏈接：http://www.tebozhan.com/showinfo-26-15484-0.html并發的查詢請求增加時，數據架構部分如何做主從分離？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號