mysql日期臨界值查詢，如何實(shí)現(xiàn)分布式系統(tǒng)的高可用性？

職場(chǎng)新兵的指南：關(guān)于高可用系統(tǒng)建設(shè)的一些思考

在參與公司幾個(gè)多數(shù)據(jù)中心項(xiàng)目的容災(zāi)架構(gòu)設(shè)計(jì)后，積累了一些高可用和多數(shù)據(jù)中心容災(zāi)的一些思考，希望總結(jié)和分享出來(lái)和大家一起學(xué)習(xí)。

可用性衡量指標(biāo)我們做軟件系統(tǒng)核心是服務(wù)于業(yè)務(wù)，構(gòu)建高可用系統(tǒng)本質(zhì)也是為了讓業(yè)務(wù)的服務(wù)質(zhì)量提供，因?yàn)樵跇?gòu)建高可用系統(tǒng)之前，我們需要根據(jù)業(yè)務(wù)特性確認(rèn)我們系統(tǒng)需要怎么樣的高可用級(jí)別，也就是需要一個(gè)指標(biāo)度量我們系統(tǒng)的可用性。

可用性度量的指標(biāo)有以下幾個(gè)：

MTBF（Mean Time Between Failure），平均故障間隔，代表兩次故障的間隔時(shí)間，也就是系統(tǒng)正常運(yùn)轉(zhuǎn)的平均時(shí)間。這個(gè)時(shí)間越長(zhǎng)，系統(tǒng)穩(wěn)定性越高。MTTR（Mean Time To Repair），故障的平均恢復(fù)時(shí)間，也叫平均故障時(shí)間。這個(gè)值越小，故障對(duì)于用戶的影響越小。但 MTBF 和 MTTR 這兩個(gè)指標(biāo)中的故障不僅僅是IT系統(tǒng)宕機(jī)故障，也包括了性能問(wèn)題和人為的錯(cuò)誤。甚至USITS一項(xiàng)關(guān)于大型互聯(lián)網(wǎng)服務(wù)的研究發(fā)現(xiàn)，運(yùn)維配置錯(cuò)誤是導(dǎo)致服務(wù)中斷的首要原因，而硬件故障（服務(wù)器或網(wǎng)絡(luò)）僅導(dǎo)致了 10-25% 的服務(wù)中斷，但如何避免人為錯(cuò)誤并不在今天的討論當(dāng)中。

所以，在針對(duì)數(shù)據(jù)中心的容災(zāi)，我們可能用到更多地是RTO和RPO這兩個(gè)指標(biāo)：

RTO(Recovery Time Object)，恢復(fù)時(shí)間目標(biāo)，RTO是反映數(shù)據(jù)中心業(yè)務(wù)恢復(fù)的及時(shí)性指標(biāo)。RPO(Recovery Point Objective)，復(fù)原點(diǎn)目標(biāo)，指數(shù)據(jù)中心能容忍的最大數(shù)據(jù)丟失量，是指當(dāng)業(yè)務(wù)恢復(fù)后，恢復(fù)得來(lái)的數(shù)據(jù)所對(duì)應(yīng)時(shí)間點(diǎn)，RPO取決于數(shù)據(jù)中心數(shù)據(jù)恢復(fù)到怎樣的更新程度，反映數(shù)據(jù)中心恢復(fù)數(shù)據(jù)完整性的指標(biāo)。

一般我們對(duì)現(xiàn)有系統(tǒng)做可用性改造時(shí)，可以先看看現(xiàn)有系統(tǒng)的基準(zhǔn)值是多少，然后根據(jù)業(yè)務(wù)目標(biāo)，確定要提升到多少來(lái)改善。

高可用改造層級(jí)在和業(yè)務(wù)確定好可用指標(biāo)后，接下來(lái)就需要對(duì)系統(tǒng)做高可用改造，從容災(zāi)級(jí)別可以分為三個(gè)層面：

基于Region(地理區(qū)域)的高可用架構(gòu)同城多Zone的高可用架構(gòu)單Zone多實(shí)例的的高可用架構(gòu)注：這里Region表示地區(qū)，一般是指行政單元比如地級(jí)市，Zone表示可用區(qū)，指電力和網(wǎng)絡(luò)相互獨(dú)立的物理區(qū)域

從軟件架構(gòu)的角度來(lái)看，針對(duì)可用性改造可以分為四個(gè)部分：

DNS服務(wù)負(fù)載均衡(LB)應(yīng)用服務(wù)數(shù)據(jù)庫(kù)/中間件其中，DNS服務(wù)和負(fù)載均衡都是無(wú)狀態(tài)的，數(shù)據(jù)庫(kù)和中間件則是有狀態(tài)的，而應(yīng)用服務(wù)根據(jù)業(yè)務(wù)邏輯不同可能是無(wú)狀態(tài)也可能是有狀態(tài)的。

單機(jī)房多實(shí)例的的高可用架構(gòu)這種架構(gòu)是最簡(jiǎn)單的，一般這種架構(gòu)只有一個(gè)LB網(wǎng)關(guān)，通過(guò)LB轉(zhuǎn)發(fā)到下游的應(yīng)用服務(wù)，應(yīng)用服務(wù)可以通過(guò)服務(wù)發(fā)現(xiàn)的方式做成多副本從而實(shí)現(xiàn)多活，比如可以用k8s部署應(yīng)用服務(wù)，配合存活探針檢查和k8s的service服務(wù)發(fā)現(xiàn)，可以輕松實(shí)現(xiàn)無(wú)狀態(tài)應(yīng)用的多活。如果你的服務(wù)不基于k8s部署，也可以基于微服務(wù)框架部署在多臺(tái)主機(jī)上實(shí)現(xiàn)應(yīng)用多活，只要實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)、存活探針檢查和自動(dòng)的流量切換就可以了。

但對(duì)于有狀態(tài)的，比如數(shù)據(jù)庫(kù)和中間件，僅僅依賴服務(wù)發(fā)現(xiàn)和流量切換并不能解決問(wèn)題，因?yàn)閿?shù)據(jù)在多副本之間需要做同步。因此針對(duì)數(shù)據(jù)庫(kù)或中間件的高可用方案基本都是需要專門設(shè)計(jì)，因?yàn)槌肆髁壳袚Q還要解決數(shù)據(jù)同步問(wèn)題。這部分在后面數(shù)據(jù)庫(kù)和中間件高可用解決方案在單獨(dú)展開(kāi)。

同城多機(jī)房的高可用架構(gòu)同城多機(jī)房（多AZ）容災(zāi)一般通過(guò) BGP 實(shí)現(xiàn)單IP多線網(wǎng)絡(luò)，然后機(jī)房之間通過(guò)專線相互打通物理網(wǎng)絡(luò)，當(dāng)出口流量出現(xiàn)故障時(shí)，可以通過(guò) BGP 在路由層切換報(bào)文轉(zhuǎn)發(fā)表來(lái)實(shí)現(xiàn)線路切換。架構(gòu)圖如下：

在數(shù)據(jù)鏈路正常的情況下，機(jī)房1，2會(huì)分別向路由宣告自己的路由表：機(jī)房1：地域AS -> 運(yùn)營(yíng)商AS -> 機(jī)房1 AS機(jī)房2：地域AS -> 運(yùn)營(yíng)商AS -> 機(jī)房2 AS

在機(jī)房1出現(xiàn)故障和運(yùn)營(yíng)商邊緣（接入）路由器斷開(kāi)的時(shí)候，機(jī)房2會(huì)向運(yùn)營(yíng)商AS宣告連接機(jī)房1的最短路徑從而讓流量轉(zhuǎn)發(fā)給自己：地域AS -> 運(yùn)營(yíng)商AS -> 機(jī)房2 AS -> 機(jī)房1 AS

如果對(duì)路由器BGP協(xié)議不是很了解的可以參考BGP的wiki

基于地理區(qū)域的高可用架構(gòu)如果我們要做基于地理區(qū)域級(jí)別的高可用，那么我們需要DNS智能路由和跨地域的云連接。

DNS智能路由DNS服務(wù)結(jié)合存活探測(cè)可以實(shí)現(xiàn)跨地域流量切換。當(dāng)存活探測(cè)發(fā)現(xiàn)后端 LB 不可用的時(shí)候，可以直接修改DNS解析，使其失效。但需要注意 DNS 協(xié)議切換一些延遲，生效時(shí)間在15分鐘~30分鐘（RTO），因此 DNS 一般只用于跨地域的 LB 的高可用，只有當(dāng)整個(gè)地區(qū)的 LB 不可用的時(shí)候才會(huì)被啟用。

我們知道跨地域的故障可以根據(jù)智能DNS協(xié)議來(lái)切換流量到不同的LB中，那么DNS服務(wù)本身是如何做高可用的呢？DNS 服務(wù)做高可用一般是基于 Anycast 和路由協(xié)議來(lái)實(shí)現(xiàn)，比如 BGP 或 OSPF。和同城多機(jī)房的高可用架構(gòu)一樣，通過(guò)路由協(xié)議實(shí)現(xiàn)單IP多線的網(wǎng)絡(luò)架構(gòu)來(lái)實(shí)現(xiàn)容災(zāi)切換。Anycast 網(wǎng)絡(luò)允許網(wǎng)絡(luò)上的多臺(tái)服務(wù)器使用相同的 IP 地址或一組 IP 地址, 通過(guò) BGP 的路徑選擇算法改變路由的選擇，從而使失效的DNS服務(wù)器節(jié)點(diǎn)下線，或者實(shí)現(xiàn)智能路由。不過(guò) DNS 服務(wù)做了高可用并不一定就萬(wàn)無(wú)一失了，2021年10月4日的 facebook 全球死機(jī)事件就是 BGP 配置錯(cuò)誤導(dǎo)致了 facebooK 的 DNS 全部失效了。所以，像開(kāi)頭說(shuō)的，高可用系統(tǒng)架構(gòu)只是解決了系統(tǒng)硬件故障，但人為配置錯(cuò)誤并不能避免。

云連接跨地域的云連接可以是基于骨干網(wǎng)的專線，也可以是VPN。通過(guò)云連接將處在不同地域的子網(wǎng)連接起來(lái)構(gòu)造一個(gè)互聯(lián)互通的企業(yè)網(wǎng)。專線相比VPN網(wǎng)絡(luò)傳輸會(huì)更穩(wěn)定些，安全性更高，但價(jià)格也會(huì)更貴，成本更高。

數(shù)據(jù)庫(kù)及中間件的高可用方案數(shù)據(jù)庫(kù)和中間件的容災(zāi)是一種典型的有狀態(tài)服務(wù)應(yīng)用的場(chǎng)景，其核心是數(shù)據(jù)復(fù)制和同步。前面說(shuō)到的兩個(gè)指標(biāo) RTO 和 RPO 就是圍繞數(shù)據(jù)容災(zāi)來(lái)描述的，如果我們是雙活架構(gòu)那么RTO就是0，如果是主備那么RTO就是主備切換所需的時(shí)間；如何我們的數(shù)據(jù)復(fù)制采用完全同步的方式，RPO就是0，如果采用異步復(fù)制，那么RPO就是數(shù)據(jù)復(fù)制之間的時(shí)間差，如果是快照，那么RPO就是快照產(chǎn)生備份數(shù)據(jù)和。

數(shù)據(jù)復(fù)制數(shù)據(jù)復(fù)制按照l(shuí)eader可以分為三種：?jiǎn)晤I(lǐng)導(dǎo)者（single leader，單主），多領(lǐng)導(dǎo)者（multi leader，多主） 和 無(wú)領(lǐng)導(dǎo)者（leaderless，無(wú)主）。單主和多主都屬于主從架構(gòu)，從節(jié)點(diǎn)通過(guò)復(fù)制主節(jié)點(diǎn)的日志或變更流(change stream)來(lái)同步數(shù)據(jù)，但在使用場(chǎng)景上兩者存在比較大的不同，多主架構(gòu)一般被用于地理位置上的多數(shù)據(jù)中心的容災(zāi)和就近服務(wù)，而單主架構(gòu)一般用于單數(shù)據(jù)中心，因?yàn)槎嘀骷軜?gòu)給整個(gè)系統(tǒng)帶來(lái)的復(fù)雜度是很高的，我們需要處理數(shù)據(jù)沖突，這會(huì)給整個(gè)系統(tǒng)帶來(lái)復(fù)雜性并降低性能。架構(gòu)設(shè)計(jì)核心是要解決問(wèn)題，因此本質(zhì)上是一種取舍和balance，在架構(gòu)設(shè)計(jì)的時(shí)候要視業(yè)務(wù)和場(chǎng)景而定。

單主架構(gòu)單主架構(gòu)就是我們常說(shuō)的主從架構(gòu)，是分布式架構(gòu)中最簡(jiǎn)單的架構(gòu)，只在 leader 節(jié)點(diǎn)做讀寫(xiě)操作，follower 節(jié)點(diǎn)提供讀操作。從庫(kù)復(fù)制主庫(kù)通常通過(guò)變更日志實(shí)現(xiàn)，這種變更日志既可以是預(yù)寫(xiě)日志(WAL)，也可以是復(fù)制邏輯日志。常用的數(shù)據(jù)庫(kù)的數(shù)據(jù)復(fù)制:

Kafka的kafaka MirrorMarkerMySQL的 binlog 主從復(fù)制PostgreSQL的 WAL 主從復(fù)制多主架構(gòu)多主架構(gòu)在主從數(shù)據(jù)同步邏輯上和單主架構(gòu)是一樣的，區(qū)別核心在多個(gè)主節(jié)點(diǎn)寫(xiě)入數(shù)據(jù)的時(shí)候如何進(jìn)行數(shù)據(jù)同步。一般引入多主架構(gòu)其中一個(gè)原因是解決跨地域數(shù)據(jù)同步問(wèn)題，比如在單主架構(gòu)下，一個(gè)在廣州的用戶在寫(xiě)入數(shù)據(jù)需要需要傳輸?shù)奖本┑闹鞴?jié)點(diǎn)上，那么性能就會(huì)比較差了。另一個(gè)原因則是多主的故障容忍要大于主從，比如在兩個(gè)主節(jié)點(diǎn)的情況下，其中一個(gè)節(jié)點(diǎn)出故障的時(shí)候另一個(gè)節(jié)點(diǎn)并不會(huì)受到影響，只會(huì)影響一半的用戶，而主從架構(gòu)在從節(jié)點(diǎn)切換完成之前是全用戶故障的。我們可以先從最簡(jiǎn)單的，兩個(gè)主節(jié)點(diǎn)來(lái)討論。在雙主的結(jié)構(gòu)下，核心要解決的就是寫(xiě)入的時(shí)候的數(shù)據(jù)沖突問(wèn)題，如下圖所示：

在解決數(shù)據(jù)沖突的時(shí)候通常會(huì)采用以下的一些辦法：

最簡(jiǎn)單的方式就是采用同步的方式寫(xiě)入數(shù)據(jù)，即數(shù)據(jù)寫(xiě)入成功需要等待其他主庫(kù)解決沖突之后，這樣就將多個(gè)主庫(kù)寫(xiě)入變成串行執(zhí)行了，也就失去了多主庫(kù)的核心。通過(guò)分庫(kù)的方式來(lái)避免沖突，比如請(qǐng)求通過(guò)統(tǒng)一的路由讓a用戶數(shù)據(jù)都讀寫(xiě)在A庫(kù)中，而b類數(shù)據(jù)讀寫(xiě)在B庫(kù)，其實(shí)這樣本質(zhì)類似于將數(shù)據(jù)庫(kù)以多分區(qū)的形式存放在多個(gè)地區(qū)，只是a庫(kù)會(huì)通過(guò)數(shù)據(jù)復(fù)制在同步到b庫(kù)。只保證所有副本最終一致性，通過(guò)全局唯一ID或全局時(shí)鐘確定最后更新的數(shù)據(jù)才寫(xiě)入。但是這種方法在異步的情況下會(huì)導(dǎo)致一部分中間數(shù)據(jù)丟失。除了要解決數(shù)據(jù)沖突，多主在數(shù)據(jù)復(fù)制的時(shí)候還需要解決節(jié)點(diǎn)復(fù)制傳播的順序，也就是復(fù)制拓?fù)?replication topology)。對(duì)于多主復(fù)制，常見(jiàn)的復(fù)制拓?fù)渲饕腥N：

環(huán)型拓?fù)浼軜?gòu)(circular topology)，即一個(gè)數(shù)據(jù)節(jié)點(diǎn)將數(shù)據(jù)復(fù)制給相鄰的節(jié)點(diǎn)，依次循環(huán)一周。星型拓?fù)浼軜?gòu)(star topology)，所有節(jié)點(diǎn)圍繞著一個(gè)中心節(jié)點(diǎn)進(jìn)行數(shù)據(jù)復(fù)制和交互。全拓?fù)浼軜?gòu)(all-to-all topology)，即所有節(jié)點(diǎn)相互之間都會(huì)進(jìn)行數(shù)據(jù)的復(fù)制和交互，常見(jiàn)的比如 gossip 協(xié)議。

在多個(gè)主節(jié)點(diǎn)進(jìn)行數(shù)據(jù)復(fù)制和傳播的時(shí)候，由于會(huì)經(jīng)過(guò)多個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)之間需要識(shí)別攜帶其他節(jié)點(diǎn)的變更信息，比如每個(gè)節(jié)點(diǎn)添加有一個(gè)唯一ID標(biāo)識(shí)其已經(jīng)過(guò)的節(jié)點(diǎn)，這樣才不會(huì)造成無(wú)休止的死循環(huán)無(wú)休止的傳播。

無(wú)主架構(gòu)在無(wú)主架構(gòu)中每個(gè)節(jié)點(diǎn)都可以對(duì)外提供服務(wù)，從設(shè)計(jì)理念上可以看出無(wú)主架構(gòu)天生就是為可用性而生，不過(guò)知道CAP理論的都知道，可用性和一致性不能兼得，無(wú)主架構(gòu)是個(gè)典型的AP模型，其犧牲了強(qiáng)一致性用最終一致性代替。無(wú)主架構(gòu)中最出名的是 AWS 的 Dynamo，像 Cassandra 這種采用和他類似的無(wú)主架構(gòu)的都被成為類Dynamo。Dynamo 采用Gossip協(xié)議來(lái)做復(fù)制數(shù)據(jù)，任何一個(gè)節(jié)點(diǎn)收到數(shù)據(jù)后會(huì)向其他節(jié)點(diǎn)異步地復(fù)制數(shù)據(jù)。那么 Dynamo 是怎么保證數(shù)據(jù)最終一致性的呢？Dynamo 使用 W + R > N 這個(gè)公式保證，R代表最少讀取的節(jié)點(diǎn)個(gè)數(shù)，W代表最少寫(xiě)入的節(jié)點(diǎn)個(gè)數(shù)，N為數(shù)據(jù)副本數(shù)，這里的副本數(shù)并不是實(shí)際的物理節(jié)點(diǎn)，因?yàn)?Dynamo 使用的一致性 hash。

比如N有3個(gè)節(jié)點(diǎn)，R是2，W也是2，那么客戶端向集群寫(xiě)入數(shù)據(jù)的時(shí)候只有在2個(gè)節(jié)點(diǎn)寫(xiě)入成功后才會(huì)返回給客戶端，這個(gè)過(guò)程是同步的，剩下的兩個(gè)節(jié)點(diǎn)則是異步的，在讀數(shù)據(jù)的時(shí)候，必須讀到2個(gè)節(jié)點(diǎn)，并取2個(gè)中最新的數(shù)據(jù)，可以看出這樣肯定可以讀到最新的數(shù)據(jù)。

當(dāng)出現(xiàn)數(shù)據(jù)沖突的時(shí)候 Dynamo 通過(guò)引入向量時(shí)鐘解決數(shù)據(jù)沖突：

向量時(shí)鐘通過(guò)帶上其他節(jié)點(diǎn)的向量時(shí)鐘來(lái)確定偏序關(guān)系，按圖上例子三個(gè)節(jié)點(diǎn)P0，P1，P2，初始三個(gè)節(jié)點(diǎn)都是(0,0,0)

首先，P0寫(xiě)入在 a 寫(xiě)入數(shù)據(jù)，P0 的向量時(shí)鐘為(1,0,0)當(dāng)P0把時(shí)鐘信息傳播到 P1 的時(shí)候，對(duì)應(yīng)的是時(shí)間點(diǎn) b，P1 的向量時(shí)鐘是(1,1,0)，這時(shí)候 P1 節(jié)點(diǎn)如果有個(gè)c寫(xiě)入，那么他的向量時(shí)鐘是(1,2,0)，c的向量時(shí)鐘里面的元素均大于等于 a，所以我們可以知道 c 時(shí)刻大于 a。這時(shí)候 P1 把時(shí)鐘信息傳播 d，向量時(shí)鐘是(1,2,1)，寫(xiě)入數(shù)據(jù) e 的數(shù)據(jù)時(shí)鐘是(1,2,2)，這個(gè)信息傳回 P0 后變成 g 時(shí)刻，向量時(shí)鐘是(3,2,2)在這里我們可以看到，a -> b -> c -> d -> e -> g 這個(gè)邏輯順序是成立的，而在向量時(shí)鐘上表現(xiàn)就是后一個(gè)所有元素都大于或等于前一個(gè)時(shí)間點(diǎn)。但 f 和 c, e 的先后順序關(guān)系是不確定的，在沒(méi)有全局時(shí)鐘的情況下你并不能知道誰(shuí)先誰(shuí)后，而在向量時(shí)鐘上表現(xiàn)就是 f 不是所有元素都大于等于 c 或 e。因此，其實(shí)向量時(shí)鐘表示為:

if V(a) > V(b) then a -> b

V(a) > V(b), 表示a向量的所有坐標(biāo)元素大于b向量的所有對(duì)應(yīng)坐標(biāo)的元素，a->b 表示 a 到 b 存在事件順序。

向量時(shí)鐘只能解決最終一致性（收斂）問(wèn)題，如果數(shù)據(jù)在達(dá)成最終一致性之前產(chǎn)生版本沖突，Dynamo 會(huì)將沖突版本返回給客戶端，由業(yè)務(wù)自行判斷。除了交由客戶端判斷，我們也可以采用“最后寫(xiě)入勝利（LWW, last write wins）”的策略，在數(shù)據(jù)生成的時(shí)候通過(guò)帶上時(shí)間戳，最后比較兩個(gè)版本的時(shí)間戳誰(shuí)新以誰(shuí)為準(zhǔn)。

Dynamo 檢測(cè)數(shù)據(jù)不一致用的 MerkleTree，MerkleTree 是通過(guò)一個(gè) hash 樹(shù)來(lái)計(jì)算每部分的數(shù)據(jù)，父節(jié)點(diǎn)是子節(jié)點(diǎn)數(shù)據(jù)的 hash，只要有一塊數(shù)據(jù)變動(dòng)了，最上層的根節(jié)點(diǎn)的hash就會(huì)改變，然后可以通過(guò)逐層遞歸的方式找到目標(biāo)節(jié)點(diǎn)，查詢時(shí)間復(fù)雜度是o(log(n))，如下圖：

更多詳細(xì)的 Dynamo 可以參考原論文，這是國(guó)外老哥的一篇論文筆記：

數(shù)據(jù)復(fù)制的幾種方式前面說(shuō)了數(shù)據(jù)復(fù)制的幾種架構(gòu)，那么具體數(shù)據(jù)復(fù)制的形式有哪些呢？這里根據(jù)數(shù)據(jù)庫(kù)復(fù)制數(shù)據(jù)的主體不同分為四類：

基于語(yǔ)句(statement)的數(shù)據(jù)復(fù)制基于邏輯日志(行)的數(shù)據(jù)復(fù)制基于預(yù)寫(xiě)日志(WAL)的數(shù)據(jù)復(fù)制基于觸發(fā)器的復(fù)制基于語(yǔ)句復(fù)制直接基于數(shù)據(jù)庫(kù)的語(yǔ)句進(jìn)行復(fù)制，MySQL 5.1 版本前都是基于語(yǔ)句進(jìn)行復(fù)制，基于語(yǔ)句的主從復(fù)制下 MySQL 會(huì)將 SQL 變更語(yǔ)句寫(xiě)入 binlog 中，然后同步給從節(jié)點(diǎn)讓其更新，基于語(yǔ)句的復(fù)制主要簡(jiǎn)單，而且傳輸數(shù)據(jù)量少，但其可能會(huì)存在不安全語(yǔ)句，而且每次更新都只能串行，特別是某些語(yǔ)句比如 INSERT ... SELECT 會(huì)因?yàn)殒i比行復(fù)制慢更多。PostgreSQL 的 pgpool-II 也是一種基于語(yǔ)句復(fù)制工具，但其本身相當(dāng)于數(shù)據(jù)庫(kù)的 Proxy，而不是數(shù)據(jù)庫(kù)自身提供的CDC。

復(fù)制邏輯日志(行)邏輯日志是針對(duì)語(yǔ)句復(fù)制提出來(lái)的，因?yàn)榛趕tatement的復(fù)制存在諸多問(wèn)題，比如事務(wù)沒(méi)辦法并行復(fù)制，只有等待一個(gè)commit才能復(fù)制另一個(gè)，性能差。因此另一種，是以行為顆粒度基于邏輯日志的數(shù)據(jù)方式，經(jīng)典代表就是 MySQL的binlog(row)格式。其對(duì)數(shù)據(jù)庫(kù)表的寫(xiě)入記錄：

對(duì)于插入的行，日志包含所有列的新值。對(duì)于刪除的行，日志包含足夠的信息來(lái)唯一標(biāo)識(shí)被刪除的行，這通常是主鍵，但如果表上沒(méi)有主鍵，則需要記錄所有列的舊值。對(duì)于更新的行，日志包含足夠的信息來(lái)唯一標(biāo)識(shí)被更新的行，以及所有列的新值（或至少所有已更改的列的新值）。復(fù)制預(yù)寫(xiě)日志(WAL)很多數(shù)據(jù)庫(kù)在寫(xiě)數(shù)據(jù)的時(shí)候?yàn)榱舜疟P順序讀寫(xiě)優(yōu)化和事務(wù)性會(huì)引入預(yù)寫(xiě)日志(write ahead logs,WAL)，因此一些數(shù)據(jù)同步方案會(huì)嘗試?yán)?wal 特性來(lái)做數(shù)據(jù)復(fù)制和同步。比如 PostgreSQL 9.0之后的 PITR(Point in Time Recovery) 就是基于 WAL 做主從復(fù)制。 PostgreSQL 的預(yù)寫(xiě)日志復(fù)制傳輸提供兩種：存檔式(archive)和流式(streaming)。存檔式就是等一個(gè)WAL文件寫(xiě)完后，再拷貝從節(jié)點(diǎn)；流式則是寫(xiě)完一條WAL記錄就通過(guò)TCP直接傳給從節(jié)點(diǎn)。存檔式存在數(shù)據(jù)延遲較大，流式則再主節(jié)點(diǎn)崩潰時(shí)從節(jié)點(diǎn)存在丟失數(shù)據(jù)的可能。

PostgreSQL Archive Replication

PostgreSQL Streaming Replication

基于觸發(fā)器的復(fù)制

上面講的那些復(fù)制方式都是數(shù)據(jù)庫(kù)系統(tǒng)提供的，比如基于語(yǔ)句和邏輯日志的復(fù)制是在數(shù)據(jù)庫(kù)的 server 計(jì)算層來(lái)做，預(yù)寫(xiě)日志(WAL)則是在存儲(chǔ)層做，而觸發(fā)器是數(shù)據(jù)庫(kù)系統(tǒng)系統(tǒng)的將自定義的程序注冊(cè)進(jìn)數(shù)據(jù)庫(kù)讓其在數(shù)據(jù)變更時(shí)自動(dòng)觸發(fā)。由于是由外部程序?qū)ψ兏M(jìn)行捕捉，因此他的靈活性是最高的，像多主復(fù)制的沖突解決方案大部分都是基于觸發(fā)器實(shí)現(xiàn)，比如 PostgreSQL 的 bucardo 就是基于 pg 的觸發(fā)器來(lái)做多主的數(shù)據(jù)復(fù)制。

小結(jié)整篇小作文洋洋灑灑寫(xiě)了近一萬(wàn)字，從系統(tǒng)架構(gòu)、各層級(jí)組件的高可用到數(shù)據(jù)復(fù)制拓?fù)洌Ｍ梢越o大家一個(gè)相對(duì)比較完整的視角去認(rèn)識(shí)高可用系統(tǒng)的建設(shè)。

參考文獻(xiàn)BGP協(xié)議2021年Facebook死機(jī)事件Designing Data-Intensive Application