- 生产者数据不丢失 Kafka的ack机制：在kafka发送数据的时候，每次发送消息都会有一个确认反馈机制，确保消息正常能够被收到，其中状态有0，1，-1. ack = 0：producer不等待broker同步完成的确认，继续发送下一条（批）信息。 ack = 1(默认)：producer要等待leader成功收到数据并确认，才发送下一条message。 ack = -1：producer得到follower确认，才发送下一条数据。 同步模式：ack设置为0，风险很大，一般不建议设置为0。即使设置为1，也会随着leader宕机丢失数据。所以如果要严格保证生产端数据不丢失，可设置为-1。 异步模式：也会考虑ack的状态，除此之外，异步模式下的有个buffer，通过buffer来进行控制数据的发送，有两个值来进行控制，时间阈值与消息的数量阈值，如果buffer满了数据还没有发送出去，有个选项是配置是否立即清空buffer。可以设置为-1，永久阻塞，也就数据不再生产。异步模式下，即使设置为-1。也可能因为程序员的不科学操作，操作数据丢失，比如kill -9，但这是特别的例外情况。
- 消费者数据不丢失 通过offset commit来保证数据的不丢失，kafka每次记录自己消费的offset数值，下次继续消费的时候，会接着上次的offset进行消费。 而offset的信息在kafka0.8版本之前保存在zookeeper中，在0.8版本之后保存到topic中，即使消费者在运行过程中挂掉了，再次启动的时候会找到offset的值，找到之前消费消息的位置，接着消费，由于 offset 的信息写入的时候并不是每条消息消费完成后都写入的，所以这种情况有可能会造成重复消费，但是不会丢失消息。 唯一例外的情况是，我们在程序中给原本做不同功能的两个consumer组设置 KafkaSpoutConfig.bulider.setGroupid的时候设置成了一样的groupid，这种情况会导致这两个组共享同一份数据，就会产生组A消费partition1，partition2中的消息，组B消费partition3的消息，这样每个组消费的消息都会丢失，都是不完整的。 为了保证每个组都独享一份消息数据，groupid一定不要重复才行。
- broker数据不丢失 每个broker中的partition一般设置有replication(副本)个数，生产者写入的时候首先根据分发策略（有partition按partition，有key按key,都没有按轮询）写入到leader中，follower(副本)再跟leader同步数据，有了备份也可以保证消息数据不丢失。
本文转载自: https://blog.csdn.net/qq_45275284/article/details/129775641
版权归原作者 木良Duncan 所有， 如有侵权，请联系我们删除。
版权归原作者 木良Duncan 所有， 如有侵权，请联系我们删除。