7.1 分区分配策略
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 并不能保证己提交的事务中的所有消息都能够被消费。因为事务中的某些消息有可能被清理或者删除。