网站建设的公司这个,企业网站的建立意义,做网站需要什么文件,网站建设方案申请目录
前言#xff1a;
幂等
事务
总结#xff1a;
参考资料 前言#xff1a;
Kafka 消息交付可靠性保障以及精确处理一次语义的实现。
所谓的消息交付可靠性保障#xff0c;是指 Kafka 对 Producer 和 Consumer 要处理的消息提供什么样的承诺。常见的承诺有以下三…目录
前言
幂等
事务
总结
参考资料 前言
Kafka 消息交付可靠性保障以及精确处理一次语义的实现。
所谓的消息交付可靠性保障是指 Kafka 对 Producer 和 Consumer 要处理的消息提供什么样的承诺。常见的承诺有以下三种
最多一次at most once消息可能会丢失但绝不会被重复发送。至少一次at least once消息不会丢失但有可能被重复发送。精确一次exactly once消息不会丢失也不会被重复发送。
目前Kafka 默认提供的交付可靠性保障是第二种即至少一次。 即只有 Broker 成功“提交”消息且 Producer 接到 Broker 的应答才会认为该消息成功发送。不过倘若消息成功“提交”但 Broker 的应答没有成功发送回 Producer 端比如网络出现瞬时抖动那么 Producer 就无法确定消息是否真的提交成功了。因此它只能选择重试也就是再次发送相同的消息。这就是 Kafka 默认提供至少一次可靠性保障的原因不过这会导致消息重复发送。
大部分用户还是希望消息只会被交付一次这样的话消息既不会丢失也不会被重复处理。或者说即使 Producer 端重复发送了相同的消息Broker 端也能做到自动去重。在下游 Consumer 看来消息依然只有一条。 Kafka 是怎么做到精确一次的呢简单来说这是通过两种机制幂等性Idempotence和事务Transaction。
幂等 “幂等”这个词原是数学领域中的概念指的是某些操作或函数能够被执行多次但每次得到的结果都是不变的。 幂等性有很多好处其最大的优势在于我们可以安全地重试任何幂等性操作反正它们也不会破坏我们的系统状态。如果是非幂等性操作我们还需要担心某些操作执行多次对状态的影响但对于幂等性操作而言我们根本无需担心此事。 在 Kafka 中Producer 默认不是幂等性的但我们可以创建幂等性 Producer。它其实是 0.11.0.0 版本引入的新功能。在此之前Kafka 向分区发送数据时可能会出现同一条消息被发送了多次导致消息重复的情况。在 0.11 之后指定 Producer 幂等性的方法很简单仅需要设置一个参数即可即 props.put(“enable.idempotence”, ture)或 props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG true)。 enable.idempotence 被设置成 true 后Producer 自动升级成幂等性 Producer其他所有的代码逻辑都不需要改变。Kafka 自动帮你做消息的重复去重。底层具体的原理很简单就是经典的用空间去换时间的优化思路即在 Broker 端多保存一些字段。当 Producer 发送了具有相同字段值的消息后Broker 能够自动知晓这些消息已经重复了于是可以在后台默默地把它们“丢弃”掉。当然实际的实现原理并没有这么简单但你大致可以这么理解。 看上去幂等性 Producer 的功能很酷使用起来也很简单仅仅设置一个参数就能保证消息不重复了但实际上我们必须要了解幂等性 Producer 的作用范围。 首先它只能保证单分区上的幂等性即一个幂等性 Producer 能够保证某个主题的一个分区上不出现重复消息它无法实现多个分区的幂等性。其次它只能实现单会话上的幂等性不能实现跨会话的幂等性。这里的会话你可以理解为 Producer 进程的一次运行。当你重启了 Producer 进程之后这种幂等性保证就丧失了。 那么你可能会问如果我想实现多分区以及多会话上的消息无重复应该怎么做呢答案就是事务transaction或者依赖事务型 Producer。这也是幂等性 Producer 和事务型 Producer 的最大区别
事务 Kafka 的事务概念类似于我们熟知的数据库提供的事务。在数据库领域事务提供的安全性保障是经典的 ACID即原子性Atomicity、一致性 (Consistency)、隔离性 (Isolation) 和持久性 (Durability)。
各大主流数据库厂商都比较统一。所谓的 read committed指的是当读取数据库时你只能看到已提交的数据即无脏读。同时当写入数据库时你也只能覆盖掉已提交的数据即无脏写。
Kafka 自 0.11 版本开始也提供了对事务的支持目前主要是在 read committed 隔离级别上做事情。它能保证多条消息原子性地写入到目标分区同时也能保证 Consumer 只能看到事务成功提交的消息。下面我们就来看看 Kafka 中的事务型 Producer。
事务型 Producer 能够保证将消息原子性地写入到多个分区中。这批消息要么全部写入成功要么全部失败。另外事务型 Producer 也不惧进程的重启。Producer 重启回来后Kafka 依然保证它们发送消息的精确一次处理。
设置事务型 Producer 的方法也很简单满足两个要求即可
和幂等性 Producer 一样开启 enable.idempotence true。设置 Producer 端参数 transactional. id。最好为其设置一个有意义的名字
此外你还需要在 Producer 代码中做一些调整如这段代码所示
producer.initTransactions();
try {producer.beginTransaction();producer.send(record1);producer.send(record2);producer.commitTransaction();
} catch (KafkaException e) {producer.abortTransaction();
}
nitTransaction、beginTransaction、commitTransaction 和 abortTransaction它们分别对应事务的初始化、事务开始、事务提交以及事务终止。
这段代码能够保证 Record1 和 Record2 被当作一个事务统一提交到 Kafka要么它们全部提交成功要么全部写入失败。实际上即使写入失败Kafka 也会把它们写入到底层的日志中也就是说 Consumer 还是会看到这些消息。因此在 Consumer 端读取事务型 Producer 发送的消息也是需要一些变更的。修改起来也很简单设置 isolation.level 参数的值即可。当前这个参数有两个取值
read_uncommitted这是默认值表明 Consumer 能够读取到 Kafka 写入的任何消息不论事务型 Producer 提交事务还是终止事务其写入的消息都可以读取。很显然如果你用了事务型 Producer那么对应的 Consumer 就不要使用这个值。read_committed表明 Consumer 只会读取事务型 Producer 成功提交事务写入的消息。当然了它也能看到非事务型 Producer 写入的所有消息。
总结
幂等性 Producer 和事务型 Producer 都是 Kafka 社区力图为 Kafka 实现精确一次处理语义所提供的工具只是它们的作用范围是不同的。幂等性 Producer 只能保证单分区、单会话上的消息幂等性而事务能够保证跨分区、跨会话间的幂等性。从交付语义上来看自然是事务型 Producer 能做的更多。
不过切记天下没有免费的午餐。比起幂等性 Producer事务型 Producer 的性能要更差在实际使用过程中我们需要仔细评估引入事务的开销切不可无脑地启用事务。
参考资料
14 | 幂等生产者和事务生产者是一回事吗-极客时间
