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：核心设计与实践原理》
原文地址:https://blog.csdn.net/sinat_32502451/article/details/136018501
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.7code.cn/show_67535.html
如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！
