https://www.zhihu.com/question/34842764/answer/138125661
kafka使用high api如何确保不丢失消息,不重复发送,消息只读取一次?
虽然low api可以通过offset来实现,但是感觉好麻烦
作者:雨夜偷牛的人
链接:https://www.zhihu.com/question/34842764/answer/138125661
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
那么,如何确保非极端环境下,Kafka 不丢数据,以及 Kafka 集群尽可能稳定呢?
既然是极端环境的探讨,也就意味着能碰到的几率是非常低的,几率有多少我没统计过,其中第二种情况在业务中时常遇到。
链接:https://www.zhihu.com/question/34842764/answer/138125661
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
首先说明,Kafka 的设计就是 at-least-once 的
那么,如何确保非极端环境下,Kafka 不丢数据,以及 Kafka 集群尽可能稳定呢?
- Producer 端设置 ack 为 all(或者说尽可能越多越好,但实际生产里集群实例过多,这样设置会影响性能,因此根据具体情况来定),即 确保所有 replication 都拿到数据的时候,send 方法才得以返回,以此来判断数据是否发送成功,那么理论上来说,此时发送成功的数据都不会丢失;
- unclean.leader.election.enable 设置为 false(默认参数为 true),意思是,当存有你最新一条记录的 replication 宕机的时候,Kafka 自己会选举出一个主节点,如果默认允许还未同步你最新数据的 replication 所在的节点被选举为主节点的话,你的数据将会丢失,因此这里应该按需将参数调控为 false;
- auto.offset.reset 参数设置为 earliest 避免出现 offset 丢失的时候,跳过需要消费的数据的情况,准确来说这里并非丢失,即使因为参数配置的问题出现跳过的情况,也可以通过前置 offset 找回历史消息;
- 数据持久化的时间需要设置业务足够接受的程度,我自己业务上使用就是能保证我的数据持久化时间为8个小时,超过8个小时的数据将被清空。
即使这样配置了,Kafka 在极端环境下也并非确保绝对不丢数据!!!
既然是极端环境的探讨,也就意味着能碰到的几率是非常低的,几率有多少我没统计过,其中第二种情况在业务中时常遇到。
- 根据 Kafka 官方文档说明,Producer 发送消息持久化到 Kafka 得到 ack 的回馈这段过程中,基于性能的考虑,Kafka 并没有及时把数据落盘的,而是将数据放到内存(FS cache)中,并周期性的落盘(从磁盘监控也可以看的出来),如果数据未及时落盘,如遇到服务器断电宕机,则数据丢失;
- 实际业务中,对数据可靠性较高的场景我建议手动提交 offset,自动提交 offset 会出现一个比较尴尬的情况,在业务应用被 kill 之前, A 消息的offset 可能被提交了,然而 A 消息在应用系统中尚未执行完毕,且状态都保存在了内存中,无法保留,此时重启应用将不会继续消费 A 消息,而是神不知鬼不觉的跳过。当然这种情况也并非算得上丢失数据,重置 offset 一样可以找的回来,但是手动提交 offset 可以避免这种诡异的情况发生。
Kafka HA 如何保障?
官方的意思是尽可能多节点集群部署,节点数尽可能大于等于3,并且 replication 数量也是大于等于3,那么当 replication 数量为 N 时,ack 设置为 all,这种情况下,就能确保 N-1台机子宕机的时候,数据仍能保持不丢。
Kafka本身是不能保证“消息只读一次”,需要借助其他办法保证,比如2PC等,但是如果使用分布式事务的话,会影响吞吐量的。另外Kafka本身就是为了高吞吐量而设计的,如果非要保证“消息只读取一次”,可以使用JMS。
另外,说句题外话——每一个框架被设计的时候,都有考虑特定的使用场景的,比如Kafka就比较适合高吞吐量并且允许少量数据丢失的场景,所以一定要根据应用业务和使用场景来做技术选型。
另外,说句题外话——每一个框架被设计的时候,都有考虑特定的使用场景的,比如Kafka就比较适合高吞吐量并且允许少量数据丢失的场景,所以一定要根据应用业务和使用场景来做技术选型。