kafka的以下幾個基本特性保證了基本的可靠性：
生產者可以進行有關配置，使得不一定等到資料認為是已提交的之後，才進行下一輪的投遞，這是在可用性和一致性的之間的平衡
分割槽副本複製方式和同步條件：
複製係數及其意義
replication.factor：複製係數，指定了乙個分割槽的副本個數，預設是3，意思是每個分割槽在不同的broker上有三個資料副本，會比原來多三倍的空間。
borker.rack：配置機架引數，一般要把不同的broker配置在不同的機架上。
不完全首領選舉
具體方案：一般來說，只能在可用性和一致性之間抉擇。選擇集群不可用的情況；或者不一致的可用集群，此時副本會把就的訊息刪除，消費者無法獲取對應的訊息。
最少同步副本
多個副本的情況，可能出現部分副本不同的情況，為了保證一致性，需要設定min.insync.replicas引數，如果不同步或者不可用副本超過該數，則首領分割槽broker會停止接收生產者的資料，此時生產者會報錯；但是消費者仍然可讀。恢復可寫的情況，需要重新讓同步副本不小於該數。
兩種常見的不可靠場景
傳送確認的保證
生產者本身也要能處理自身的錯誤
消費者可靠性主要在兩方面：
輪詢設定，如果任務時間長，一定要保證心跳，心跳通過輪詢傳送
auto.offset.reset：如果沒有偏移量可以提交，或者請求的偏移量不存在時，消費者的行為：
kafka的資料可靠性保證
為保證 producer 傳送的資料，能可靠的傳送到指定的 topic，topic 的每個 partition 收到 producer 發 送的資料後，都需要向 producer 傳送 ack acknowledgement 確認收到 如果 producer 收到 ack，就會進行下一輪的傳送，否則...
Kafka如何保證資料可靠性
kafka的資料可靠性保證 1.副本資料同步策略 兩種副本資料同步策略 kafka選擇第二種 方案優點 缺點半數以上完成同步，就傳送ack 延遲低選舉新的leader時，容忍n臺節點的故障，需要2n 1個副本 全部完成同步，才傳送ack 選舉新的leader時，容忍n臺節點的故障，需要n 1個副本 ...
Kafka如何保證訊息的可靠性傳輸
1.消費端弄丟了資料 唯一可能導致消費者弄丟資料的情況，就是說，你消費到了這個訊息，然後消費者那邊自動提交了 offset，讓 kafka 以為你已經消費好了這個訊息，但其實你才剛準備處理這個訊息，你還沒處理，你自己就掛了，此時這條訊息就丟咯。這不是跟 rabbitmq 差不多嗎，大家都知道 kaf...