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

基于 MySQL 和 DynamoDB 的强全都性分布式事务实践 为什么需要分布式事务？ 当应用程序有严格的数据全都性要求时，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：易学，易懂，易记，系统设计上无业务侵入，没有额外的编码或测试工作。 多引擎数据库分布式事务技术选型 常见分布式事务处理方案对比表: 结合 Freewheel 强全都性业务需求，多数据源分布式事务将由 XA、2PC 和 Seata 这些处理方案组合而成。 Seata 框架设计思想 基于 XA 的 Aurora 分支事务 基于 2PC 的 DynamoDB 分支事务 多数据源分布式事务处理方案 架构解析 Freewheel 分布式事务依托在 Freewheel 数据访问层两头件(DAL)上，这个两头件是由 Freewheel 平台团队自主研发的，它的目标是为上游应用供应更好的数据访问，为下游数据源供应更好的爱护。为了便利描述，下文均用 DAL 来作为 Freewheel 数据访问层两头件的简称。 ? 分布式事务由这三个组件来协商处理： Transaction Coordinator (TC)： 事务协调器，维护全局事务的运转形态，担任协调并驱动全局事务的提交或回滚。 Transaction Manager (TM)： 把握全局事务的边界，担任开启一个全局事务，并最终发起全局提交或全局回滚的决议。 Resource Manager (RM)： 把握分支事务，担任分支注册、并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。 ? 为了预防死锁，并且削减 DAL RM 和 TC 之间的 交互，降低对 TC 的依靠，同一个分布式事务操作放在同一个 DAL 节点，由此，DAL RM 可以便利的在单节点把握和协调分支事务，完成全局事务的提交和回滚。 ? 以多服务，不同数据源(Aurora 与 DynamoDB)为例，描述 Freewheel 分布式事务过程。 A Service TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局独一的 XID。 XID 在微服务调用链路的上下文中传播。 TM 向 TC 发起针对 XID 的全局提交或回滚决议。 TC 向 DAL RM 发起全局提交或回滚决议。 DAL RM 对 XI