网站建设服务费的摊销期限,flash 做ppt的模板下载网站有哪些,怎么免费注册公司,做门户网站的好处丢失消息有 3 种不同的情况#xff0c;针对每一种情况有不同的解决方案。 生产者丢失消息的情况消费者丢失消息的情况Kafka 弄丢了消息 生产者丢失消息的情况 生产者(Producer) 调用send方法发送消息之后#xff0c;消息可能因为网络问题并没有发送过去。所以#xff0c;我们…丢失消息有 3 种不同的情况针对每一种情况有不同的解决方案。 生产者丢失消息的情况消费者丢失消息的情况Kafka 弄丢了消息 生产者丢失消息的情况 生产者(Producer) 调用send方法发送消息之后消息可能因为网络问题并没有发送过去。所以我们不能默认在调用 send() 方法发送消息之后消息消息发送成功了。 为了确定消息是发送成功我们要判断消息发送的结果。 但是要注意的是 Producer 使用 send() 方法发送消息实际上是异步的操作我们可以通过 get()方法获取调用结果但是这样也让它变为了同步操作示例代码如下 SendResultString, Object sendResult kafkaTemplate.send(topic, o).get();
if (sendResult.getRecordMetadata() ! null) {logger.info(生产者成功发送消息到 sendResult.getProducerRecord().topic() - sendResult.getProducerRecord().value().toString());
} 但是一般不推荐这么做可以采用为其添加回调函数的形式示例代码如下 ListenableFutureSendResultString, Object future kafkaTemplate.send(topic, o);future.addCallback(result - logger.info(生产者成功发送消息到topic:{} partition:{}的消息, result.getRecordMetadata().topic(), result.getRecordMetadata().partition()),ex - logger.error(生产者发送消失败原因{}, ex.getMessage())); 如果消息发送失败的话我们检查失败的原因之后重新发送即可 另外这里推荐为 Producer 的 retries重试次数设置一个比较合理的值一般是 3 但是为了保证消息不丢失的话一般会设置比较大一点。设置完成之后当出现网络问题之后能够自动重试消息发送避免消息丢失。另外建议还要设置重试间隔因为间隔太小的话重试的效果就不明显了网络波动一次你 3 次一下子就重试完了 消费者丢失消息的情况 我们知道消息在被追加到 Partition(分区)的时候都会分配一个特定的偏移量offset。offset 表示 Consumer 当前消费到的 Partition(分区)的所在的位置。Kafka 通过偏移量offset可以保证消息在分区内的顺序性。 当消费者拉取到了分区的某个消息之后消费者会自动提交了 offset。自动提交的话会有一个问题试想一下当消费者刚拿到这个消息准备进行真正消费的时候突然挂掉了消息实际上并没有被消费但是 offset 却被自动提交了。 这种情况的解决办法也比较粗暴我们手动关闭自动提交 offset每次在真正消费完消息之后之后再自己手动提交 offset 。但是细心的朋友一定会发现这样会带来消息被重新消费的问题。比如你刚刚消费完消息之后还没提交 offset结果自己挂掉了那么这个消息理论上就会被消费两次。 Kafka 弄丢了消息 我们知道 Kafka 为 Partition 引入了多副本Replica机制。Partition 中的多个副本之间会有一个叫做 Leader 的家伙其他副本称为 Follower。我们发送的消息会被发送到 Leader 副本然后 Follower 副本才能从 Leader 副本中拉取消息进行同步。生产者和消费者只与 Leader 副本交互。你可以理解为其他副本只是 Leader 副本的拷贝它们的存在只是为了保证消息存储的安全性。 试想一种情况假如 Leader 副本所在的 Broker 突然挂掉那么就要从 Fllower 副本重新选出一个 Leader 但是 Leader 的数据还有一些没有被 Follower 副本的同步的话就会造成消息丢失。 设置 acks all 解决办法就是我们设置 acks all。acks 是 Kafka 生产者(Producer) 很重要的一个参数。 acks 的默认值即为1代表我们的消息被leader副本接收之后就算被成功发送。当我们配置 acks all 表示只有所有 ISR 列表的副本全部收到消息时生产者才会接收到来自服务器的响应. 这种模式是最高级别的也是最安全的可以确保不止一个 Broker 接收到了消息. 该模式的延迟会很高. 设置 replication.factor 3 为了保证 Leader 副本能有 Follower 副本能同步消息我们一般会为 Topic 设置 replication.factor 3。这样就可以保证每个 Partition 至少有 3 个副本。虽然造成了数据冗余但是带来了数据的安全性。 设置 min.insync.replicas 1 一般情况下我们还需要设置 min.insync.replicas 1 这样配置代表消息至少要被写入到 2 个副本才算是被成功发送。min.insync.replicas 的默认值为 1 在实际生产中应尽量避免默认值 1。 但是为了保证整个 Kafka 服务的高可用性你需要确保 replication.factor min.insync.replicas 。为什么呢设想一下假如两者相等的话只要是有一个副本挂掉整个分区就无法正常工作了。这明显违反高可用性一般推荐设置成 replication.factor min.insync.replicas 1。 设置 unclean.leader.election.enable false Kafka 0.11.0.0 版本开始 unclean.leader.election.enable 参数的默认值由原来的 true 改为 false 我们最开始也说了我们发送的消息会被发送到 Leader 副本然后 Follower 副本才能从 Leader 副本中拉取消息进行同步。多个 Follower 副本之间的消息同步情况不一样当我们配置了 unclean.leader.election.enable false 的话当 Leader 副本发生故障时就不会从 Follower 副本中和 Leader 同步程度达不到要求的副本中选择出 Leader 这样降低了消息丢失的可能性。
