kafka會丟消息主要集中在兩個環節

消息落盤時機

消息落盤有異步刷新和同步刷新兩種，明顯異步刷新的可靠性要高很多。但在某些場景下追求性能而忽略可靠性，可以啟用。

消息存儲維護

持久化存儲，這句話不是說來玩的。Oracle／MySQL做了這么久的存儲，其中的災難恢復工具等都非常完備并形成體系（出問題你能找到人并能解決問題）kafka的存儲誰特么知道～工具又特么的少！

另外就是落盤的存儲介質，如果不做raid，那么單盤存在損壞的可能；做了raid，則成本上升。如果做多集copy，則存在網絡同步延時所帶來的瞬間數據不一致。

小結：kafka你要做到完全不丟數據（在非大災大難的情況下，比如機房被原子彈轟炸；或者raid被誤操作弄錯同步時間或者低格等），是完全可以的。代價就是丟失一定的性能。

所以kafka我一般用在業務允許少量數據丟失但整體吞吐量非常大的場景（比如日志采集），數據統計分析（卻少幾百條數據不會對億萬級的樣本空間產生什么影響）。

kafka也可以用在兩個可靠存儲之間做數據同步，比如MySQL(寫)->MySQL(度)，因為MySQL(寫)保證了數據可被重放，所以kafka出問題時恢復速度和恢復可靠程度是可以得到保證的

?

kafka環節丟失數據，常見的kafka環節丟失數據的原因有：

如果auto.commit.enable=true，當consumer fetch了一些數據但還沒有完全處理掉的時候，剛好到commit interval出發了提交offset操作，接著consumer crash掉了。這時已經fetch的數據還沒有處理完成但已經被commit掉，因此沒有機會再次被處理，數據丟失。

網絡負載很高或者磁盤很忙寫入失敗的情況下，沒有自動重試重發消息。沒有做限速處理，超出了網絡帶寬限速。kafka一定要配置上消息重試的機制，并且重試的時間間隔一定要長一些，默認1秒鐘并不符合生產環境（網絡中斷時間有可能超過1秒）。

如果磁盤壞了，會丟失已經落盤的數據

單批數據的長度超過限制會丟失數據，報kafka.common.MessageSizeTooLargeException異常
解決：

Consumer side:fetch.message.max.bytes- this will determine the largest size of a message that can be fetched by the consumer.Broker side:replica.fetch.max.bytes- this will allow for the replicas in the brokers to send messages within the cluster and make sure the messages are replicated correctly. If this is too small, then the message will never be replicated, and therefore, the consumer will never see the message because the message will never be committed (fully replicated).Broker side:message.max.bytes- this is the largest size of the message that can be received by the broker from a producer.Broker side (per topic):max.message.bytes- this is the largest size of the message the broker will allow to be appended to the topic. This size is validated pre-compression. (Defaults to broker'smessage.max.bytes.)

partition leader在未完成副本數follows的備份時就宕機的情況，即使選舉出了新的leader但是已經push的數據因為未備份就丟失了！
kafka是多副本的，當你配置了同步復制之后。多個副本的數據都在PageCache里面，出現多個副本同時掛掉的概率比1個副本掛掉的概率就很小了。（官方推薦是通過副本來保證數據的完整性的）

kafka的數據一開始就是存儲在PageCache上的，定期flush到磁盤上的，也就是說，不是每個消息都被存儲在磁盤了，如果出現斷電或者機器故障等，PageCache上的數據就丟失了。
可以通過log.flush.interval.messages和log.flush.interval.ms來配置flush間隔，interval大丟的數據多些，小會影響性能但在0.8版本，可以通過replica機制保證數據不丟，代價就是需要更多資源，尤其是磁盤資源，kafka當前支持GZip和Snappy壓縮，來緩解這個問題 是否使用replica取決于在可靠性和資源代價之間的balance

?

消息發送方式

想清楚Kafka發送的消息是否丟失，需要先了解Kafka消息的發送方式。

Kafka消息發送分同步(sync)、異步(async)兩種方式

默認是使用同步方式，可通過producer.type屬性進行配置；

Kafka保證消息被安全生產，有三個選項分別是0,1,-1

通過request.required.acks屬性進行配置：

0代表：不進行消息接收是否成功的確認(默認值)；

1代表：當Leader副本接收成功后，返回接收成功確認信息；

-1代表：當Leader和Follower副本都接收成功后，返回接收成功確認信息；

六種發送場景

兩個維度相交，生成六種情況，如下圖：

?

消息丟失的場景

網絡異常

acks設置為0時，不和Kafka集群進行消息接受確認，當網絡發生異常等情況時，存在消息丟失的可能；

客戶端異常

異步發送時，消息并沒有直接發送至Kafka集群，而是在Client端按一定規則緩存并批量發送。在這期間，如果客戶端發生死機等情況，都會導致消息的丟失；

緩沖區滿了

異步發送時，Client端緩存的消息超出了緩沖池的大小，也存在消息丟失的可能；

Leader副本異常

acks設置為1時，Leader副本接收成功，Kafka集群就返回成功確認信息，而Follower副本可能還在同步。這時Leader副本突然出現異常，新Leader副本(原Follower副本)未能和其保持一致，就會出現消息丟失的情況；

以上就是消息丟失的幾種情況，在日常應用中，我們需要結合自身的應用場景來選擇不同的配置。

想要更高的吞吐量就設置：異步、ack=0；想要不丟失消息數據就選：同步、ack=-1策略

附：Kafka備份策略，不理解的可以看我的另一篇文章《Kafka消息的備份策略》

總結

以上是生活随笔為你收集整理的kafka丢消息的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。