CAP理論

1. Consistency
2. Availability
3. Partition tolerance

CAP理論：分佈時系統中，一致性，可用性，分割槽容性，最多值可能滿足倆個，一般分錯容錯性要求由保障，因此很多時候在可用性一致性之間做權衡

一致性的方案

1. Master-slave

• RDBMS的讀寫分離就是典型的Master-slave方案
• 同步複製可以保證強一致性，但是會贏下給可用性
• 非同步複製可提供高可用性但會降低一致性

2. WNR

• 去中心化P2P,分散式系統中。
• N代表副本數目，W代表每次操作要保證最少寫成功的副本書，R代表每次至少讀取副本數
• W+R > N，可保證每次讀取的資料至少由一個副本具有最新的更新
• 多個寫操作的順序難以保證，可能導致多個副本之間的寫的順序不一致。

3. Paxos及其變種

• zookeeper的Zab(Zookeeper 原子廣播),RAFT等

Kafka Replica

• 當某個Topic的replication-factor為N且N大於1時，每個Partition都會有N個副本（replica）
• Replica的個數小於等於Broker數，即對每個Partition而言每個Broker上只會有一個Replica,因此可用Broker ID表示Replica
• 所有Partition的所有Replica預設情況都會均勻分佈到所有Broker上

Data Replication要解決的問題

讀寫都在leader 上進行

什麼時候Commit

1. ISR

• Leader會維護一個與其保持基本同步的Replica列表，該列表稱之為(in-sync Replica)
• 如果一個Follower比Leader落後太多，或者超過一定時間沒有發起複製請求，則Leader將其從ISR中移除
• 當ISR中所有Replicat都向Leader傳送ACK,Leader即Commit

2. Commit策略

• Server 配置 replica.lag.time.max.ms=1000 replica.lag.max.messages=4000
• Topic配置 min.insync.replicas=1
• Producer配置 request.required.acks=0

如何處理Replica全部宕機

1. 等待ISR中任一Replica回覆，並選它為Leader,並選它為Leader

• 等待時間長，降低可用性
• 或ISR中所有的Replica都無法回覆或者資料丟失，則該Partition將永不可用

2. 選擇第一個恢復的Replica為新的Leader,無論它是否在ISR中

• 並未包含所有已被之前Leader Commit過的訊息，因此會導致資料丟失
• 可用性比較高