前言

接上文 《游戏服务的分布式事务优化（一）- Write Ahead Log(WAL) 模块》

在挺久以前我写过一篇分享 《在游戏服务器中使用分布式事务》 。当时尝试在我们的游戏服务中引入TCC模型的分布式事务机制，以优化好友和公会服务的一致性流程。 最开始的实现并不通用，后来我对这个事务的实现做了进一步的优化和重构，抽离成了较为通用的模块，并对之前没全部完成的功能做了进一步完善。 此篇为重构内容的第二部分，主要聚焦于事务管理。

前言

在挺久以前我写过一篇分享 《在游戏服务器中使用分布式事务》 。当时尝试在我们的游戏服务中引入TCC模型的分布式事务机制，以优化好友和公会服务的一致性流程。 但是时间原因，但是写的第一版是深入我们当时的游戏业务的，第一版仅用在好友服上，既不通用测试也不完善。 后来逐渐把公会服务和聊天的功能也采用或部分采用这里的分布式事务的组件来实现，发现有大量的相似代码。 并且由于分布式事务的流程本身比较复杂，其他人接手的时候看起来就会比较吃力，所以我一直有计划重构这一块代码并且实现为更加通用且灵活的模块。 最近也是基本完成了这部分的工作，通用接口主要分为两部分。第一部分是 Write Ahead Log(WAL) 模块，第二部分是事务管理模块。 本此分享主要专注于第一部分 Write Ahead Log(WAL) 。

前言

前段时间接触到腾讯云的一个新数据库产品 CynosDB 是基于 Amazon Aurora 数据库的Paper实现的。我比较感兴趣就来看看它和之前看过的 Spanner 之类有什么不同，也许部分设计也能用在我们游戏业务的服务器中。它的主要的创新点在于重新设计了binlog和存储的部分，所以我也主要就看了两篇Paper： 《Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases》 是一个整体性质的介绍和概述； 《Amazon Aurora: On Avoiding Distributed Consensus for I/Os,Commits, and Membership Changes》 是对其重点部分的存储服务的。