深入理解kafka核心设计与实践原理_读书笔记第7章深入客户端

最新推荐文章于 2024-12-19 19:15:14 发布

原创最新推荐文章于 2024-12-19 19:15:14 发布 · 315 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

收录于

kafka

本文详细探讨Kafka中的分区分配策略、消费者协调器功能，重点解析__consumer_offsets主题作用，深入分析Kafka事务与幂等性的实现机制，包括消息传输保障的三个层级：at most once、at least once及exactly once，阐述幂等性和事务如何确保消息的精确处理。

第7章深入客户端

7.1 分区分配策略

详解Kafka中所有的分区分配.

7.2 消费者协调器和组协调器

	TODO

7 .3 __consumer _offsets 剖析

	位移提交的内容最终会保存到 Kafka 的内部主题 __consumer_offsets 。

7.4 事务与幂等

7.4.1 消息传输保障

一般而言，消息中间件的消息传输保障有3个层级，分别如下：
(1) at most once ：至多一次。消息可能会丢失，但绝对不会重复传输。
(2) at least once 最少一次。消息绝不会丢失，但可能会重复传输。
(3) exactly once ：恰好一次。每条消息肯定会被传输一次且仅传输一次。
Kafka 0.11.0.0 版本开始引入了幂等和事务这两个特性，以此来实现 EOS ( exactly once
semantics ，精确一次处理语义）

7.4.2幂等

所谓的幕等，简单地说就是对接口的多次调用所产生的结果和调用一次是一致的 。
开启幕等性功能的方式很简单，只需要显式地将生产者客户端参数 enable.idempotence
设置为 true 即可（这个参数的默认值为 false ），参考如下：
```
properties.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG,true);
＃或者
properties.put("enable.dempotence",true);
```

7.4.3 事务

幂等性并不能跨多个分区运作，而事务可以弥补这个缺陷。事务可以保证对多个分区写入操作的原子性。操作的原子性是指多个操作要么全部成功，要么全部失败，不存在部分成功、失败的可能。
为了实现事务，应用程序必须提供唯 transactionalld ，这个 transactionalId 通过客户端参数 transactional.id 来显式设置，参考如下
```
properties.put(ProducerConfig.TRANSACTIONALID_CONFIG,"transaction.Id" ) ;
＃或者
properties.put("transactional.id","transactionid"); 
```
事务要求生产者开启幕等特性。需要将 enable.idempotence设置为 true
生产者的角度分析，通过事务，Kafka 可以保证跨生产者会话的消息幕等发送，以及跨生产者会话的事务恢复。
从消费者的角度分析，事务能保证的语义相对偏弱。Kafka 并不能保证己提交的事务中的所有消息都能够被消费。因为事务中的某些消息有可能被清理或者删除。