kafka以其高性能、高吞吐、可扩展等出色能力，被广泛应用在各行各业，是事件流处理平台和消息队列中的佼佼者，但是经常可以看到有人在吐槽kafka消息丢失，但是真的是kafka的锅吗，本文我们就来认真分析一下到底哪些场景可能导致消息丢失以及使用怎么样的方案可以防止消息丢失。
答案很简单，topic多分几个分片，然后使用消费者组去消费topic即可。答案也不难，topic分片之后，生产者定制分发策略，保证同一对象的操作请求都分发到同一个分片中，这样每个消费者就都是在按照顺序消费各自分片中的数据啦~
之前，Kafka 集群单节点的时候，offsets.topic.replication.factor 参数设置的是 1 ，所以，kafka 自动创建的 __consumer_offsets topic 副本数也就是 1 ，它的默认 50 个分区就都在 broker 200 节点上。
这周我们学习下消费者，还是先从一个消费者的Hello World学起:前两步和生产者类似，配置参数然后根据参数创建实例，区别在于消费者使用的是反序列化器，以及多了一个必填参数 group.id，用于指定消费者所属的消费组。
如果对RocketMQ或者对消息中间件有所了解的话，消费端在进行消息消费时至少需要先进行队列的负载，即一个消费组内的多个消费者如何对订阅的主题中的队列进行负载均衡，当消费者新增或减少、队列增加或减少时能否自动重平衡，做到应用无感知，直接决定了程序伸缩性，其说明图如下:
用生产者客户端 API 向 Kafka 生产消息，用消费者客户端 API 从 Kafka 读取这些消息。Kafka 0.9 版本之前，除了 broker 之外， 消费者也会使用 Zookeeper 保存一些信息，比如消费者群组的信息、 主题信息、消费分区的偏移量。
在 zookeeper 服务器上，通过如下命令去获取对应分区的信息， 比如下面这个是获取 secondTopic 第 1 个分区的状态信息。 更新当前分区的 HW，这个时候 leader LEO 和 remote LEO 都是 1，所以 HW 的值也更新为 1。
