魚和熊掌不可兼得。系統設計需要根據具體的應用場景做出權衡。
系統設計者可以通過配置kafka，來得到不同程度的需求滿足。
每個kafka主題(topic)都分為多個分割槽(partitions)。每個分割槽可以具有多個副本(replica)，其中乙個副本是主分割槽(leader)。所有讀寫請求都由主分割槽提供。其他副本只需要與主分割槽(leader)保持同步(in-sync)，並實時複製所有最近的訊息。如果主分割槽掛了，則乙個同步副本(in-sync)將成為新的主分割槽(leader)。從而是整個集群繼續可用。
kafka的主從副本(每個分割槽具有多個副本)是kafka所有可靠性保證的核心。在多個副本中寫入訊息是，kafka可以在某個節點發生崩潰時也能保證訊息不丟。
什麼是同步副本(in-sync)？
除了主分割槽(leader)，滿足以下條件的分割槽副本也是同步副本(in-sync)：
不滿足以上條件的分割槽副本就是不同步的(out-of-sync)。有可能是節點掛掉從啟動了，也有可能是網路斷了一段時間。當不同步的副本趕上之後，滿足了上面的兩個條件，就也會成為同步分割槽(in-sync)。 這是乙個動態變化的過程。
如果某個in-sync的分割槽比較慢，會影響整個集群的相應速度，因為producer需要等所有的in-sync的副本確認提交(commit)訊息，才認為成功傳送；consumer也只能讀到提交(commit)的訊息。反而out-of-sync的分割槽不會影響效能，因為它不參與決策。
伺服器broker中的三個配置引數可影響kafka關於可靠訊息儲存的行為。
副本個數 replication.factor的權衡
副本個數越多，自然是越安全，但是也會越慢。因為需要同步的節點多。同時需要的磁碟空間也大。broker的數量要大於副本個數，在乙個broker上有多於1個的副本沒有意義。
如果對一致性要求很高，比如金融系統，可以設定為5。如果是日誌收集或者效能監控訊息收集，可以允許丟訊息，訊息量很大，那麼1或者2都可以。
min.insync.replicas 最少的in-sync的節點數
只有所有in-sync的節點都commit了，訊息才算提交了(commit)。如果總的replica是3個，min.insync.replicas 是2，那麼是允許1個replica掛掉的。這樣只要lead還有乙個備份。當然你也可以選擇全部必須都是in-sync的，那樣不允許乙個replica掛掉。
unclean.leader.election.enable， 允許out-of-sync的分割槽成為lead嗎？預設是true
如果 min.insync.replicas 小於 replication.factor，就意味著允許有out-of-sync的副本存在。比如預設是3個備份，最小in-sync的節點數是2的情況下，就可能有乙個replica是out-of-sync的。這個時候如果lead掛了，那麼還有乙個in-sync的replica可以當lead，還是安全的。但是如果lead和in-sync的節點都掛了，只剩下乙個out-of-sync的節點了，怎麼辦？
允許這個節點成為主lead節點嗎？這個決定很重要，關係到可用性和可靠性還有一致性的選擇：
如果允許，那麼就有可能丟訊息，因為這個節點不包含很多已經提交的(commit)的訊息，而哪些已經提交的訊息很可能已經被消費過了。比如圖中，消費者已經消費到offset 900了，那個out-of-sync的節點才到350。這就是說這個新lead會產生新的從351以後的訊息。如果別的消費者去消費，就會消費到和之前的消費者不一樣的訊息。這樣就不一致了。
如果不允許，那就必須停止對外服務。這個cluster掛掉了。得等那兩個in-sync的節點恢復好，這可能需要比較長的時間。會影響系統的可用性。
整個系統的一致性和可靠性也不完全是伺服器broker端可以決定的。客戶端在生產訊息和消費訊息的時候也可以做出選擇，也需要做出乙個配合。我們下次繼續分享。
關注的多的話我會嘗試做成動畫來演示一下整個過程。
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
保證一致性嗎 分布式系統 一致性協議
一致性模型本質上是程序與資料儲存的約定，通過一致性模型我們可以理解和推理在分布式系統中資料複製需要考慮的問題和基本假設。那麼，一致性模型的具體實現有一些呢？本文會介紹一致性協議實現的主要思想和方法。一致性協議描述了特定一致性模型的實際實現。一致性模型就像是介面，而一致性協議就像是介面的具體實現。一致...
如何保證Session一致性
session同步法 多台web server互相同步資料，缺點是水平擴充套件受限，因為每台web server都是儲存所有的session 客戶端儲存法 session儲存到瀏覽器cookie中，每個客戶端只要儲存乙個使用者的資料了。缺點是占用外網頻寬 大小受限 因為cookie有大小限制 反向 ...