OpenStack、Docker、K8S的演进史

此模式使用数据库表作为临时消息队列。如上图所示，发送消息的服务有个OUTBOX数据表，在进行INSERT、UPDATE、DELETE 业务操作时也会给OUTBOX数据表INSERT一条消息记录，这样可以保证原子性，因为这是基于本地的ACID事务。

OUTBOX表充当临时消息队列，然后我们在引入一个消息中继(MessageRelay)的服务，由他从OUTBOX表中读取数据并发布消息到消息组件。

消息中继的实现可以很简单，只需要通过定时任务定期从OUTBOX表中拉取最新未发布的数据，获取到数据后将数据发送给消息组件，最后将完成发送的消息从OUTBOX表中删除即可。

使用事务日志发布事件

另外一种保证事务性消息的方式是基于数据库的事务日志，也就是所谓的数据变更捕获，Change Data Capture，简称CDC。

一般数据库在数据发生变更的时候都会记录事务日志(Transaction Log)，比如MySQL的binlog。事务日志可以简单的理解成数据库本地的一个文件队列，它主要记录按时间顺序发生的数据库表变更记录。

这里我们利用alibaba开源的组件canal结合MySQL来说明下这种模式的工作原理。

更多操作说明可以参考官方文档：

canal工作原理

• canal 模拟 MySQL slave 的交互协议，把自己伪装成一个MySQL的 slave节点 ，向 MySQL master 发送dump 协议;
• MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal );
• canal 解析 binary log 对象(原始为 byte 流)，然后可以将解析后的数据直接发送给消息组件。

RocketMQ事务消息解决方案

Apache RocketMQ在4.3.0版中已经支持分布式事务消息，RocketMQ采用了2PC的思想来实现了提交事务消息，同时增加一个补偿逻辑来处理二阶段超时或者失败的消息，如下图所示。

 

当接收方处理消息时，它将消息的 message id 作为创建和变更业务实体的事务的一部分记录在数据表里。如上图所示，接收方将包含message id 的行插入 PROCESSED_MESSAGE表。如果消息是重复的，则INSERT将失败，接收方可以选择丢弃该消息。

另一个解决方案是消息处理程序在应用程序表，而不是专门表中记录 message id。当时用具有受限事务模型的NoSQL数据库时，此方法特别有用，因为 NoSQL数据库通常不支持将针对两个表的更新作为数据库事务。

处理事务性消息

服务通常需要在更新数据库的事务中发布消息，数据库更新和消息发送都必须在事务中进行，否则服务可能会更新数据库然后在发送消息之前崩溃。

如果服务不以原子方式执行者两个操作，则类似的故障可能使系统处于不一致状态。

接下来我们看一下常用的保证事务消息的两种解决方案，最后再看看现代消息组件RocketMQ的事务性消息解决方案。

使用数据库表作为消息队列

如果你的应用程序正在使用关系型数据库，要保证数据的更新和消息发送之间的事务可以直接使用 事务性发件箱模式，Transactional Outbox 。

（编辑：淮安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!