kafak入门(十一)：Kafka怎么保证可靠性？

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：核心设计与实践原理》