1、消息发送
Kafka消息发送有两种方式：同步（sync）和异步（async），默认是同步方式，可通过producer.type属性进行配置。Kafka通过配置request.required.acks属性来确认消息的生产：
0---表示不进行消息接收是否成功的确认；
1---表示当Leader接收成功时确认；
-1---表示Leader和Follower都接收成功时确认；
综上所述，有几种消息生产的情况，下面分情况来分析消息丢失的场景：
（1）acks=0，不和Kafka集群进行消息接收确认，则当网络异常、缓冲区满了等情况时，消息可能丢失；
（2）acks=1、同步模式下，只有Leader确认接收成功后但挂掉了，副本没有同步，数据可能丢失；
2、消息消费
Kafka消息消费有两个consumer接口，Low-level API和High-level API（低等级消费和高等级消费）：
Low-level API：消费者自己维护offset等值，可以实现对Kafka的完全控制；
High-level API：封装了对parition和offset的管理，使用简单；
如果使用高级接口High-level API，可能存在一个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offset值后，还没来得及消费就挂掉了，那么下次再消费时之前没消费成功的消息就“诡异”的消失了；
解决办法：
- 针对消息丢失：同步模式下，确认机制设置为-1，即让消息写入Leader和Follower之后再确认消息发送成功；异步模式下，为防止缓冲区满，可以在配置文件设置不限制阻塞超时时间，当缓冲区满时让生产者一直处于阻塞状态；
- 针对消息重复：将消息的唯一标识保存到外部介质中，每次消费时判断是否处理过即可。
3.Kafka的Leader选举机制
Kafka将每个Topic进行分区Patition，以提高消息的并行处理，同时为保证高可用性，每个分区都有一定数量的副本 Replica，这样当部分服务器不可用时副本所在服务器就可以接替上来，保证系统可用性。在Leader上负责读写，Follower负责数据的同步。当一个Leader发生故障如何从Follower中选择新Leader呢？
Kafka在Zookeeper上针对每个Topic都维护了一个ISR（in-sync replica---已同步的副本）的集合，集合的增减Kafka都会更新该记录。如果某分区的Leader不可用，Kafka就从ISR集合中选择一个副本作为新的Leader。这样就可以容忍的失败数比较高，假如某Topic有N+1个副本，则可以容忍N个服务器不可用。
如果ISR中副本都不可用，有两种处理方法：
（1）等待ISR集合中副本复活后选择一个可用的副本；
（2）选择集群中其他可用副本；
Kafka的leader选举区分多种角色：
- controller的选举
- 分区leader的选举
- 消费者group组内leader选举
Leader选举过程可参考：
- kafka的leader选举过程 - 简书
- kafka的HA设计 - 简书
- http://www.jasongj.com/2015/04/24/KafkaColumn2/
4. kafka三种消费方式：
最多一次（at most once）: 消息可能丢失也可能被处理，但最多只会被处理一次。可能丢失 不会重复。
至少一次（at least once）: 消息不会丢失，但可能被处理多次。可能重复 不会丢失。
精确传递一次（exactly once）: 消息被处理且只会被处理一次。不丢失 不重复 就一次。
而kafka其实有两次消息传递，一次生产者发送消息给kafka，一次消费者去kafka消费消息。
两次传递都会影响最终结果，两次都是精确一次，最终结果才是精确一次。
两次中有一次会丢失消息，或者有一次会重复，那么最终的结果就是可能丢失或者重复的。