replication.factor
每個主題的partition都會有n個副本
這樣，在n-1個broker失效的情況下，仍然能從主題讀取資料或向主題寫入資料
複製係數n需要至少n個broker，而且會有n個資料副本
unclean.leader.election
如果設為true，當分割槽首領不可用時，我們允許不同步的副本(不在isr中)成為首領，需要承擔丟失資料和出現資料不一致的風險。
如果設為false，當分割槽首領不可用時，我們只允許同步的副本(在isr中)成為首領，但如果此時沒有同步的副本，我們只能等待原先的首領上線，降低了可用性。
min.insync.replcas
對於乙個包含3個副本的主題，如果min.insync.replcas被設為2，那麼至少要存在兩個同步副本才能向分割槽寫入資料
如果不滿足兩個同步副本，那麼broker會停止接受生產者的請求。嘗試傳送資料的生產者會受到notenoughreplica***ception異常。消費者仍然可以繼續讀取已有的資料。
這樣是為了避免在發生不完全選舉時資料的寫入和讀取出現非預期的行為
1)acks 0，1，-1/all
通過acks=all，保證訊息達到所有的副本
2)retries 重試次數
3)開發人員針對異常進行處理
例如將異常的訊息儲存起來，後續處理
1）group.id
消費者組，同乙個消費者組中的消費者只會分到主題分割槽的乙個子集
2）auto.offset.reset
在沒有偏移量可提交時（比如消費者第一次啟動時）或者請求的偏移量在broker上不存在時(發生了rebalance)，消費者應該獲取什麼偏移量
earliest,消費者會從分割槽的開始位置讀取資料，會導致消費重複資料
lastest,消費者會從分割槽的末尾開始讀取資料，這樣可以減少處理重複資料，但很有可能會錯過一些訊息
3) enable.auto.commit
是否允許自動提交
4) auto.commit.interval.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，意...