Kafka可靠性分析
- 多副本。
就Kafka而言,越多的副本数越能够保证数据的可靠性,副本数可以在创建主题时配置,也可以在后期修改,不过副本数越多也会引起磁盘、网络带宽的浪费,同时会引起性能的下降。一般而言,设置副本数为3即可满足绝大多数场景对可靠性的要求。部分业务比如银行对可靠性要求比较高,会副本数到5。
- 指定ISR集合中最小的副本数。
min.insync.replicas参数(默认值为1)来作为辅助(配合acks=-1来使用),这个参数指定了ISR集合中最小的副本数,如果不满足条件就会抛出NotEnoughReplicasException或NotEnoughReplicasAfterAppendException。在正常的配置下,需要满足副本数 > min.insync.replicas参数的值。一个典型的配置方案为:副本数配置为 3,min.insync.replicas 参数值配置为 2。注意 min.insync.replicas参数在提升可靠性的时候会从侧面影响可用性。试想如果ISR中只有一个leader副本,那么最起码还可以使用,而此时如果配置 min.insync.replicas>1,则会使消息无法写入。
- 生产者客户端参数 acks。
acks=-1 (客户端还可以配置为 all,含义与 -1 一样) 可以最大程度地提高消息的可靠性。
对于 acks = 1的配置,生产者将消息发送到 leader 副本,leader 副本在成功写入本地日志之后会告知生产者已经成功提交。如果此时 ISR 集合的 follower 副本还没来得及拉取到 leader 中新写入的消息, leader 就宕机了,那此次发送的消息就会丢失。
- 生产者消息发送时设置失败通知。
消息发送的3种模式,即发后即忘、同步和异步。
对于发后即忘的模式,不管消息有没有被成功写入,生产者都不会收到通知,那么即使消息写入失败也无从得知,因此发后即忘的模式不适合高可靠性要求的场景。
如果要提升可靠性,那么生产者可以采用同步或异步的模式,在出现异常情况时可以及时获得通知,以便可以做相应的补救措施,比如选择重试发送(可能会引起消息重复)。
- retries 参数配置重试机制。
客户端内部本身提供了重试机制来应对这种类型的异常,通过 retries 参数即可配置。默认情况下,retries参数设置为0,即不进行重试,对于高可靠性要求的场景,需要将这个值设置为大于 0 的值。
- 消费者 enable.auto.commit 参数。
默认值为 true,即开启自动位移,容易带来重复消费和消息丢失。可以将 enable.auto.commit 参数设置为 false 来执行手动位移提交。
kafka入门文章
https://blog.csdn.net/sinat_32502451/category_12465196.html
资料来源
《深入理解Kafka:核心设计与实践原理》