1. CAP理論

　　1.1 Cosistency(一致性)

　　通過某個節點的寫操作結果對后面通過其他節點的讀操作可見。

　　如果更新數據后，并發訪問的情況下可立即感知該更新，稱為強一致性

　　如果允許之后部分或全部感知不到該更新，稱為弱一致性。

　　若在之后的一段時間（通常該時間不是固定的）后，一定可以感知到該更新，稱為最終一致性。

　　1.2 Availability(高可用性)

　　即是任何一個沒有發生故障的節點必須在有限的時間內返回合理的結果（不論是正確的還是錯誤的）。

　　1.3 Partition tolerance（分區容錯性）

　　部分節點宕機或者是無法與其他節點通信時，各分區間還可以保持分部式系統的功能，比如上海和北京兩個網絡分區，當上海分區光纖或其他原因導致網絡不通時，北京上海兩個分區之間不可通信，但是最起碼要保證北京的分區中的分布式系統功能可用。

　　1.4 CAP理論

　　分布式系統中，一致性，可用性，分區容忍性最多只可同時滿足兩個，但是一般分區容錯性都是需要保障的，因此很多時候都是在可用性和一致性之間做權衡。如下一幅圖講解了CP和AP的兩種模式的具體表現形式：

　　首先看CP模式，N1和N2之間代表了網絡通信，C表示客戶端，X表示新寫入的數據,Y表示舊數據，當C向N2發起請求時，由于N2與N1之間網絡通信異常，會導致N2不能同步到N1中的x,在保證一致性的情況下，此時N2不會正常返回處理結果，要么是等待網絡連接成功，將N1的Y獲取過來，保證數據一致，要么系統出現錯誤，這樣的情況是不能保證高可用的，但是保證了數據一致性。

　　AP模式下，N1和N2之間代表了網絡通信，C表示客戶端，X表示新寫入的數據,Y表示舊數據，當C向N2發起請求時，由于N2與N1之間網絡通信異常，會導致N2不能同步到N1中的X，但是N2不會等待N1連接成功，或是返回錯誤信息，而是返回之前老的數據x,這樣系統能夠正常的運行，但是數據的一致性并沒有保證，此時選擇了系統的高可用方案。

　　1.5 一致性的方案

　　1.5.1 Master-slave(主從模式)

　　RDBMS的讀寫分離即為典型的Master-slave方案

　　同步復制可保證強一只性，但是會行影響性能（因為Master必須要等待所有的salve都接收到到更新才能返回）

　　異步復制提高可用性，但是會降低一致性，因為Master只需要自己寫操作完成，就立即返回，同時向Slave進行復制，這期間可能會出現某個或多個Slave由于網絡或其他原因沒有更新到數據，造成數據不一致性。

　　1.5.2 WNR

　　主要用于去中心化（P2P）的分布式系統中。DynamoDB與Cassandra即采用此方案,N代表副本數，W代表每次寫操作要保證的最少寫成功的副本數，R代表每次讀至少讀取的副本數,當W+R>N時，可保證每次讀取的數據至少有一個副本具有最新的更新,多個寫操作的順序難以保證，可能導致多副本間的寫操作順序不一致，Dynamo通過向量時鐘保證最終一致性。這里可以通過時間戳或者是自增主鍵之類的方式來保證過濾出讀取的最新的數據。

　　1.5.3 Paxos及其變種

　　Google的Chubby，Zookeeper的Zab，RAFT等

2. Kafka的數據復制（Replica）

　　Kafka提供了Replica保證了數據一致性

　　2.1 Replica

　　當某個Topic的replication-factor為N切N大于1時，每個Partition都會有N個副本（Replica）,Replica的個數小于等于Broker數，即對每個Partition而言每個Broker上只會有一個Replica，因此可用Broker ID表示Replica，所有Partition的所有Replica默認情況會均勻分布到所有Broker上，如圖：

　　圖中可以看到，Broker中存的是Topic2的Partition0和Topic2的Partition2的Replica,但是在Broker2中卻存了Topic2的Partition1和Topic2的Partition0的Replica，所以默認的Partition都是分布在集群節點上的，replica也一樣。這就可以保證到某個節點掛掉之后，其他的節點中保存的replica仍然可以向消費者推送或被拉取消息，保證消息不丟失。

　　注意：

　　假如當前我們搭建了三個Broker的集群，但是我此時指定4個Replica時，會出現org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication factor: 4 larger than available brokers: 3異常，如圖：

　2.2?Data Replication（數據復制）要解決的問題

　　2.2.1 如何Propagate（備份）消息

　　如下圖：

　　當producer想leader節點發送消息時，其余follower節點（個人理解跟slave類似）將會如其他mq的consumer一樣去從主節點的topic中將數據拉取或被推送到自身節點中。這樣當leader節點掛掉之后，consumer訪問集群時，仍然可以從其他的follower中獲取到最新數據，防止了數據丟失。

　　2.2.2 何時Commit

　　ISR:?Leader會維護一個與其基本保持同步的Replica列表，該列表稱為ISR（in-sync Replica）,如果一個Follower比Leader落后太多，或者超過一定時間未發起數據復制請求，則Leader將其從ISR中移除,當ISR中所有Replica都向Leader發送ACK時，Leader即Commit（告訴Producer消息發送成功）。

　　Commit策略

　　1. 在Server中配置

　　replica.lag.time.max.ms：默認100000，最大未發起數據復制請求的時間。

　　replica.lag.max.messages：最大落后消息數，根據自身需要配置

　　2. Topic配置

　　min.insync.replicas=1： ISR列表最小個數，默認1，只有當request.required.acks為-1時才生效，如果ISR中的副本數少于min.insync.replicas配置的數量時，客戶端會返回異常：org.apache.kafka.common.errors.NotEnoughReplicasExceptoin: Messages are rejected since there are fewer in-sync replicas than required。

　　3. Produce配置

　　request.required.acks=1，默認為1，roducer發送數據到leader，leader寫本地日志成功，返回客戶端成功；此時ISR中的副本還沒有來得及拉取該消息，leader就宕機了，那么此次發送的消息就會丟失，當為-1時，當producer設置request.required.acks為-1時，min.insync.replicas指定replicas的最小數目（必須確認每一個repica的寫數據都是成功的），如果這個數目沒有達到，producer會產生異常。

　　2.2.3?如何處理Replica恢復

　　如圖：

　　1. 可以看到SR={A,B,C},Leader(A)節點中存在m1,m2,m3三條消息，F(B)存在m1,m2兩條消息，f（c）只存在m1一消息，所以這里只會提交m1這條消息，因為m2這條消息還沒有在ISR中完成復制。它只會提交三個ISR中都存在的消息。

　　2. 當L(A)在將消息m2復制到B,C之后掛掉，此時ISR中只有{B,C}，B被選舉成為新的主節點，當m2,m1都存在于B,C節點中時，B將會提交m1,m2兩條消息，不會提交m3消息。

　　3. 此時消息將都會發送到B節點上，C節點同步了B節點中的新發的消息m4,m5之后，將會提交m4,m5.

　　5.此時A節點連接集群成功或重啟，可以使用了，它會從B節點中同步從m1,到m5的消息，直到它的消息與B和C中的一致為止，此時的Replica將會變成ISR={A,B,C},完成了Replica的恢復。這里我們發現m3并沒有存在了，這里并不是丟失了，只是當沒有主節點提交m3這條消息時，它將會自動反饋到Producer，Producer會重試，或做其他處理，當重試成功后可能m3消息將會append到m5的后面，所以consumer消費消息時，我們保證的順序性不是producer發送消息的順序，而是commit時的順序。