庭前云落的博客

（1）开启幂等性后，为了保证数据不会重复，那么就需要给每一个请求批次的数据增加唯一性标识，kafka 中，这个标识采用的是连续的序列号数字 sequencenum，但是不同的生产者 Producer 可能序列号是一样的，所以仅仅靠 seqnum 还无法唯一标记数据，所以还需要同时对生产者进行区分，所以 Kafka 采用申请生产者 ID （producerid）的方式对生产者进行区分。注意，这里的同样的一条数据，指的不是内容一致的数据，而是指的不断重试的数据。如果不是，那么说明数据已经乱了，发生异常。

如果 Kafka 通过主线程代码将一条数据放入到缓冲区后，需等待数据的后续发送操作的应答状态，才能发送下一条数据的场合，我们就称之为同步发送。根据前面提供的配置信息创建生产者对象，通过这个生产者对象向 Kafka 服务器节点发送数据，而具体的发送是由生产者对象创建时，内部构件的多个组件实现的，多个组件的关系类似与生产者消费者模式。（1）数据生产者（KafkaProducer）：生产者对象，用于对我们的数据进行必要的转换和处理，将处理后的数据放入到数据收集器中，类似于生产者消费者模式下的生产者。

Kafka 的topic也存在类似的问题，也就是说，如果一个topic 划分了多个分区 partition，那么这些分区怒就会均匀地分布在不同的 broker 节点上，一旦某一个 broker 节点出现了问题，那么在这个节点上的分区就会出现问题，那么 Topic 的数据就不完整了。主题创建后，需要找到一个用于存储分区数据的位置，根据上面ZooKeeper 存储的节点配置信息可以知道，当前主题的分区数量为3，副本数量为1，那么数据存储的位置就是每个分区 Leader 副本所在的 broker 节点。

ZooKeeper 中的 /controller 节点就会自动被删除，而其他那些 Slave 节点因为增加了监听器，所以当监听到 /controller 节点被删除后，就会马上向 ZooKeeper 发出创建 /controller 节点的请求，一旦创建成功，那么该Broker 就变成了新的 Controller 节点了。方案是不错，但是问题就在于选哪一个Slave节点呢？Broker启动时，会通过 ZK 客户端对象向 ZK 注册当前的 Broker 节点ID，注册后，创建的 ZK节点为临时节点。

在当前的Web软件开发中，多节点分布式的架构设计已经成为必然，那么如何保证架构中不同的节点所运行的环境，系统配置是相同的，就是一个非常重要的话题。永久节点就是无论客户端是否连接上ZooKeeper都一直存在的节点，而临时节点指的是客户端连接时创建，断开连接后删除的节点。生产者和消费者彼此之间不直接通信，而通过阻塞队列来进行通信，所以生产者生产完数据之后不用等待消费者处理，直接扔给阻塞队列，消费者不着生产者要数据，而是直接从阻塞队列里取，阻塞队列就相当于一个消息缓冲区，平衡了生产者和消费者的处理能力。