現(xiàn)在有一個(gè)架構(gòu)圖如下所示：

圖片

在這種情況下，咱們的數(shù)據(jù)庫仍然是單機(jī)部署。根據(jù)一些云廠商的基準(zhǔn)測試結(jié)果，使用4核8GB的機(jī)器運(yùn)行MySQL 5.7時(shí)，大約可以支持每秒500個(gè)事務(wù)（TPS）和每秒10,000個(gè)查詢（QPS）。然而，現(xiàn)在運(yùn)營團(tuán)隊(duì)正在準(zhǔn)備雙十一活動，并且公司計(jì)劃在全渠道推廣中繼續(xù)投資，這顯然會導(dǎo)致查詢量突然增加的問題。因此，今天我們將探討如何通過主從分離來應(yīng)對查詢請求的增加。

主從讀寫分離

實(shí)際上，許多系統(tǒng)都面臨著讀取操作遠(yuǎn)多于寫入操作的情況，讀寫請求的數(shù)量差距可能達(dá)到幾個(gè)數(shù)量級。

這并不難理解，因?yàn)闉g覽朋友圈的請求肯定比發(fā)布朋友圈的請求多，而在線商店中，一個(gè)商品的瀏覽量肯定遠(yuǎn)遠(yuǎn)超過下單量。因此，我們首先考慮如何使數(shù)據(jù)庫能夠處理更多的查詢請求，而為此，首先需要將讀取流量和寫入流量分開，這就是我們所說的主從讀寫分離。

實(shí)際上，這是一種流量分流的策略，可以將其比作道路交通控制，其中一個(gè)有四個(gè)車道的主干道中有三個(gè)車道供領(lǐng)導(dǎo)和外賓使用，而另一個(gè)車道供一般市民使用，以確保領(lǐng)導(dǎo)和外賓能夠優(yōu)先通過。這個(gè)策略是一種常規(guī)做法，即使在大型項(xiàng)目中，也是應(yīng)對數(shù)據(jù)庫突發(fā)讀取流量增加的有效方法。

在我目前的項(xiàng)目中，我們曾經(jīng)遇到前端流量突然增加導(dǎo)致從數(shù)據(jù)庫副本負(fù)載過高的問題，數(shù)據(jù)庫管理員首先擴(kuò)展了從數(shù)據(jù)庫，這樣讀取流量就分散到多個(gè)從數(shù)據(jù)庫上，從而降低了從數(shù)據(jù)庫的負(fù)載。接下來，開發(fā)團(tuán)隊(duì)再考慮如何在數(shù)據(jù)庫層之上采取措施來處理這一流量。

主從讀寫的兩個(gè)技術(shù)關(guān)鍵點(diǎn)

通常，在主從讀寫分離機(jī)制中，我們復(fù)制一個(gè)數(shù)據(jù)庫的數(shù)據(jù)到一個(gè)或多個(gè)其他數(shù)據(jù)庫服務(wù)器上，并將原始數(shù)據(jù)庫稱為主庫，其主要任務(wù)是處理數(shù)據(jù)寫入操作，而復(fù)制到的目標(biāo)數(shù)據(jù)庫稱為從庫，主要用于支持?jǐn)?shù)據(jù)查詢操作。主從讀寫分離涉及兩個(gè)關(guān)鍵技術(shù)點(diǎn)：首先，數(shù)據(jù)的拷貝，這稱為主從復(fù)制；其次，在主從分離的情況下，如何屏蔽應(yīng)用訪問數(shù)據(jù)庫時(shí)的變化，以使開發(fā)人員感覺就像在使用單一數(shù)據(jù)庫一樣。

1. 主從復(fù)制

讓我用不同的表達(dá)方式來解釋MySQL的主從復(fù)制過程。MySQL的主從復(fù)制是依賴于二進(jìn)制日志（binlog）的技術(shù)。二進(jìn)制日志記錄了MySQL上的所有數(shù)據(jù)變化，并以二進(jìn)制形式保存在磁盤上的日志文件中。主從復(fù)制的目標(biāo)是將主庫中的binlog數(shù)據(jù)傳輸?shù)綇膸焐?，通常這個(gè)過程是異步的，也就是說，主庫上的操作不需要等待binlog同步完成。

主從復(fù)制的過程如下：首先，從庫連接到主庫時(shí)會創(chuàng)建一個(gè)I/O線程，用于請求主庫上的binlog數(shù)據(jù)，并將接收到的binlog信息寫入一個(gè)名為"relay log"的日志文件中。與此同時(shí)，主庫也會創(chuàng)建一個(gè)"log dump"線程來將binlog數(shù)據(jù)發(fā)送給從庫。此外，從庫還會創(chuàng)建一個(gè)SQL線程，用于讀取"relay log"中的內(nèi)容，并在從庫上進(jìn)行回放，從而實(shí)現(xiàn)主從庫的數(shù)據(jù)一致性。

這種主從復(fù)制方式的優(yōu)點(diǎn)在于，它使用了獨(dú)立的"log dump"線程，這是一種異步方式，避免了對主庫的主要數(shù)據(jù)更新流程產(chǎn)生影響。此外，從庫在接收到binlog信息后，并不會直接寫入從庫的實(shí)際存儲中，而是將數(shù)據(jù)寫入"relay log"，這可以避免寫入從庫存儲的延遲，從而減少主從庫之間的數(shù)據(jù)同步延遲。

圖片

主從復(fù)制是一種在性能考慮下實(shí)現(xiàn)的數(shù)據(jù)庫同步機(jī)制，其中主庫負(fù)責(zé)數(shù)據(jù)寫入，而從庫負(fù)責(zé)數(shù)據(jù)讀取。主庫的寫入操作通常不會等待主從同步完成就返回結(jié)果，這意味著在極端情況下，如主庫上的binlog數(shù)據(jù)還未來得及刷新到磁盤時(shí)發(fā)生磁盤損壞或機(jī)器掉電，可能會導(dǎo)致binlog數(shù)據(jù)丟失，進(jìn)而引起主從數(shù)據(jù)不一致的問題。盡管這種情況出現(xiàn)的概率很低，對于互聯(lián)網(wǎng)項(xiàng)目來說是可以接受的。

一旦進(jìn)行了主從復(fù)制，就可以實(shí)現(xiàn)寫請求只寫主庫，讀請求只讀從庫的策略。這意味著即使寫請求鎖定了表或記錄，也不會影響讀請求的執(zhí)行。此外，在讀流量較大的情況下，可以部署多個(gè)從庫來共同處理讀流量，這被稱為"一主多從"部署方式，可以用來應(yīng)對高并發(fā)讀取流量，比如在您的垂直電商項(xiàng)目中。

此外，從庫還可以用作備份庫，以防止主庫發(fā)生故障導(dǎo)致數(shù)據(jù)丟失。然而，需要注意的是，增加從庫的數(shù)量并不是無限制的，因?yàn)殡S著從庫數(shù)量的增加，主庫需要處理更多的IO線程和log dump線程，這可能會對主庫的資源消耗和網(wǎng)絡(luò)帶寬造成影響。通常情況下，一個(gè)主庫最多可以連接3到5個(gè)從庫。

盡管主從復(fù)制提供了許多好處，例如負(fù)載均衡和容錯(cuò)性，但它也有一些缺點(diǎn)，包括引入部署復(fù)雜性和可能導(dǎo)致主從同步延遲。這種延遲有時(shí)會對某些業(yè)務(wù)產(chǎn)生影響，例如在微博發(fā)布中，主從同步延遲可能會影響后續(xù)異步操作的正常流程，如將微博信息發(fā)送給審核系統(tǒng)。

圖片

這個(gè)問題解決的思路有很多，核心思想就是盡量不去從庫中查詢信息，純粹以上面的例子來說，我就有三種解決方案：

1. 數(shù)據(jù)冗余方案： 在將消息發(fā)送到消息隊(duì)列時(shí)，不僅發(fā)送微博ID，還將隊(duì)列處理機(jī)所需的完整微博信息一并發(fā)送，以避免從數(shù)據(jù)庫重新查詢數(shù)據(jù)。這可以確保數(shù)據(jù)一致性，但可能會增加單條消息的大小，從而增加消息傳輸?shù)膸捄蜁r(shí)間成本。
2. 緩存方案： 同步寫入數(shù)據(jù)庫的同時(shí)，將微博數(shù)據(jù)寫入Memcached緩存。這樣，隊(duì)列處理機(jī)在獲取微博信息時(shí)首先嘗試從緩存中獲取，以提高查詢速度和減輕數(shù)據(jù)庫負(fù)擔(dān)。這種方法特別適用于新增數(shù)據(jù)的場景，但在更新數(shù)據(jù)時(shí)需要小心，因?yàn)橥瑫r(shí)更新緩存和數(shù)據(jù)庫可能導(dǎo)致數(shù)據(jù)不一致，特別是在并發(fā)更新時(shí)。
3. 查詢主庫方案： 在隊(duì)列處理機(jī)中直接查詢主庫而不是從庫。這是一種可行的方法，但需要謹(jǐn)慎使用，因?yàn)槿绻樵兞亢艽?，可能會給主庫帶來過大的壓力。這種方式適用于查詢量較小且在主庫負(fù)載可承受范圍內(nèi)的情況。

最終，我會傾向于選擇數(shù)據(jù)冗余方案，因?yàn)樗鄬唵?，但可能會?dǎo)致消息的大小增加以及消息傳輸?shù)膸捄蜁r(shí)間成本的增加。緩存方案適用于新增數(shù)據(jù)的情況，但需要小心處理數(shù)據(jù)一致性。查詢主庫方案是一種可行的備選方案，但需要謹(jǐn)慎使用以避免對主庫造成過大的壓力。

主從同步延遲是一個(gè)容易被忽略的問題，特別在排查問題時(shí)。有時(shí)候，當(dāng)我們遇到從數(shù)據(jù)庫中無法獲取信息的奇怪問題時(shí)，我們可能會首先懷疑代碼中是否有一些邏輯會導(dǎo)致數(shù)據(jù)被刪除。但隨著時(shí)間的推移，我們又發(fā)現(xiàn)之前丟失的數(shù)據(jù)突然又能夠查詢到，這通常是主從同步延遲導(dǎo)致的問題。因此，我們通常將從庫的數(shù)據(jù)落后時(shí)間作為一個(gè)關(guān)鍵的數(shù)據(jù)庫性能指標(biāo)來監(jiān)控和設(shè)置警報(bào)。正常情況下，數(shù)據(jù)同步延遲應(yīng)該在毫秒級別，一旦延遲達(dá)到秒級別，就需要觸發(fā)警報(bào)，以及時(shí)發(fā)現(xiàn)和解決潛在的問題。

2. 如何訪問數(shù)據(jù)庫

第一類中間件，以淘寶的TDDL（Taobao Distributed Data Layer）為代表，通常以代碼形式嵌入到應(yīng)用程序內(nèi)部運(yùn)行?？梢詫⑺暈閿?shù)據(jù)源的代理，它管理著多個(gè)數(shù)據(jù)源，每個(gè)數(shù)據(jù)源對應(yīng)一個(gè)數(shù)據(jù)庫，可以是主庫也可以是從庫。當(dāng)應(yīng)用程序發(fā)起數(shù)據(jù)庫請求時(shí)，這種中間件會將SQL語句路由到特定的數(shù)據(jù)源進(jìn)行處理，然后返回處理結(jié)果。

這種中間件的優(yōu)點(diǎn)在于它的簡單和易用，而且沒有額外的部署成本，因?yàn)樗c應(yīng)用程序一起運(yùn)行，適合運(yùn)維能力較弱的小團(tuán)隊(duì)使用。然而，它的缺點(diǎn)在于缺乏多語言支持。目前，這類主流解決方案如TDDL和早期的網(wǎng)易DDB，它們都是用Java開發(fā)的，無法支持其他編程語言。另外，版本升級也需要使用方主動更新，相對較為困難。

第二類中間件方案是單獨(dú)部署的代理層，代表性的有早期的阿里巴巴開源項(xiàng)目Cobar、基于Cobar開發(fā)的Mycat、360開源的Atlas，以及美團(tuán)開源的基于Atlas開發(fā)的DBProxy等等。這些中間件獨(dú)立部署在專用服務(wù)器上，業(yè)務(wù)代碼可以像使用單一數(shù)據(jù)庫一樣與它交互，盡管實(shí)際上它內(nèi)部管理著多個(gè)數(shù)據(jù)源。當(dāng)應(yīng)用程序發(fā)起數(shù)據(jù)庫請求時(shí)，這些中間件會對SQL語句進(jìn)行必要的改寫，然后將其發(fā)送到指定的數(shù)據(jù)源。它們通常使用標(biāo)準(zhǔn)的MySQL通信協(xié)議，因此可以很好地支持多種編程語言。

由于這些中間件是獨(dú)立部署的，因此比較容易進(jìn)行維護(hù)和升級，適合具有一定運(yùn)維能力的大中型團(tuán)隊(duì)使用。然而，它們的缺點(diǎn)在于所有SQL語句需要跨越兩次網(wǎng)絡(luò)：從應(yīng)用到代理層，然后從代理層到數(shù)據(jù)源，因此在性能方面可能會有一些損耗。

圖片

這些中間件，對你而言，可能并不陌生，但是我想讓你注意到是，在使用任何中間件的時(shí)候一定要保證對于中間件有足夠深入的了解，否則一旦出了問題沒法快速地解決就悲劇了。

需要明確的要點(diǎn)主要有：

1. 主從復(fù)制是一種存儲節(jié)點(diǎn)之間相互復(fù)制數(shù)據(jù)的技術(shù)，它實(shí)現(xiàn)了數(shù)據(jù)冗余，用于備份和提高橫向擴(kuò)展性。在使用主從復(fù)制時(shí)，需要權(quán)衡一致性和寫入性能。如果要確保所有從節(jié)點(diǎn)都成功寫入，寫入性能可能會受到影響。如果只寫入主節(jié)點(diǎn)并立即返回成功，從節(jié)點(diǎn)可能出現(xiàn)數(shù)據(jù)同步失敗的情況，導(dǎo)致主從不一致。在互聯(lián)網(wǎng)項(xiàng)目中，通常更注重性能而不是強(qiáng)一致性。
2. 主從復(fù)制的延遲問題是一個(gè)關(guān)鍵的監(jiān)控指標(biāo)，可能會導(dǎo)致無法立刻讀取數(shù)據(jù)的問題。很多奇怪的讀取不到數(shù)據(jù)的情況可能與主從延遲有關(guān)。因此，在遇到這類問題時(shí)，首先要考慮檢查主從延遲的數(shù)據(jù)。
3. 業(yè)界存在多種方案來屏蔽主從復(fù)制后數(shù)據(jù)庫訪問的細(xì)節(jié)，使開發(fā)人員能夠像訪問單一數(shù)據(jù)庫一樣使用它們。這些方案包括嵌入應(yīng)用內(nèi)部的解決方案（如TDDL、Sharding-JDBC）和獨(dú)立部署的代理方案（如Mycat）。不同的方案適用于不同的場景和需求。

這種思想和技術(shù)在許多存儲組件中都有應(yīng)用，如Redis使用主從復(fù)制實(shí)現(xiàn)讀寫分離，Elasticsearch中的索引分片可以被復(fù)制到多個(gè)節(jié)點(diǎn)，HDFS中的文件會被復(fù)制到多個(gè)DataNode。盡管不同組件對復(fù)制的一致性和延遲要求不同，但這種設(shè)計(jì)思想是通用的，對于理解和學(xué)習(xí)其他存儲組件非常有幫助。