公众号开通差不多有6个月了，在此做个小结。一共发表了23篇分布式和数据库相关技术原创，有630多位技术朋友关注，非常感谢大家的关注和支持！

我从事数据库行业已经10多年。入职阿里B2B接触ORACLE数据库性能调优，从事开发DBA帮助业务更好更快的使用数据库，三年后感觉oracle原理才入门就调到淘宝加入到去IOE的运动中。MySQL在淘宝大量替换ORACLE，公司积攒了很多大规模MySQL平台运维经验和分布式数据库架构经验，接着阿里云诞生了云数据库。于是又去支持RDS MySQL和SQLServer，经历过RDS发展最艰难的早期。多年以后又回到淘宝支持天猫业务。分布式MySQL在电商业务已经非常成熟，OceanBase也开始在金融业务逐步替换ORACLE。接触OceanBase了解其历史和原理后深受吸引，于是现在就从事对外推广OceanBase产品和解决方案。

在阿里，技术更替比较快。从ORACLE入门，到最后要去替换ORACLE，经历了数据库架构的演变，积累了一些经验，不想简单的遗忘，就开通这个公众号记录一下，希望对一些技术同行有些启发或者帮助。也希望大家继续支持我 ^_^

最早的文章《一些关系数据库的架构总结》想总结传统ORACLE/MySQL常用架构，以及新兴的常用分布式数据库架构。由于水平有限，写的比较粗糙。

传统的数据库架构偏重数据安全，有高可用，不丢数据。高可用的实现方法有多种。一是ORACLE RAC这种实现主实例集群，有负载均衡和高可用的能力；二是HACMP、VeritasHA软件实现的主实例的Active-Standby集群，有Failover能力。这两者的共同点都是依赖共享存储，HA机制大部分是有效的，有问题的时候需要依赖厂商分析解决。第三种就是主备切换这种，切换过程多是运维手动的。后来做的好的有些脚本去自动化做这个。主备切换的问题就是备库要同步完主库所有数据才能转变角色，这个时间会在分钟级别。总体上来说数据库实例不是很多的时候，两三个DBA就可以支持公司的数据库运维需求。

去ORACLE后MySQL的实例规模膨胀的很快，可用性方面也很差，几个DBA根本不能支持很多MySQL的运维。于是开始开发自动化运维产品。高可用始终是个难题。MySQL的Master-Slave同步是逻辑同步，在异常时，主备不一致的概率很高，切换失败的概率也很高，都需要DBA人肉修复。MySQL会丢数据吗，内外不同说法很多。于是我总结了两篇文章《揭开数据库RPO等于0的秘密（上）》《揭开数据库RPO等于0的秘密（下）》试图说明怎么去分析这个问题，以及分析其他数据库，尤其是开源数据库流行后，很多数据库都在说不丢数据。

就目前看来，阿里云的PolarDB实现了共享文件系统存储MySQL的数据和Redo，并在Master-Slave实例之间改为同步Redo这个做法算是彻底解决了MySQL丢数据的风险。不过PolarDB依然兼容Binlog的用法，只要有依赖这个Binlog做数据同步的，其数据的可靠性仍然不是百分百。蚂蚁的OceanBase很早就实现了三副本通过Paxos协议同步数据来实现了数据的高可用和强一致。

分布式数据库有些自己的特点，阿里和蚂蚁把分布式数据库架构发挥到极致，实现了跨城市的异地容灾和多活能力。虽然都是异地多活，实现细节还是有点区别。文章《数据库的异地多活分析和方案》总结了这个异地多活方案的原理和区别。

电商普遍是分布式MySQL架构，三个城市每个城市双机房一对MySQL主备实例(实际是Master-Master双向同步，通过tddl的主备权重控制业务单写一个实例)。城市之间的MySQL实例数据同步是靠软件DTS实现(内部叫DRC)。所以DTS最早是在内部业务里打磨过，解决数据同步的带宽问题，数据一致性校验问题、异常处理、以及最关键的并行同步时事务因果序保证等问题。由于三地的MySQL实例都是独立的可写的，业务控制流量的分发，三地数据库同时读写，这就是电商的异地多活。

蚂蚁的异地多活则不同，使用OceanBase集群横跨三地五机房，五副本的同步是内部机制，五副本默认只有一个leader副本可以读写，其他不提供服务，角色的切换也是内部机制。同时结合分库分表技术，将不同用户的数据的leader副本分散在不同的机房，也实现了异地多活的能力。

对外部客户而言，OceanBase把异地多活时的常见的数据同步和切换问题在内核里解决了，更容易用来实施异地容灾或异地多活目标。文章《如何基于OceanBase构建应用和数据库的异地多活》特别解释了原理和实施方案。

现在提分布式数据库的优势，必然是成本低，扩展性好，性能不够就加机器。但是业务真上了分布式数据库才发现并不一定如此。文章《分布式数据库的拆分设计实践》分析了这个问题。关键点在于如果要发挥分布式数据库的性能和扩展性优势，首先要了解数据的分布特点。要能将业务对数据库的需求“分而治之”，发挥多个机器节点的并行处理优势。这其中就要水平拆分的技巧，业务SQL的写法(算法)等等。其中最难理解和控制的就是SQL的写法。文章《说说分库分表的一个最佳实践》其实就是以DRDS的实践经验来总结，不同的业务SQL在数据库扩容后收获的效益是不完全一样的。

分布式数据库里还有个麻烦的事务问题。在单机数据库里，事务的使用场景也有多种，隔离级别不同时事务的特性、锁的特性都不一样。文章《说说数据库事务开发（上）》尝试总结了不同数据库不同隔离级别事务使用原理和注意事项。
分布式事务并不是新东西，传统的两阶段提交方案虽然能解决但性能不好，不满足互联网业务需求。所以诞生了很多分布式事务中间件。文章《说说数据库事务和开发（下）—— 分布式事务》就是分析分布式事务中间件的原理，解释为什么TCC是最终一致的。

总的来说，分布式事务就是一个架构在数据库上的编程框架，业务开发还是需要了解这个框架的原理才能规避问题。也正是因为有些客户研发没有搞清楚这个，将分布式数据库跟中间件结合使用时，以为就跟传统在单个实例上开发事务一样。结果性能可能不好。 后来一些分布式数据库就自己支持了分布式事务。如DRDS的柔性事务就是TCC方案。当然DRDS后来也支持强一致的XA方案(前提是MySQL 5.7以上)。当然，分布式事务中间件还是有使用场景的，如当一个业务实例跨越多个分布式数据库实例时。

OceanBase是个多租户的数据库集群。租户就是实例，实例内部的数据可能跨多个机器，会产生分布式事务，这个OceanBase租户是支持的。如果业务事务跨越了租户(实例)边界，这个就需要分布式事务中间件解决。

OceanBase是阿里巴巴和蚂蚁金服完全自主研发的通用的分布式关系型企业数据库。12年启动，13年上线第一个电商业务——淘宝收藏夹业务。至今收藏夹的数据还在OceanBase里，因为数据量非常大(上百亿)，所以OceanBase集群节点规模曾经超过100台。一个有趣的现象是购物车是分布式MySQL集群，拆分为4096个分表，这个集群的扩展已经到达瓶颈，现在只能尽可能的提升单机MySQL实例的性能(包括硬件的提升)。购物车有直接下单的功能，所以业务可靠性要求很高，但受限于数据库的性能瓶颈，用户购物车的容量不能轻易扩容。

OceanBase的安装对机器硬件要求目前偏高，但是安装过程相比ORACLE RAC集群还是容易很多，详情查看文章《OceanBase数据库实践入门——手动搭建OceanBase集群》。OceanBase集群的自运维能力很强，这个得益于它有个独特的内部总控服务，详情查看文章《OceanBase数据库实践入门——了解总控服务》。总控服务的功能很多，其中OceanBase的资源弹性伸缩和数据负载均衡就是由它完成，具体请看文章《揭秘OceanBase的弹性伸缩和负载均衡原理》。
搭建好OceanBase集群后，可以快速体验一下，常用操作参考《OceanBase数据库实践入门——常用操作SQL》。

OceanBase有3个版本。0.4-0.5是开源版本。1.0后闭源，内部到1.4.7。 此外还有2.x版本，支持对ORACLE的兼容。 要去O，阿里内部业务做了很多改造，舍弃了数据库的存储过程和复杂的表连接功能。不过外部业务能做的改造不多，所以OceanBase对ORACLE的兼容是去O的第一步。目前兼容性进展可以查看文章《OceanBase 2.1 的ORACLE兼容性能力探秘》。

关于OceanBase的使用原理我会持续的总结分享。目前总结的文章除了前面提的外，还有《OceanBase分区表有什么不同？》

阿里数据库去O运动促使了数据库架构的大转型，也促进了业务团队的转型，诞生了中间件团队。这其中有着非常多的经验，涉及到不同的领域产品等。目前我也是尝试每次从一个领域切入分享一些经验。 初期请查看《支付宝去O的关键技术之一——数据库弹性路由》。后面我还会针对数据在线迁移、分布式事务总结更多经验。

阿里数据库有很多特别的功能。尤其是AliSQL为了满足业务需求，做了很多加强。详情查看《阿里数据库性能诊断的利器——SQL执行干预》和《阿里数据库性能诊断的利器——SQL全量日志》。

关于运维平台的建设，也是我想总结的。目前初步写了一篇《自动化运维产品的命门——元数据库》。后面还会就这个方向继续总结。

在分布式数据库里，强一致性概念是被反复提起的，很容易让人混淆。我特地总结了一篇文章《分布式学习：Sequential 和 Linearizability》，试图消除概念混乱，希望也能给人启发。

由于微信文章不能修改，并且我的公众号文章没有留言评论功能，有些文章存在局部观点不对也不能有效纠正。所以我想在定期总结的时候顺便纠正前面文章里的失误和遗漏。

• 《OceanBase数据库实践入门——手动搭建OceanBase集群》。增加：内核参数配置里，建议配置参数aio-max-nr 的值不应小于1048576。当单机跑3个OBServer节点时会因为这个参数没有改而启动失败。

如果您对OceanBase有任何想了解的，欢迎公众号留言。其他的跟数据库架构、运维和性能调优有关的问题也可以留言。大家的问题就是我写作思路的源泉。

为了便于问题沉淀(其他人可以看到)，您也可以通过下面这个小程序发起提问。

更多后续分享敬请关注公众号：obpilot  。感谢大家的关注和支持！