現(xiàn)在絕大部分軟件項(xiàng)目，都會(huì)使用到關(guān)系型數(shù)據(jù)庫(kù)，比如MySQL、Oracle、DB2等等，目前這些數(shù)據(jù)庫(kù)的單機(jī)性能已經(jīng)是不斷優(yōu)化和提高了，但是隨著數(shù)據(jù)增長(zhǎng)的速度和并發(fā)訪問(wèn)量的增加，在某些公司、某些場(chǎng)景下，單機(jī)數(shù)據(jù)庫(kù)已經(jīng)很難滿足業(yè)務(wù)的需要了，所以必須考慮數(shù)據(jù)庫(kù)集群的方式來(lái)提高系統(tǒng)的可用性；最常見(jiàn)的兩種方法：

分庫(kù)分表：把數(shù)據(jù)分散到不同的數(shù)據(jù)庫(kù)上，每臺(tái)數(shù)據(jù)庫(kù)中存儲(chǔ)的數(shù)據(jù)是不相同的（這里先不考慮每個(gè)庫(kù)做備份或讀寫分離）；分庫(kù)分表既可以分散數(shù)據(jù)庫(kù)訪問(wèn)的壓力，也可以分散數(shù)據(jù)存儲(chǔ)的壓力；但是使用分庫(kù)分表方案的時(shí)候，會(huì)帶來(lái)擴(kuò)容、事務(wù)、關(guān)聯(lián)查詢等問(wèn)題和難點(diǎn)，具體這里就不展開講了。

讀寫分離：將數(shù)據(jù)庫(kù)讀操作和寫操作分散到不同的節(jié)點(diǎn)上，通常是一臺(tái)數(shù)據(jù)庫(kù)做寫操作，1到N臺(tái)做讀操作；讀寫分離的架構(gòu)，每一臺(tái)數(shù)據(jù)中的數(shù)據(jù)是相同的（這里先忽略延遲的問(wèn)題），所以只分散了數(shù)據(jù)庫(kù)訪問(wèn)的壓力，并沒(méi)有分散數(shù)據(jù)存儲(chǔ)的壓力；我們這里主要講一講讀寫分離。

讀寫分離基本架構(gòu)

MySQL讀寫分離的基本架構(gòu)，可以參考下圖：

如上圖，讀寫分離實(shí)現(xiàn)的基本步驟是：

數(shù)據(jù)庫(kù)服務(wù)器搭建多臺(tái)，一主N從（N大于等于1）；

主數(shù)據(jù)庫(kù)只負(fù)責(zé)寫操作，從數(shù)據(jù)庫(kù)只負(fù)責(zé)讀操作；

主數(shù)據(jù)庫(kù)復(fù)制數(shù)據(jù)到從數(shù)據(jù)庫(kù)上；

客戶端寫操作路由到主數(shù)據(jù)庫(kù)上，讀操作路由到從數(shù)據(jù)庫(kù)上。

讀寫分離還有另外一種架構(gòu)，就是在MySQL數(shù)據(jù)庫(kù)和客戶端之間，增加一層中間代理層，客戶端只連接代理， 由代理根據(jù)請(qǐng)求類型，把請(qǐng)求分發(fā)到不同的數(shù)據(jù)庫(kù)上：

第一種架構(gòu)，整體架構(gòu)比較簡(jiǎn)單直接，性能會(huì)稍微高一些，但是如果才用直連的方式，客戶端可能會(huì)稍微麻煩一些（通常需要引入一些組件，負(fù)責(zé)管理數(shù)據(jù)庫(kù)）；

第二種架構(gòu)，對(duì)客戶端比較友好，因?yàn)榭蛻舳酥恍枰痛斫换ィ⒉挥藐P(guān)注數(shù)據(jù)庫(kù)的具體信息；但是因?yàn)槎嗔艘粚哟?，多多少少?huì)對(duì)性能有一定的影響。

讀寫分離帶來(lái)的好處

讀寫分離結(jié)構(gòu)中，會(huì)有兩臺(tái)甚至更多臺(tái)數(shù)據(jù)庫(kù)，這種冗余的設(shè)計(jì)，可以提高數(shù)據(jù)的安全性和系統(tǒng)的可用性；就算是在分庫(kù)分表的架構(gòu)中，每一臺(tái)子庫(kù)，也可以一主多備的部署方式；

讀寫分離更多的時(shí)候使用在讀操作遠(yuǎn)遠(yuǎn)大于寫操作的場(chǎng)景下，這樣可以保證寫操作的數(shù)據(jù)庫(kù)承受更小的壓力，也可以緩解X鎖和S鎖爭(zhēng)用；

服務(wù)器數(shù)量的增加，意味著可以有效地利用多臺(tái)服務(wù)器的資源；讀操作被分?jǐn)?，提高了系統(tǒng)的性能；

如果寫操作比讀操作多，或者相近，可以采用雙主相互復(fù)制的架構(gòu)。

讀寫分離會(huì)帶來(lái)的問(wèn)題

之前的文章，我也反復(fù)強(qiáng)調(diào)過(guò)，任何的架構(gòu)、軟件、框架、組件...在解決一部分問(wèn)題的時(shí)候，一定會(huì)帶來(lái)其他的問(wèn)題；讀寫分離最大的一個(gè)問(wèn)題就是，數(shù)據(jù)從主復(fù)制到從的過(guò)程中，可能會(huì)存在延遲的，如果客戶端在執(zhí)行完一個(gè)讀操作后，立刻從存庫(kù)中查詢的話，可能會(huì)讀取到舊數(shù)據(jù)的情況（我們不斷優(yōu)化，也只能縮短這個(gè)時(shí)間，并不能完全消除掉這個(gè)時(shí)間）。

那么針對(duì)這個(gè)問(wèn)題，有哪些處理方法呢？

根據(jù)具體場(chǎng)景進(jìn)行評(píng)估，是否可以接收這個(gè)延遲（這好像是一句廢話，但是大多數(shù)業(yè)務(wù)場(chǎng)景，是可以接收這點(diǎn)兒延遲的）；

對(duì)于實(shí)時(shí)性要求很高的場(chǎng)景（查詢的數(shù)據(jù)必須是最新的結(jié)果），將這些請(qǐng)求強(qiáng)制路由到主庫(kù)上；

執(zhí)行完寫操作之后，在讀操作發(fā)生之前，讓中間的時(shí)間變長(zhǎng)（也就是從業(yè)務(wù)操作角度來(lái)做一些控制，不一定操作完了立刻查詢）；

判斷主備無(wú)延遲，可以通過(guò)判斷seconds_behind_master參數(shù)、對(duì)比GTID、對(duì)比位點(diǎn)等方式，判斷從數(shù)據(jù)庫(kù)是否和主數(shù)據(jù)庫(kù)一致。