Producer

kafka

1、Producer 写入消息的方式

• Kafka 的 Producer 采用 push 模式将消息发布到 broker，每条消息都被 append 到 Partition 中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障 Kafka 吞吐率）。

2、写入消息时的路由策略

• Producer 发送消息到 broker 时，会根据分区算法选择将其存储到哪一个 Partition。其路由机制为：

  1）指定了 Partition，则直接使用；

  2）未指定 Partition 但指定 key，通过对 key 的 value 进行 hash 选出一个 Partition；

  3）Partition 和 key 均未指定，就使用轮询选出一个 Partition。

3、写入消息的流程

1）Producer 先从 Zookeeper 的 /brokers/.../state 节点找到该 Partition 的 Leader；

2）Producer 将消息发送给该 Leader；

3）Leader 将消息写入本地 log；

4）Followers 从 Leader pull 消息，写入本地 log 后向 Leader 发送 ACK；

5）Leader 收到 ISR 中所有 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset）并向 Producer 发送 ACK。

4、Kafka 的 ACK 机制

Kafka 生产者 ProducerConfig 中的 ACK 配置一般常设置三种值：

• 1（默认）
  
  • 消息发送到 Kafka 后，经过 Leader 成功接收消息的的确认，就算是发送成功了。在这种情况下，如果当 Follower 尚未同步数据时刚好 Leader 宕机则会导致数据丢失。
• 0
  
  • 生产者将数据发送出去就不管了，不去等待任何返回。这种情况下数据传输效率最高，但是数据可靠性也是最低的。
• -1
  
  • 生产者需要等待 ISR 中的所有 Follower 都确认接收到数据后才算一次发送完成，可靠性最高。当 ISR 中所有 Replica 都向 Leader 发送 ACK 时，Leader 才 commit，这时候 Producer 才能认为一个请求中的消息都 commit 了。
  • 当然，如果 Leader 接受数据候在 Follower 尚未同步数据时宕机，那么 Producer 会感知消息未发送成功并重试。
  • ACK = -1 能否可以代表消息一定不丢失？
  • 当然不能，如果 Partition 只有一个副本，也就是只有一个 Leader，没有其他 Follower，那么即使它已经完成接受消息，但是接受消息过后宕机了，一样会导致数据丢失。

5、Delivery Guarantee（消息投递保证机制）

Kafka 消息有以下三种可能的 delivery guarantee：

• At most once：消息可能会丢，但绝不会重复传输；
• At least one：消息绝不会丢，但可能会重复传输；
• Exactly once：每条消息肯定会被传输一次且仅传输一次，很多时候这是用户所想要的。

Producer 到 Broker 的 delivery guarantee semantic 非常直接。当producer向broker发送消息时，一旦这条消息被commit，由于replication的存在，它就不会丢。但是如果producer发送数据给broker后，遇到的网络问题而造成通信中断，那producer就无法判断该条消息是否已经commit。这一点有点像向一个自动生成primary key的数据库表中插入数据。虽然Kafka无法确定网络故障期间发生了什么，但是producer可以生成一种类似于primary key的东西，发生故障时幂等性的retry多次，这样就做到了Exactly one。所以目前默认情况下一条消息从producer和broker是确保了At least once，但可通过设置producer异步发送实现At most once。