基于 MySQL 和 DynamoDB 的强一致性分布式事务实践

在单体应用向微服务架构转型的过程中，本地事务已不再满足系统一致性需求，为了解决这一问题，前人在对性能和数据一致性反复权衡的过程中总结了许多典型的协议和算法，各有优劣。本文我们将深入探讨 Freewheel 如何实现无单点故障的可扩展分布式事务实现模型。

为什么需要分布式事务？

当应用程序有严格的数据一致性要求时，ACID 事务是必须的，如果一个事务涉及的所有操作能够放在一个服务内部，且共用一个数据库，那么只用在一个方法里同一个事务下操作数据库即可。然而为了提升系统整体的可靠性，方便各个模块独立演化，系统从单体应用演进为微服务架构。随着数据体量的增长，数据源也从 MySQL 扩展到关系型数据库 Amazon Aurora 和 NoSQL 数据库(Amazon DynamoDB)，基于多样化索引和查询数据的需求，引入了搜素引擎(ApacheSolr 和 ElasticSearch ) ，多服务交互、多数据源并存产生了分布式事务。

Freewheel 分布式事务应用场景有三个：

• 多服务，同数据源: 业务单元跨越多个独立服务，服务访问同一个数据源，如 MySQL。
• 单服务，不同数据源: 业务单元涉及一个独立服务，但这个服务访问多个数据源，如 MySQL，DynamoDB。
• 多服务，不同数据源: 业务单元跨越多个独立服务，每个服务访问不同数据源，如 MySQL，DynamoDB。

综合考虑 Freewheel 的业务需求后，我们实现了多引擎数据库分布式事务。

多引擎数据库分布式事务设计

Freewheel 分布式事务方案主要设计目标如下：

数据强一致性：确保该事务范围内的所有操作都可以全部成功或者全部失败，事务具有原子性、一致性、隔离性、持久性 4 个特性。

• Atomicity（原子性）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复到事务开始前的状态，就像这个事务从来没有执行过一样。
• Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。完整性包括外键约束、应用定义等约束不会被破坏。
• Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
• Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

系统高可用：遵循“design for failure”的设计原则，硬件层面，采用服务节点多 region 多 AZ 部署和节点故障快速自恢复的策略来保证系统的高可用。软件层面，设计 failover 机制应对服务异常。

可扩展：应用 Auto Scaling 服务，它会基于设定的负载压力，自动进行扩展和缩容，来保证服务正常运行。

易用性：分布式事务应用 API：易学，易懂，易记，系统设计上无业务侵入，没有额外的编码或测试工作。

多引擎数据库分布式事务技术选型

常见分布式事务解决方案对照表:

方案	优点	缺点
XA	强一致性 无业务侵入	同步阻塞