深入理解kafka核心设计与实践原理_读书笔记 第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 并不能保证己提交的事务中的所有消息都能够被消费。因为事务中的某些消息有可能被清理或者删除。