一、分布式一致性協(xié)議
參考鏈接：https://www.jianshu.com/p/71b2729d3004
兩類(lèi)一致性(操作原子性與副本一致性)
2PC，3PC協(xié)議：強調事務(wù)，用于保證屬于多個(gè)數據分片上的操作的原子性。這些數據分片可能分布在不同的服務(wù)器上，2PC協(xié)議保證多臺服務(wù)器上的操作要么全部成功，要么全部失敗。Paxos，Raft協(xié)議：強調同一條數據的復制，用于保證同一個(gè)數據分片的多個(gè)副本之間的數據一致性。當這些副本分布到不同的數據中心時(shí)，這個(gè)需求尤其強烈。
下面講的是多個(gè)副本之間的數據一致性。
分布式系統
分布式一致性協(xié)議
選擇理由
協(xié)議核心功能
備注
TiDB
raft協(xié)議（強一致性）
raft協(xié)議實(shí)現簡(jiǎn)單
保證數據一致性，完整復制日志到其它節點(diǎn)leader選舉同一時(shí)刻只能保證有一個(gè)Leader，只有leader可以復制日志
由于raft協(xié)議是2013年發(fā)布，而TiDB發(fā)布于2016年，時(shí)間剛好趕上了
ElasticSearch
Gossip
最終一致性消息
Kafka
ZooKeeper
Zab協(xié)議
HDFS
HBase
通過(guò)HDFS進(jìn)行數據備份。WAL(Write-ahead logging)
WAL的實(shí)現是HLog，HLog也是存儲在HDFS上的，所以HRegionServer崩潰了也不會(huì )導致HLog的丟失，它也有備份。
需要注意的是，HBase Replication 是以 Column Family 為單位，每個(gè)CF都可以設置是否進(jìn)行 Replication。
注意：HBase是強一致性的
注意：
1.為什么raft協(xié)議是強一致性協(xié)議？因為超過(guò)半數成功后，認為是提交成功，然后只有這些提交成功的節點(diǎn)才會(huì )對外服務(wù)，這樣就保證了app查到的數據是正確的數據（沒(méi)有反饋確認的其它節點(diǎn)，即使成功了，也不會(huì )對外服務(wù)，只有反饋給leader成功，才會(huì )對外服務(wù)）
2.HBase中的Replication也是基于WAL的，其在主集群的每個(gè)RegionServer進(jìn)程內部起了一個(gè)叫做ReplicationSource的線(xiàn)程來(lái)負責Replication，同時(shí)在備集群的每個(gè)RegionServer內部起了一個(gè)ReplicationSink的線(xiàn)程來(lái)負責接收Replication數據。ReplicationSource記錄需要同步的WAL隊列，然后不斷讀取WAL中的內容，同時(shí)可以根據Replication的配置做一些過(guò)濾，比如是否要復制這個(gè)表的數據等，然后通過(guò)replicateWALEntry這個(gè)Rpc調用來(lái)發(fā)送給備集群的RegionServer，備集群的ReplicationSink線(xiàn)程則負責將收到的數據轉換為put/delete操作，以batch的形式寫(xiě)入到備集群中。
3、提一下Mysql：Mysql是通過(guò)異步的方式讀取binlog然后存儲到slave集群，肯定會(huì )導致數據一致性的延時(shí)，有時(shí)候寫(xiě)入量大可能會(huì )延時(shí)幾小時(shí)。
二、分布式系統需要考慮的幾個(gè)基本問(wèn)題
分片要盡量均勻的散落在不同的節點(diǎn)，均勻的目的：負載均衡，避免形成熱點(diǎn)；很重要的隱藏意義，即增加或減少節點(diǎn)，數據會(huì )重新進(jìn)行均衡分配，動(dòng)態(tài)的根據節點(diǎn)分片情況遷移數據（增加的節點(diǎn)剛開(kāi)始是沒(méi)有數據的，這樣導致各個(gè)增加節點(diǎn)數據不均勻，就會(huì )觸發(fā)分片重新分配；其實(shí)減少節點(diǎn)也會(huì )，因為減少后，可能導致某些主分片或副本丟失，所以要重新拷貝副本，這個(gè)過(guò)程就會(huì )導致數據不均勻，所以也會(huì )重新分配）必須多副本，至少一個(gè)，且數據的主分片和副本必須不能在同一個(gè)節點(diǎn)上：如果只有一個(gè)副本，且主分片和副本在一臺機器上，那么這臺機器掛掉后，這塊數據就會(huì )丟失，這違背了分布式系統的設計初衷；數據的散落方案：一種是按照 Key 做 Hash，根據 Hash 值選擇對應的存儲節點(diǎn)（ElasticSearch）；另一種是分 Range，某一段連續的 Key 都保存在一個(gè)存儲節點(diǎn)上（HBase，TiDB）。節點(diǎn)遷移需要控制速度，避免影響線(xiàn)上服務(wù)
三、數據存儲原理
分布式系統
概念
備注
其它說(shuō)明
TiDB
Region
ElasticSearch
分布式存儲原理：ElasticSearch - 巍巍的個(gè)人頁(yè)面 - OSCHINA - 中文開(kāi)源技術(shù)交流社區
Kafka
Broker，Partition
Broker：Kafka集群中的一臺或多臺服務(wù)器統稱(chēng)broker.Partition：Topic物理上的分組，一個(gè)topic可以分為多個(gè)partion,每個(gè)partion是一個(gè)有序的隊列。partion中每條消息都會(huì )被分配一個(gè) 有序的Id(offset)，同一 topic 下的不同分區包含的消息是不同的。
ZooKeeper
HDFS
HBase
Region
四、分布式系統的集群管理工具
分布式系統
集群管理
備注
其它說(shuō)明
TiDB
PD
ElasticSearch
Kafka
ZooKeeper
ZooKeeper
HDFS
HBase
ZooKeeper
1、管理機器是否可用
2、存儲region信息
3、
五、權衡CA之Quorum機制
參考鏈接：
https://blog.csdn.net/tb3039450/article/details/80249664
https://blog.csdn.net/tb3039450/article/details/80185436
六、MVCC與事務(wù)
MVCC即樂(lè )觀(guān)鎖的一種實(shí)現方式。
樂(lè )觀(guān)鎖(MVCC)何謂數據版本？即為數據增加一個(gè)版本標識，在基于數據庫表的版本解決方案中，一般是通過(guò)為數據庫表增加一個(gè) version 字段來(lái)實(shí)現。讀取出數據時(shí)，將此版本號一同讀出，之后更新時(shí)，對此版本號加一。此時(shí)，將提交數據的版本數據與數據庫表對應記錄的當前版本信息進(jìn)行比對，如果提交的數據版本號大于數據庫表當前版本號，則予以更新，否則認為是過(guò)期數據。
幾個(gè)分布式系統事務(wù)的實(shí)現機制：
分布式系統
事務(wù)
選擇理由
協(xié)議核心功能
備注
TiDB
TiKV 的事務(wù)采用的是 Percolator 模型，總體來(lái)說(shuō)就是一個(gè)經(jīng)過(guò)優(yōu)化的二階段提交（2PC）的實(shí)現
ElasticSearch
Kafka
ZooKeeper
HDFS
HBase
七、分片或region的調度
要設計很好的調度系統，就需要手機足夠多的信息，如每個(gè)節點(diǎn)的狀態(tài)；每個(gè)分片的狀態(tài)；節點(diǎn)或分片訪(fǎng)問(wèn)的QPS、吞吐量信息；節點(diǎn)的配置信息，如硬盤(pán)，內存等；