大家好，今日小蚪来为大家解答以上的问题。kafka测试消息发送和接收，kafka发送消息失败常见原因很多人还不知道，现在让我们一起来看看吧！

kafka测试消息发送和接收 kafka发送消息失败常见原因kafka测试消息发送和接收 kafka发送消息失败常见原因


kafka测试消息发送和接收 kafka发送消息失败常见原因


kafka测试消息发送和接收 kafka发送消息失败常见原因


1、副本指定必须写作成功的小副本数量，如果不能满足这个小值，则生产者引发一个异常（NotEnoughReplicash或者NotEnoughReplicashAfterAppend）在如今的分布式环境时代，任何一款中间件产品，大多都有一套机制去保证一致性的，Kafka 作为一个商业级消息中间件，消息一致性的重要性可想而知，那 Kafka 如何保证一致性的呢？本文从高水位更新机制、副本同步机制以及 Leader Epoch 几个方面去介绍 Kafka 是如何保证一致性的。

2、要想 Kafka 保证一致性，我们必须先了解 HW（High Watermark）高水位和 LEO（Log End Offset）日志末端位移，看下面这张图你就清晰了：高水位的作用：这里我们不讨论 Kafka 事务，因为事务机制会影响消费者所能看到的消息的范围，它不只是简单依赖高水位来判断。

3、它依靠一个名为 LSO（Log St在 kafka/bin 目录中，kafka提供了一个写请求性能测试脚本 kafka-producer-perf-test.sh 。

4、able Offset）的位移值来判断事务型消费者的可见性。

5、日志末端位移的作用：高水位和 LEO 是副本对象的两个重要属性。

6、Kafka 所有副本都有对应的高水位和 LEO 值，而不仅仅是 Leader 副本。

7、只不过 Leader 副本比较特殊，Kafka 使用 Leader 副本的高水位来定义所在分区的高水位。

8、换句话说，分区的高水位就是其 Leader 副本的高水位。

9、从图中可以看出，Broker 0 上保存了某分区的 Leader 副本和所有 Follower 副本的 LEO 值，而 Broker 1 上仅仅保存了该分区的某个 Follower 副本。

10、Kafka 把 Broker 0 上保存的这些 Follower 副本又称为远程副本（Remote Replica）。

11、Kafka 副本机制在运行过程中，会更新 Broker 1 上 Follower 副本的高水位和 LEO 值，同时也会更新 Broker 0 上 Leader 副本的高水位和 LEO 以及所有远程副本的 LEO， 但它不会更新远程副本的高水位值，也就是我在图中标记为灰色的部分 。

12、这里你可能就困惑了？别着急，老周带你看下源码：在 kafka.cluster.Partition#makeLeader 中：Leader 副本所在的 Broker 上只有重置更新远程副本的 LEO，并没有远程副本的 HW。

13、这里你又可能会问了？Broker 0 上保存这些远程副本的主要作用是，帮助 Leader 副本确定其高水位，也就是分区高水位。

14、第二个问题我们直接来看下 HW 和 LEO 被更新的时机：处理生产者请求的逻辑如下：处理 Follower 副本拉取消息的逻辑如下：从 Leader 拉取消息的处理逻辑如下：搞清楚了上面 HW 和 LEO 的更新机制后，我们举一个单分区且有两个副本的主题来演示下 Kafka 副本同步的全流程。

15、当生产者发送一条消息时，Leader 和 Follower 副本对应的 HW 和 LEO 是怎么被更新的呢？首先是初始状态。

16、下面这张图中的 remote LEO 就是刚才的远程副本的 LEO 值。

17、在初始状态时，所有值都是 0。

18、此时，Leader 副本成功将消息写入了本地磁盘，故 LEO 值被更新为 1。

19、这时，Follower 副本也成功地更新 LEO 为 1。

20、此时，Leader 和 Follower 副本的 LEO 都是 1，但各自的高水位依然是 0，还没有被更新。

21、它们需要在下一轮的拉取中被更新，如下图所示：在新一轮的拉取请求中，由于位移值是 0 的消息已经拉取成功，因此 Follower 副本这次请求拉取的是位移值 =1 的消息。

22、Leader 副本接收到此请求后，更新远程副本 LEO 为 1，然后更新 Leader 高水位为 1。

23、做完这些之后，它会将当前已更新过的高水位值 1 发送给 Follower 副本。

24、Follower 副本接收到以后，也将自己的高水位值更新成 1。

25、至此，一次完整的消息同步周期就结束了。

26、事实上，Kafka 就是利用这样的机制，实现了 Leader 和 Follower 副本之间的同步。

27、上面的副本同步机制似乎很完美，我们不妨来思考下这种场景：从刚才的分析中，我们知道，Follower 副本的高水位更新需要一轮额外的拉取请求才能实现。

本文到这结束，希望上面文章对大家有所帮助。