kafka的replica机制能保证不丢数据吗

不能

kafka的replica机制完美的在可用性和一致性之间做了平衡，但是他仍然有丢失数据的风险

消息写入主分片后，flowers会定时来拉取，如果超过时间都不来拉，直接就判定他死了，直接从isr中踢出去

如果拉的太慢，相比主分片有较大延迟，比如副本分片所有的broker有gc异常，超过一个阈值认为是慢follower，也可以踢出去

比如这个阈值设置为10，凡是延迟在10以内的都是isr成员，只有他们全都到主分片拉到消息，这条消息才能commit

 

高可用体现在哪呢？

相比于所有副本拉到消息才commit，isr甚至可以把所有follower都踢掉，极端情况下只要维护一个主分片

最大效率的保证同步速度

 

为啥会丢失数据呢？

数据写入主分片后，followers还没有跟上，主分片上这时候会多几条数据，这几条数据因为没有被拉到follower，导致不能commit

此时如果主分片所在的broker宕机，没有提交的这几条消息就丢了

 

如何保证严格数据不丢失？

同步发送，每条消息收到ack之后再发送下一条，收不到ack就一直重试，直到开发者意识到

问题

同步发送效率太低，异步批量发送才能保证效率

 

如何兼顾效率和不丢失数据？

最终一致性和补偿机制

异步批量发，发送失败的数据就在callback中写会文件，定时重试。

 

上面讨论的是isr机制导致的数据丢失，kafka生产者造成数据丢失还有其他情况

1.发送数据太快，缓冲区总是满导致内存溢出，造成数据丢失

2.没有关闭unclean.leader.election.enable，选出了非ISR中的成员当leader

3.即使选举使用isr中的成员，isr中的follower没有跟上，leader宕机，也会丢数据(isr管理机制就是replica机制，replica机制也不能保证完全不丢数据)

4.发送数据时单批数据超过限制会丢数据

5.kafka宕机重启会丢数据，丢多少取决于刷新磁盘的时间频率和消息条数