前言

前段时间接触到腾讯云的一个新数据库产品 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》 是对其重点部分的存储服务的。

前言

游戏业务通常有个特点是模块相关性非常高，模块之间的联动也非常密集且复杂。要保持各个相关模块的数据一致性，同时又兼顾效率和，没有一个通用的方法。通常的做法是走有损服务（也叫柔性服务）和自动修复的方式。比如支付服务一般的做法是在2PC的基础上增加redo log，对于发放和订单确认这两方，如果失败了会尝试几次补发。又或者好友系统或者公会，因为涉及多个对象的数据相互索引，一些做法是玩家在线的时候定期去检查数据是否正确，如果不正确走修复流程。

前言

之前看过 《大规模分布式存储系统：原理解析与架构实战》 ，这个系统设计还是挺有意思的，里面提及了Google的一整套系统都有论文，而且现在已经进化到下一代支持分布式跨行事务的关系型数据库系统了。所以一直很想抽时间看看Google的那套去中心化并且可以平行扩容的分布式系统和数据库的论文。之前一些计划中的我自己的项目的优化项都差不多完成了，这段时间就陆陆续续的看完了这三篇Paper，可怜我的渣渣英语，所以看得比较慢。