https://blog.csdn.net/xiaofengcanyuexj/article/details/52555230

當(dāng)系統(tǒng)規(guī)模達(dá)到一定程度時(shí)，傳統(tǒng)的單機(jī)模式往往無法滿足，于是就有了分布式系統(tǒng)。分布式系統(tǒng)面臨的問題是CAP問題?。CAP具體含義如下：

1、consistency：一致性，保持?jǐn)?shù)據(jù)同步更新

2、availability：可用性，良好的響應(yīng)性能

3、partition tolerance：分區(qū)容錯(cuò)性，可靠性

定理：任何分布式系統(tǒng)只可同時(shí)滿足二點(diǎn)，沒法三者兼顧。忠告：一般3種特性不能同時(shí)滿足，而是應(yīng)該取舍與折中。

一般來說，當(dāng)數(shù)據(jù)分布在不同的機(jī)器（或者實(shí)體集，或者虛擬機(jī)，或者跨機(jī)房等）上，具體的好處有很多，通?？梢阅脕碜鳛楦鞣N指標(biāo)的總結(jié)如下：

1、數(shù)據(jù)分布

2、負(fù)載平衡

3、備份

4、高可用性

5、容錯(cuò)

? ? BASE模型是CAP犧牲強(qiáng)一致性、保證可用性的折中方案：

1、basically available-基本可用

分布式系統(tǒng)發(fā)生不可預(yù)知的故障時(shí)，允許損失部分可用性，如服務(wù)降級(jí)等等

2、soft state-弱狀態(tài)

分布式系統(tǒng)不同節(jié)點(diǎn)間某個(gè)時(shí)刻數(shù)據(jù)允許存在中間狀態(tài)，不同節(jié)點(diǎn)的數(shù)據(jù)副本之間進(jìn)行同步時(shí)可能存在時(shí)延，如主從同步

3、eventually consistent-最終一致

分布式系統(tǒng)不同節(jié)點(diǎn)的所有數(shù)據(jù)副本，在經(jīng)過一段時(shí)間數(shù)據(jù)同步后，最終達(dá)到一致狀態(tài)，即保證最終一致性，不保證實(shí)時(shí)一致性

? ? 我們通常接觸的常見中間件，如mysql、zookeeper、redis、elasticsearch等都是基于BASE理論建立的，下面就簡(jiǎn)要分析它們保持主從同步的機(jī)制，作為讀書筆記，歡迎斧正與提建議，謝謝。

一、mysql

作為通用的開源關(guān)系型數(shù)據(jù)庫，mysql在CAP方面有著較好的折中，mysql集群主要是通過binlong在主從DB上進(jìn)行傳遞來保持同步的。slave的io線程從master讀取二進(jìn)制日志binlog，并在本地保存為中繼日志relaylog，然后sql線程讀取中繼日志relaylog的內(nèi)容并執(zhí)行命令，從而保證slave和master數(shù)據(jù)同步。

具體步驟大致如下：

1、master驗(yàn)證連接

2、master為slave開啟主從同步線程

3、slave二進(jìn)制日志binlog的偏移位ssynch告訴master

4、master檢查ssynch是否小于當(dāng)前二進(jìn)制日志binlog偏移位msynch

5、如果ssynch小于msynch，則通知slave來取數(shù)據(jù)

6、slave持續(xù)從master取數(shù)據(jù)，直至取完

7、當(dāng)master更新時(shí)，master線程被激活，并將二進(jìn)制日志推送給slave，slave io線程讀取網(wǎng)絡(luò)上的二進(jìn)制日志binlog

8、slave的sql線程執(zhí)行二進(jìn)制日志binlog，同步數(shù)據(jù)

其中 二進(jìn)制日志binlog具體傳輸?shù)氖莝ql命令還是最終數(shù)據(jù)行，視具體設(shè)置而定。從mysql5.1.12開始，支持3種模式來實(shí)現(xiàn)復(fù)制：

1、statement-based replication，SBR-基于SQL語句的復(fù)制

優(yōu)點(diǎn)：binlog較少，網(wǎng)絡(luò)傳輸效率高；binlog可以實(shí)時(shí)還原；主從版本可以不一樣

缺點(diǎn)：必須串行執(zhí)行；不是所有的update語句都能被復(fù)制，尤其是包含不確定操作的時(shí)候，如：load_file()、uuid()、user()、found_rows()、sysdate()(除非啟動(dòng)了sysdate is now 選項(xiàng))；進(jìn)行全表掃描的update時(shí)，需要比RBR更多的行級(jí)鎖；復(fù)雜的語句在slave上執(zhí)行耗資源嚴(yán)重

2、row-based replication，RBR-基于數(shù)據(jù)行的復(fù)制

RBR優(yōu)點(diǎn)：可以并行執(zhí)行，安全可靠；需要更少的行級(jí)鎖，如insert ... select、包含 auto_increment字段的 insert等

RBR缺點(diǎn)：binlog文件大，網(wǎng)絡(luò)傳輸效率低；master上執(zhí)行update語句時(shí)，寫入較多，可能導(dǎo)致頻繁發(fā)生binlog的并發(fā)寫問題

3、mixed-based replication，MBR-混合模式復(fù)制

對(duì)應(yīng)binlog有三種模式：statement，row，mixed，其中在MBR模式中，SBR模式是默認(rèn)的。

二、zookeeper

? ? zookeeper是開源的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，是一個(gè)為分布式應(yīng)用提供一致性服務(wù)的軟件，提供的功能包括：配置文件的管理、集群管理、同步鎖、leader 選舉、隊(duì)列管理等。zookeeper集群通過paxos協(xié)議變種zab來保持同步的。

? ?zookeeper的主要角色為：首領(lǐng)-leader，跟隨者-follower，觀察者-observer

leader

? ?leader是zookeeper集群的主節(jié)點(diǎn)，負(fù)責(zé)響應(yīng)所有對(duì)zookeeper狀態(tài)變更的請(qǐng)求（事務(wù)性更新和非事務(wù)性查詢）

? ?對(duì)于exists，getData，getChildren等非事務(wù)性查詢請(qǐng)求，zookeeper服務(wù)器直接本地處理，每個(gè)服務(wù)器的命名空間是一致的。對(duì)于create，setData，delete等事務(wù)性更新請(qǐng)求，需要統(tǒng)一轉(zhuǎn)發(fā)給leader處理，leader保

證2-階段或者3-階段來處理請(qǐng)求。

follower

? ?follower響應(yīng)非事務(wù)性查詢，還可以處理leader的提議，并在leader提交該提議時(shí)在本地提交。leader和follower構(gòu)成zookeeper集群的法定人數(shù)，參與新leader的選舉、響應(yīng)leader的提議。

observer

observer只響應(yīng)非事務(wù)性查詢，observer和follower區(qū)別在于：observer不參加選舉也不響應(yīng)提議；observer不需要將事務(wù)持久化到磁盤，一旦observer重啟，需要leader全量同步命名空間。

1、SNAP-全量同步

條件：peerLastZxid

說明：證明二者數(shù)據(jù)差異太大，follower數(shù)據(jù)過于陳舊，leader發(fā)送快照SNAP指令給follower全量同步數(shù)據(jù)，即leader將所有數(shù)據(jù)全量同步到follower

2、DIFF-增量同步

條件：minCommittedLog<=peerLastZxid<=maxCommittedLog

說明：證明二者數(shù)據(jù)差異不大，follower上有一些leader上已經(jīng)提交的提議proposal未同步，此時(shí)增量提交這些提議即可

3、TRUNC-僅回滾同步

條件：peerLastZxid>minCommittedLog

說明：證明follower上有些提議proposal并未在leader上提交，follower需要回滾到zxid為minCommittedLog對(duì)應(yīng)的事務(wù)操作

4、TRUNC+DIFF-回滾+增量同步

條件：minCommittedLog<=peerLastZxid<=maxCommittedLog且特殊場(chǎng)景l(fā)eader a已經(jīng)將事務(wù)truncA提交到本地事務(wù)日志中，但沒有成功發(fā)起proposal協(xié)議進(jìn)行投票就宕機(jī)了；然后集群中剔除原leader a重新選舉出

新leader b，又提交了若干新的提議proposal，然后原leader a重新服務(wù)又加入到集群中，不管是否被選舉為新leader。

說明：此時(shí)a，b都有一些對(duì)方未提交的事務(wù)，leader a需要先回滾truncA然后增量同步新leader b上的數(shù)據(jù)

三、redis

? ? redis是一個(gè)開源的使用c編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存支持可持久化的日志型、key-value數(shù)據(jù)庫，提供多語言的API接口，通常用來作為分布式系統(tǒng)的緩存服務(wù)。redis集群通過rdb文件和aof文件來保持主從同步的。slave啟動(dòng)時(shí)連接到master，主動(dòng)發(fā)送一條sync命令；然后master啟動(dòng)后臺(tái)持久化進(jìn)程，在后臺(tái)進(jìn)程執(zhí)行完畢后，master將傳送整個(gè)redis數(shù)據(jù)庫rdb文件到slave，完成全量同步；slave服務(wù)器接收到數(shù)據(jù)庫rdb文件后將其存盤并加載到內(nèi)存中；此后，master繼續(xù)將更新命令（增刪改）以aof文件的形式有序傳送給slave，slave執(zhí)行aof文件里的命令，從而slave與master保持?jǐn)?shù)據(jù)同步。其中，關(guān)于rdb和aof兩種文件含義如下：

1、rdb持久化

? ? ?在指定的時(shí)間間隔內(nèi)生成數(shù)據(jù)集的時(shí)間點(diǎn)快照

2、aof持久化

記錄執(zhí)行更新操作命令，新命令會(huì)被追加到文件的末尾；redis對(duì)aof文件進(jìn)行重寫，使得aof文件不至于很大

redis還可以同時(shí)使用aof持久化和rbd持久化。在這種情況下，當(dāng)redis重啟時(shí)，優(yōu)先使用aof文件來還原數(shù)據(jù)集，因?yàn)閍of文件通常比rdb文件所保存的數(shù)據(jù)集更完整。

? ? ?slave連接master后，會(huì)主動(dòng)發(fā)起psync命令，slave會(huì)提供master_runid和offset，master驗(yàn)證master_runid和offset是否有效，其中master_runid作為master身份驗(yàn)證，offset是全局積壓空間數(shù)據(jù)的偏移量。

1、完整重同步

當(dāng)slave的offset不在master暫存隊(duì)列時(shí)，執(zhí)行完整重同步。master返回 full resync master_runid offset，啟動(dòng)bgsave生成rdb文件，bgsave結(jié)束后，向slave傳輸，從而完成完整重同步

2、部分重同步

?當(dāng)slave的offset存在于master暫存隊(duì)列時(shí)，執(zhí)行部分重同步。slave讀取offset偏移之后的所有更新事務(wù)日志aof，然后slave執(zhí)行對(duì)應(yīng)事務(wù)

四、elasticsearch

?elasticsearch是一個(gè)基于lucene構(gòu)建的開源，分布式，restfull搜索引擎，能夠達(dá)到實(shí)時(shí)搜索，穩(wěn)定，可靠，快速，支持通過http使用json進(jìn)行數(shù)據(jù)索引。

1、node-節(jié)點(diǎn)

? ? ?單個(gè)es實(shí)例，一臺(tái)主機(jī)上部署es應(yīng)用則稱為一個(gè)節(jié)點(diǎn)

2、cluster-集群

? ? 由若干節(jié)點(diǎn)組成

3、shard-分片

一個(gè)索引會(huì)分成多個(gè)分片存儲(chǔ)，分片數(shù)量在索引建立后不可更改

4、replica-副本

? ? 副本是分片的一個(gè)拷貝，提高系統(tǒng)的容錯(cuò)性和查詢性能

5、index-索引

類比數(shù)據(jù)庫的庫

6、type-類型

? ? 類比數(shù)據(jù)庫的表

7、document-文檔

? ? ?類比數(shù)據(jù)庫的行，包含若干個(gè)field

8、field-字段

搜索的最小單元，可通過mapping定義不同的屬性

? ? es中master節(jié)點(diǎn)相對(duì)沒有mysql、zookeeper、redis等對(duì)于整個(gè)集群那么重要，但是也是特別重要的。es的master監(jiān)控集群的拓?fù)浣Y(jié)構(gòu)和健康狀態(tài)，分發(fā)索引分片到集群節(jié)點(diǎn)，不同的是具體文檔的索引主分片不一定在master上。