云端消息系统如何支持事务
极客时间编辑部
讲述：丁婵大小：2.14M时长：04:41
与之前的消息服务相比，当今基于云的消息服务是否提供了不一样的事务支持？如果是这样，这意味着什么？日前，InfoQ 记者采访了分布式系统专家伍迪·达汉（Udi Dahan），了解了这个问题。
伍迪·达汉表示，关于事务，有两种解释。一种从技术方面来解释，比如 ACID，即原子性、一致性、隔离性和持久性。如果从业务方面来解释，我认为最好的解释是这样的：事务是一种可以让你的系统处于一致性状态的工具，不会让系统留有不准确的垃圾数据，这些垃圾数据会让系统变得无用和不符合监管规范。
我们需要面对的一个事实是，所有的事物都是相互关联的，用户希望连接到他们的数据，并在全球范围内与其他用户实时协作操作任意一组数据。
消息传递系统提供了长距离传递可靠消息的一些元素。试想这样的一个场景：你将钱从一个帐户转移到另一个帐户。任何银行都不可能、也不希望将记录锁定在任何其他一家银行的数据库中。
消息传递是作为一个临时位置引入的，既不在你的数据库中，也不在我的数据库中。然后我们可以把钱通过这些高度可靠的管道进行转移。转移过程的每一步都可以是一个事务，只要这些步骤中的每一个都是可靠并且具备事务性，就可以从业务角度保证整个流程是安全的。
在 Amazon SQS 和 Azure Service Bus 之前，一些开源的消息系统，比如 RabbitMQ 都不支持事务。ActiveMQ 虽然声称支持事务，但它的实现不稳定，我们不能完全相信它。同时 NoSQL 数据库的崛起是一件非常重要的事情。也催生了业界对事务的需求。
在云端，我们看到了缺乏事务支持所造成的连锁反应。现在，当我们迁移到云端时，需要适当地考虑事务问题。如果云供应商说他们不支持事务，那是因为它们无法灵活提供某种全局性的事务保证。
事实证明，有很多相对简单的模式可用于队列系统和数据库之间的事务。有两个基本的模式，分别是收件箱和发件箱模式。
要使用这两个模式，需要为消息提供一个标识符，用于惟一地标识消息，然后根据实际需要进行重试或去重。
当你的业务代码需要发出消息时，你可以将消息发送到发件箱，而不是直接与消息代理发生通信。发件箱会替你把消息发送给消息代理。现在，发件箱可以作为数据库事务的一部分。
因此，本质上，我们在消息系统中引入了半持久性级别，无论用户要求发送什么消息，都可以作为相同数据库事务的一部分。这意味着如果数据库事务因为发生故障而回滚，不仅可以回滚业务数据，而且可以回滚所有要发送出去的消息，这样就可以防止错误的业务数据脱离事务边界。
这就是发件箱模式。另一个是收件箱模式。假设你要从消息队列中读取一条消息。这个消息有唯一标识符，你的业务逻辑对业务实体进行了更新，并向发件箱发布了一个事件。现在，代码已经准备好发布消息了，但端点却在事务提交后发生了崩溃。然后会发生什么？这个时候需要用到收件箱，在进行消息重试时，收件箱会拿到消息的标识符，与发件箱中的消息进行比对，发现消息已经被处理过了，而且不会重新调用同样业务逻辑，因为实际上已经成功处理过了。
因此，收件箱模式为我们提供了一种内置的幂等性，开发人员不需要在程序中处理幂等性问题。在并发环境中，与更新相关的幂等性并不是一件容易实现的事情。
因此，这里有很多东西与消息 ID 管理、消息去重、幂等性、捕获和存储消息以及数据存储层的事务管理有关。如果单独看这些东西，它们并不难。但要以正确的方式将它们串在一起，将它们用于 RabbitMQ、Amazon SQS、Azure 服务总线和现有的数据库技术，才能获得最终的一致性。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论