常见的数据丢失
如果auto.commit.enable=true，当consumer fetch了一些数据但还没有完全处理掉的时候，刚好到commit interval出发了提交offset操作，接着consumer crash掉了。这时已经fetch的数据还没有处理完成但已经被commit掉，因此没有机会再次被处理，数据丢失。
网络负载很高或者磁盘很忙写入失败的情况下，没有自动重试重发消息。
如果磁盘坏了，会丢失已经落盘的数据
单批数据的长度超过限制会丢失数据，报kafka.common.MessageSizeTooLargeException异常
partition leader在未完成副本数follows的备份时就宕机的情况，即使选举出了新的leader但是已经push的数据因为未备份就丢失了
- kafka的数据一开始就是存储在PageCache上的，定期flush到磁盘上的，也就是说，不是每个消息都被存储在磁盘了，如果出现断电或者机器故障等，PageCache上的数据就丢失了。
如何解决数据丢失
producer端：
宏观上看保证数据的可靠安全性，肯定是依据分区数做好数据备份，设立副本数。broker端：
topic设置多分区，分区自适应所在机器，为了让各分区均匀分布在所在的broker中，分区数要大于broker数。分区是kafka进行并行读写的单位，是提升kafka速度的关键。-
Consumer端
consumer端丢失消息的情形比较简单：如果在消息处理完成前就提交了offset，那么就有可能造成数据的丢失。由于Kafka consumer默认是自动提交位移的，所以在后台提交位移前一定要保证消息被正常处理了，因此不建议采用很重的处理逻辑，如果处理耗时很长，则建议把逻辑放到另一个线程中去做。为了避免数据丢失，有两点建议：enable.auto.commit=false 关闭自动提交位移
在消息被完整处理之后再手动提交位移
