总结：几个分布式系统架构设计原理
一、分布式一致性協議
參考鏈接：https://www.jianshu.com/p/71b2729d3004
兩類一致性(操作原子性與副本一致性)
-
2PC，3PC協議：強調事務，用于保證屬于多個數據分片上的操作的原子性。這些數據分片可能分布在不同的服務器上，2PC協議保證多臺服務器上的操作要么全部成功，要么全部失敗。
-
Paxos，Raft協議：強調同一條數據的復制，用于保證同一個數據分片的多個副本之間的數據一致性。當這些副本分布到不同的數據中心時，這個需求尤其強烈。
下面講的是多個副本之間的數據一致性。
| 分布式系統 | 分布式一致性協議 | 選擇理由 | 協議核心功能 | 備注 |
| TiDB | raft協議（強一致性） | raft協議實現簡單 |
| 由于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集群，肯定會導致數據一致性的延時，有時候寫入量大可能會延時幾小時。
二、分布式系統需要考慮的幾個基本問題
- 分片要盡量均勻的散落在不同的節點，均勻的目的：
- 必須多副本，至少一個，且數據的主分片和副本必須不能在同一個節點上：如果只有一個副本，且主分片和副本在一臺機器上，那么這臺機器掛掉后，這塊數據就會丟失，這違背了分布式系統的設計初衷；
- 數據的散落方案：一種是按照 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、吞吐量信息；節點的配置信息，如硬盤，內存等；
總結
以上是生活随笔為你收集整理的总结：几个分布式系统架构设计原理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 分布式：分布式系统的设计
- 下一篇： ZK（1）——分布式系统概念与ZK简介