架構師手冊——幾個分布式系統架構設計原理

一、分布式一緻性協定

參考連結：https://www.jianshu.com/p/71b2729d3004

兩類一緻性(操作原子性與副本一緻性)

• 2PC，3PC協定：強調事務，用于保證屬于多個資料分片上的操作的原子性。這些資料分片可能分布在不同的伺服器上，2PC協定保證多台伺服器上的操作要麼全部成功，要麼全部失敗。
• Paxos，Raft協定：強調同一條資料的複制，用于保證同一個資料分片的多個副本之間的資料一緻性。當這些副本分布到不同的資料中心時，這個需求尤其強烈。

下面講的是多個副本之間的資料一緻性。

分布式系統	分布式一緻性協定	選擇理由	協定核心功能	備注
TiDB	raft協定（強一緻性）	raft協定實作簡單	保證資料一緻性，完整複制日志到其它節點 leader選舉 同一時刻隻能保證有一個Leader，隻有leader可以複制日志	由于raft協定是2013年釋出，而TiDB釋出于2016年，時間剛好趕上了
ElasticSearch	Gossip	最終一緻性消息
Kafka
ZooKeeper	Zab協定
HDFS
HBase	通過HDFS進行資料備份。WAL(Write-ahead logging)	WAL的實作是HLog，HLog也是存儲在HDFS上的，是以HRegionServer崩潰了也不會導緻HLog的丢失，它也有備份。 需要注意的是，HBase Replication 是以 Column Family 為機關，每個CF都可以設定是否進行 Replication。 注意：HBase是強一緻性的

注意：

1.為什麼raft協定是強一緻性協定？因為超過半數成功後，認為是送出成功，然後隻有這些送出成功的節點才會對外服務，這樣就保證了app查到的資料是正确的資料（沒有回報确認的其它節點，即使成功了，也不會對外服務，隻有回報給leader成功，才會對外服務）

2.HBase中的Replication也是基于WAL的，其在主叢集的每個RegionServer程序内部起了一個叫做ReplicationSource的線程來負責Replication，同時在備叢集的每個RegionServer内部起了一個ReplicationSink的線程來負責接收Replication資料。ReplicationSource記錄需要同步的WAL隊列，然後不斷讀取WAL中的内容，同時可以根據Replication的配置做一些過濾，比如是否要複制這個表的資料等，然後通過replicateWALEntry這個Rpc調用來發送給備叢集的RegionServer，備叢集的ReplicationSink線程則負責将收到的資料轉換為put/delete操作，以batch的形式寫入到備叢集中。

3、提一下Mysql：Mysql是通過異步的方式讀取binlog然後存儲到slave叢集，肯定會導緻資料一緻性的延時，有時候寫入量大可能會延時幾小時。

二、分布式系統需要考慮的幾個基本問題

• 分片要盡量均勻的散落在不同的節點，均勻的目的：

1. 負載均衡，避免形成熱點；
2. 很重要的隐藏意義，即增加或減少節點，資料會重新進行均衡配置設定，動态的根據節點分片情況遷移資料（增加的節點剛開始是沒有資料的，這樣導緻各個增加節點資料不均勻，就會觸發分片重新配置設定；其實減少節點也會，因為減少後，可能導緻某些主分片或副本丢失，是以要重新拷貝副本，這個過程就會導緻資料不均勻，是以也會重新配置設定）

• 必須多副本，至少一個，且資料的主分片和副本必須不能在同一個節點上：如果隻有一個副本，且主分片和副本在一台機器上，那麼這台機器挂掉後，這塊資料就會丢失，這違背了分布式系統的設計初衷；
• 資料的散落方案：一種是按照 Key 做 Hash，根據 Hash 值選擇對應的存儲節點（ElasticSearch）；另一種是分 Range，某一段連續的 Key 都儲存在一個存儲節點上（HBase，TiDB）。
• 節點遷移需要控制速度，避免影響線上服務

三、資料存儲原理

分布式系統	概念	備注	其它說明
TiDB	Region
ElasticSearch	分布式存儲原理：ElasticSearch - 巍巍的個人頁面 - OSCHINA - 中文開源技術交流社群
Kafka	Broker，Partition	Broker：Kafka叢集中的一台或多台伺服器統稱broker. Partition：Topic實體上的分組，一個topic可以分為多個partion,每個partion是一個有序的隊列。partion中每條消息都會被配置設定一個 有序的Id(offset)，同一 topic 下的不同分區包含的消息是不同的。
ZooKeeper
HDFS
HBase	Region

四、分布式系統的叢集管理工具

分布式系統	叢集管理	備注	其它說明
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與事務

MVCC即樂觀鎖的一種實作方式。

樂觀鎖(MVCC)

何謂資料版本？即為資料增加一個版本辨別，在基于資料庫表的版本解決方案中，一般是通過為資料庫表增加一個 “version” 字段來實作。讀取出資料時，将此版本号一同讀出，之後更新時，對此版本号加一。此時，将送出資料的版本資料與資料庫表對應記錄的目前版本資訊進行比對，如果送出的資料版本号大于資料庫表目前版本号，則予以更新，否則認為是過期資料。

幾個分布式系統事務的實作機制：

分布式系統	事務	選擇理由	協定核心功能	備注
TiDB	TiKV 的事務采用的是 Percolator 模型，總體來說就是一個經過優化的二階段送出（2PC）的實作
ElasticSearch
Kafka
ZooKeeper
HDFS
HBase

七、分片或region的排程

要設計很好的排程系統，就需要手機足夠多的資訊，如每個節點的狀态；每個分片的狀态；節點或分片通路的QPS、吞吐量資訊；節點的配置資訊，如硬碟，記憶體等；