Kafka消息可靠性保证

2019独角兽企业重金招聘Python工程师标准>>>

参考：http://orchome.com/15

1、生产者端保证

生产者的端的消息确认机制的设置,生产者配置

发送端支持无确认、主分区确认 (主分区收到消息后发送确认回执)、以及主备分区确认(备用分区消息同步后主分区才发送确认回执)三种机制

配置项acks:

producer需要server接收到数据之后发出的确认接收的信号，此项配置就是指procuder需要多少个这样的确认信号。此配置实际上代表了数据备份的可用性。以下设置为常用选项：
（1）acks=0： 设置为0表示producer不需要等待任何确认收到的信息。副本将立即加到socket  buffer并认为已经发送。没有任何保障可以保证此种情况下server已经成功接收数据，同时重试配置不会发生作用（因为客户端不知道是否失败）回 馈的offset会总是设置为-1；
（2）acks=1： 这意味着至少要等待leader已经成功将数据写入本地log，但是并没有等待所有follower是否成功写入。这种情况下，如果follower没有成功备份数据，而此时leader又挂掉，则消息会丢失。
（3）acks=all： 这意味着leader需要等待所有备份都成功写入日志，这种策略会保证只要有一个备份存活就不会丢失数据。这是最强的保证。
（4）其他的设置，例如acks=2也是可以的，这将需要给定的acks数量，但是这种策略一般很少用。

2、Broker端保证

配置刷盘方式两种方式，通过配置消息数、以及配置刷盘时间间隔

# The number of messages to accept before forcing a flush of data to disk
#log.flush.interval.messages=10000

# The maximum amount of time a message can sit in a log before we force a flush
#log.flush.interval.ms=1000

3、消费者端保证

消费时的可靠性取决于消费者的读取逻辑， Kafka是不保存消息的任何状态的。

• At most once
• At least once  
• Exactly once  

三种模式需要自己按照业务实现，最容易实现就是 At least once ，两外两种在分布式系统中都不可能做到完全的绝对实现，只能无限靠近，降低错误率。

offset由客户端来控制

offset0.8.x是保存在zk中的，0.10.x是保存在topic：__consumer_offsets 中默认50个分区

转载于:https://my.oschina.net/chuibilong/blog/896685