kafka使用high api如何确保不丢失消息，不重复发送，消息只读取一次？

Myth丶恋晨 2021-06-24 15:59 300阅读 0赞

[https://www.zhihu.com/question/34842764/answer/138125661][https_www.zhihu.com_question_34842764_answer_138125661]

# kafka使用high api如何确保不丢失消息，不重复发送，消息只读取一次？ #

虽然low api可以通过offset来实现，但是感觉好麻烦

作者：雨夜偷牛的人  
链接：https://www.zhihu.com/question/34842764/answer/138125661  
来源：知乎  
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

**首先说明，Kafka 的设计就是 at-least-once 的**

那么，如何确保非极端环境下，Kafka 不丢数据，以及 Kafka 集群尽可能稳定呢？

1.  Producer 端设置 ack 为 all（或者说尽可能越多越好，但实际生产里集群实例过多，这样设置会影响性能，因此根据具体情况来定），即 确保所有 replication 都拿到数据的时候，send 方法才得以返回，以此来判断数据是否发送成功，那么**理论上**来说，此时发送成功的数据都不会丢失；
2.  unclean.leader.election.enable 设置为 false（默认参数为 true），意思是，当存有你最新一条记录的 replication 宕机的时候，Kafka 自己会选举出一个主节点，如果默认允许还未同步你最新数据的 replication 所在的节点被选举为主节点的话，你的数据将会丢失，因此这里应该按需将参数调控为 false；  
    
3.  auto.offset.reset 参数设置为 earliest 避免出现 offset 丢失的时候，**跳过**需要消费的数据的情况，准确来说这里并非丢失，即使因为参数配置的问题出现跳过的情况，也可以通过前置 offset 找回历史消息；  
    
4.  数据持久化的时间需要设置业务足够接受的程度，我自己业务上使用就是能保证我的数据持久化时间为8个小时，超过8个小时的数据将被清空。

**即使这样配置了，Kafka 在极端环境下也并非确保绝对不丢数据！！！**

既然是极端环境的探讨，也就意味着能碰到的几率是非常低的，几率有多少我没统计过，其中第二种情况在业务中时常遇到。

1.  根据 Kafka 官方文档说明，Producer 发送消息持久化到 Kafka 得到 ack 的回馈这段过程中，基于性能的考虑，Kafka 并没有及时把数据落盘的，而是将数据放到内存（FS cache）中，并周期性的落盘（从磁盘监控也可以看的出来），如果数据未及时落盘，如遇到服务器断电宕机，则数据丢失；
2.  实际业务中，对数据可靠性较高的场景我建议手动提交 offset，自动提交 offset 会出现一个比较尴尬的情况，在业务应用被 kill 之前， A 消息的offset 可能被提交了，然而 A 消息在应用系统中尚未执行完毕，且状态都保存在了内存中，无法保留，此时重启应用将不会继续消费 A 消息，而是神不知鬼不觉的跳过。当然这种情况也并非算得上丢失数据，重置 offset 一样可以找的回来，但是手动提交 offset 可以避免这种诡异的情况发生。

**Kafka HA 如何保障？**  
官方的意思是尽可能多节点集群部署，节点数尽可能大于等于3，并且 replication 数量也是大于等于3，那么当 replication 数量为 N 时，ack 设置为 all，这种情况下，就能确保 N-1台机子宕机的时候，数据仍能保持不丢。

另外补充，既然是at-least-once，肯定会出现重复消费的情况，这个不难解决，Consumer 保持无状态和幂等性就可以了。

Kafka本身是不能保证“消息只读一次”，需要借助其他办法保证，比如2PC等，但是如果使用分布式事务的话，会影响吞吐量的。另外Kafka本身就是为了高吞吐量而设计的，如果非要保证“消息只读取一次”，可以使用JMS。  
另外，说句题外话——每一个框架被设计的时候，都有考虑特定的使用场景的，比如Kafka就比较适合高吞吐量并且允许少量数据丢失的场景，所以一定要根据应用业务和使用场景来做技术选型。

[https_www.zhihu.com_question_34842764_answer_138125661]: https://www.zhihu.com/question/34842764/answer/138125661

发表评论取消回复

表情：

评论列表（有 0 条评论，300人围观）

还没有评论，来说两句吧...

相关阅读

相关 kafka如何保证消息不丢失？

文章目录一、分析消息丢失场景 1、kafka消息传输过程 2、消息丢失的几种情况二、如何解决 1、kafka pro

我不是女神ヾ/ 2024年04月01日 19:42/ 0 赞/ 14 阅读

相关 90、RabbitMQ如何确保消息发送？消息接收？

RabbitMQ如何确保消息发送？消息接收？发送方确认机制接收方确认机制发送方确认机制信道需要设置为 confirm 模式，则所有在信道

我不是女神ヾ/ 2024年03月17日 23:12/ 0 赞/ 20 阅读

相关 RabbitMQ 消息丢失的场景，如何保证消息不丢失？

一.RabbitMQ消息丢失的三种情况 ![ebb529a6f2f9a2f10fa91d5e0c321847.png][] 第一种：生产者弄丢了数据。生产者将数据

àì夳堔傛蜴生んèń/ 2023年09月26日 18:46/ 0 赞/ 57 阅读

相关 kafka如何保证消息不丢失不被重复消费

文章目录 [kafka如何保证消息不丢失不被重复消费][kafka] [消息的发送机制][Link 1] [消息的接

你的名字/ 2022年12月27日 14:01/ 0 赞/ 106 阅读

相关 Kafka 消息丢失和消息重复消费

1. 消息丢失 1. producer 的`acks`参数值设置为‘0’或者‘1’，不等待服务器确认或者只让leader确认 > 解决方法：将`ack

系统管理员/ 2022年12月05日 12:11/ 0 赞/ 197 阅读

相关消息中间件如何保证不丢失消息

丢失数据场景丢数据一般分为三种，一种是生产者发送消息失败，一种是mq把消息丢了，一种就是消费时将消息丢了。下面从rabbitmq和kafka分别说一下，丢失数据的场景：

快来打我*/ 2022年11月18日 04:38/ 0 赞/ 310 阅读

相关 kafka使用high api如何确保不丢失消息，不重复发送，消息只读取一次

首先说明，Kafka 的设计就是 at-least-once 的那么，如何确保非极端环境下，Kafka 不丢数据，以及 Kafka 集群尽可能稳定呢？ 1.

快来打我*/ 2022年06月04日 09:42/ 0 赞/ 109 阅读

相关关于kafka 保证消息不丢失问题

kafka 保证消息不丢失。原因如下有： 1）生产者如果异步发送，会造成消息丢失，发送的过程中kafka会先把消息缓存起来。然后批量发送。若批量发送之前client宕机会造

港控/mmm°/ 2022年03月29日 16:40/ 0 赞/ 201 阅读

相关 Kafka消息保证不丢失

[https://blog.csdn.net/john2522/article/details/64555065][https_blog.csdn.net_john2522_a

ゝ一纸荒年。/ 2021年09月15日 05:50/ 0 赞/ 350 阅读

相关 kafka使用high api如何确保不丢失消息，不重复发送，消息只读取一次？

[https://www.zhihu.com/question/34842764/answer/138125661][https_www.zhihu.com_question_

Myth丶恋晨/ 2021年06月24日 15:59/ 0 赞/ 301 阅读