學過大資料的同學應該都知道 kafka，它是分布式訊息訂閱系統，有非常好的橫向擴充套件性，可實時儲存海量資料，是流資料處理中介軟體的事實標準。本文將介紹 kafka 是如何保證資料可靠性和一致性的。
文章目錄
2 資料一致性
kafka 作為乙個商業級訊息中介軟體，訊息可靠性的重要性可想而知。本文從 producter 往 broker 傳送訊息、topic 分割槽副本以及 leader 選舉幾個角度介紹資料的可靠性。
在 kafka 0.8.0 之前，kafka 是沒有副本的概念的，那時候人們只會用 kafka 儲存一些不重要的資料，因為沒有副本，資料很可能會丟失。但是隨著業務的發展，支援副本的功能越來越強烈，所以為了保證資料的可靠性，kafka 從 0.8.0 版本開始引入了分割槽副本（詳情請參見 kafka-50）。也就是說每個分割槽可以人為的配置幾個副本（比如建立主題的時候指定replication-factor，也可以在 broker 級別進行配置default.replication.factor），一般會設定為3。
kafka 的分割槽多副本架構是 kafka 可靠性保證的核心，把訊息寫入多個副本可以使 kafka 在發生崩潰時仍能保證訊息的永續性。
如果我們要往 kafka 對應的主題傳送訊息，我們需要通過 producer 完成。前面我們講過 kafka 主題對應了多個分割槽，每個分割槽下面又對應了多個副本；為了讓使用者設定資料可靠性， kafka 在 producer 裡面提供了訊息確認機制。也就是說我們可以通過配置來決定訊息傳送到對應分割槽的幾個副本才算訊息傳送成功。可以在定義 producer 時通過acks引數指定（在 0.8.2.x 版本之前是通過request.required.acks引數設定的，詳見 kafka-3043）。這個引數支援以下三種值：
根據實際的應用場景，我們設定不同的acks，以此保證資料的可靠性。
另外，producer 傳送訊息還可以選擇同步（預設，通過producer.type=sync配置） 或者非同步（producer.type=async）模式。如果設定成非同步，雖然會極大的提高訊息傳送的效能，但是這樣會增加丟失資料的風險。如果需要確保訊息的可靠性，必須將producer.type設定為 sync。
在介紹 leader 選舉之前，讓我們先來了解一下 isr（in-sync replicas）列表。每個分割槽的 leader 會維護乙個 isr 列表，isr 列表裡面就是 follower 副本的 borker 編號，只有跟得上 leader 的 follower 副本才能加入到 isr 裡面，這個是通過replica.lag.time.max.ms引數配置的，具體可以參見 《一文了解 kafka 的副本複製機制》。只有 isr 裡的成員才有被選為 leader 的可能。
所以當 leader 掛掉了，而且unclean.leader.election.enable=false的情況下，kafka 會從 isr 列表中選擇第乙個 follower 作為新的 leader，因為這個分割槽擁有最新的已經 committed 的訊息。通過這個可以保證已經 committed 的訊息的資料可靠性。
綜上所述，為了保證資料的可靠性，我們最少需要配置一下幾個引數：
這裡介紹的資料一致性主要是說不論是老的 leader 還是新選舉的 leader，consumer 都能讀到一樣的資料。那麼 kafka 是如何實現的呢？
假設分割槽的副本為3，其中副本0是 leader，副本1和副本2是 follower，並且在 isr 列表裡面。雖然副本0已經寫入了 message4，但是 consumer 只能讀取到 message2。因為所有的 isr 都同步了 message2，只有 high water mark 以上的訊息才支援 consumer 讀取，而 high water mark 取決於 isr 列表裡面偏移量最小的分割槽，對應於上圖的副本2，這個很類似於木桶原理。
這樣做的原因是還沒有被足夠多副本複製的訊息被認為是「不安全」的，如果 leader 發生崩潰，另乙個副本成為新 leader，那麼這些訊息很可能丟失了。如果我們允許消費者讀取這些訊息，可能就會破壞一致性。試想，乙個消費者從當前 leader（副本0） 讀取並處理了 message4，這個時候 leader 掛掉了，選舉了副本1為新的 leader，這時候另乙個消費者再去從新的 leader 讀取訊息，發現這個訊息其實並不存在，這就導致了資料不一致性問題。
當然，引入了 high water mark 機制，會導致 broker 間的訊息複製因為某些原因變慢，那麼訊息到達消費者的時間也會隨之變長（因為我們會先等待訊息複製完畢）。延遲時間可以通過引數replica.lag.time.max.ms引數配置，它指定了副本在複製訊息時可被允許的最大延遲時間。
原文：
Kafka如何保證資料可靠性
kafka的資料可靠性保證 1.副本資料同步策略 兩種副本資料同步策略 kafka選擇第二種 方案優點 缺點半數以上完成同步，就傳送ack 延遲低選舉新的leader時，容忍n臺節點的故障，需要2n 1個副本 全部完成同步，才傳送ack 選舉新的leader時，容忍n臺節點的故障，需要n 1個副本 ...
kafka的資料可靠性保證
為保證 producer 傳送的資料，能可靠的傳送到指定的 topic，topic 的每個 partition 收到 producer 發 送的資料後，都需要向 producer 傳送 ack acknowledgement 確認收到 如果 producer 收到 ack，就會進行下一輪的傳送，否則...
kafka保證資料可靠性的方式
kafka的以下幾個基本特性保證了基本的可靠性 生產者可以進行有關配置，使得不一定等到資料認為是已提交的之後，才進行下一輪的投遞，這是在可用性和一致性的之間的平衡 分割槽副本複製方式和同步條件 複製係數及其意義 replication.factor 複製係數，指定了乙個分割槽的副本個數，預設是3，意...