漫游Kafka设计篇之消息传输的事务定义
2023-11-22 08:29:24
之前讨论了consumer和producer是怎么工作的，现在来讨论一下数据传输方面。数据传输的事务定义通常有以下三种级别：
- 最多一次: 消息不会被重复发送，最多被传输一次，但也有可能一次不传输。
- 最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输.
- 精确的一次（Exactly once）: 不会漏传输也不会重复传输,每个消息都传输被一次而且仅仅被传输一次，这是大家所期望的。
大多数消息系统声称可以做到“精确的一次”，但是仔细阅读它们的的文档可以看到里面存在误导，比如没有说明当consumer或producer失败时怎么样，或者当有多个consumer并行时怎么样，或写入硬盘的数据丢失时又会怎么样。kafka的做法要更先进一些。当发布消息时，Kafka有一个“committed”的概念，一旦消息被提交了，只要消息被写入的分区的所在的副本broker是活动的，数据就不会丢失。关于副本的活动的概念，下节文档会讨论。现在假设broker是不会down的。
如果producer发布消息时发生了网络错误，但又不确定实在提交之前发生的还是提交之后发生的，这种情况虽然不常见，但是必须考虑进去，现在Kafka版本还没有解决这个问题，将来的版本正在努力尝试解决。
并不是所有的情况都需要“精确的一次”这样高的级别，Kafka允许producer灵活的指定级别。比如producer可以指定必须等待消息被提交的通知，或者完全的异步发送消息而不等待任何通知，或者仅仅等待leader声明它拿到了消息（followers没有必要）。
现在从consumer的方面考虑这个问题，所有的副本都有相同的日志文件和相同的offset，consumer维护自己消费的消息的offset，如果consumer不会崩溃当然可以在内存中保存这个值，当然谁也不能保证这点。如果consumer崩溃了，会有另外一个consumer接着消费消息，它需要从一个合适的offset继续处理。这种情况下可以有以下选择：
- consumer可以先读取消息，然后将offset写入日志文件中，然后再处理消息。这存在一种可能就是在存储offset后还没处理消息就crash了，新的consumer继续从这个offset处理，那么就会有些消息永远不会被处理，这就是上面说的“最多一次”。
- consumer可以先读取消息，处理消息，最后记录offset，当然如果在记录offset之前就crash了，新的consumer会重复的消费一些消息，这就是上面说的“最少一次”。
- “精确一次”可以通过将提交分为两个阶段来解决：保存了offset后提交一次，消息处理成功之后再提交一次。但是还有个更简单的做法：将消息的offset和消息被处理后的结果保存在一起。比如用Hadoop ETL处理消息时，将处理后的结果和offset同时保存在HDFS中，这样就能保证消息和offser同时被处理了。
最新文章
- WCF : 如何将NetTcpBinding寄宿在IIS7上
- js简单 图片版时钟，带翻转效果
- Windows下安装Maven
- 实际例子描述和分析“猎豹抢票跨站推荐功能有票刷不到”的疑似bug
- 统计学习方法笔记--EM算法--三硬币例子补充
- jquery 银行卡号验证
- Effective Java 学习笔记之第七条——避免使用终结(finalizer)方法
- 浅谈C++中的那些内存泄露
- IPTABLES封闭和开放端口
- [SQL基础教程] 1-5 表的删除和更新
- 【Android】TextView跑马灯效果
- linux下查看jdk路径
- Navicat连接阿里云Mysql遇到的的坑
- FORTH基本堆栈操作
- Servlet程序
- 简单的实现HTTP密码验证登陆
- QML-关于Qt.rgba()颜色无法正常显示问题
- redis:消息发布与订阅频道
- 三款免费实用的文件夹同步/备份软件推荐 (SyncToy/FreeFileSync/Compare Advance)
- Spring 系列教程之默认标签的解析