阿里双十一数据库技术

从2012年开始，工作重心转移到了淘宝和天猫，我的技术方向也发生了改变，2012年和2013年，经历了两次双十一，在这个过程中学到了很多东西。尤其是2013年的双十一，系统准备的非常充分，技术上有很多创新，团队也得到了成长。

这篇文章是我为《程序员》杂志双十一特刊写的一篇文章，介绍了阿里数据库的核心技术

前言

大家都知道，双十一的零点高峰给系统带来的压力，尤其是数据库，作为整个交易系统最核心的组成部分，数据库的性能直接决定了整个系统的稳定性。

阿里巴巴（淘宝和天猫）的核心系统全部运行在PC服务器和MySQL数据库上，通过数据水平拆分实现了非常高的扩展性和可用性， 数据库的容量已经不再是系统瓶颈。双十一最重要的工作就是根据业务的压力，准确评估出系统的容量。因为阿里数据库的规模非常大，数据库扩容也是一项艰巨的工作，必须有自动化工具才能完成。我们还准备了很多应急预案，来应对一些突发的情况，并且通过不断的演练，保证了出现问题时可以快速解决。AliMySQL是阿里内部的MySQL分支，我们根据业务场景，对MySQL做了多项改进。同时，阿里巴巴自主研发的OceanBase数据库，已经在多个核心应用上使用，在双十一中承担了非常重要的作用。

数据库容量

数据库的容量评估分为两个部分：评估业务对数据库产生的压力，数据库单机所能承载的容量，根据这两个值就可以计算出数据库集群的规模和水位。将业务指标换算成数据库的指标QPS（Query Per Second，本文中的QPS不仅包括查询，还包括插入，修改和删除等数据库操作）是一个非常复杂的过程，大致的思路是：首先按照业务指标评估每个应用接口的调用量，然后再根据不同的接口调用量计算出成数据库的指标QPS。

看似简单，实际情况要复杂得多。淘宝的系统非常庞大，系统间的调用关系非常复杂，要分析出每个应用接口调用数据库的QPS绝非易事。为了解决这个问题，在阿里内部有一套鹰眼（eagleeye）系统，可以监控应用接口的调用量，调用关系，以及每个接口访问数据库的QPS等。借助这套系统，我们就可以比较准确的估算出数据库的容量。大家可以看出，评估数据库的容量是自上而下进行的，所以，梳理应用的调用关系是非常重要的。

一般情况下，在应用层和数据库之间，还有一层Cache，所以在评估数据库的容量时，我们还要考虑Cache的命中率，以及Cache服务器宕机的情况。在双十一大促时，Cache承担了非常大的访问压力，一旦命中率下降或者宕机，将会给数据库带来巨大的压力。我们必须要考虑这种情况，但是过度考虑会浪费大量的机器资源。所以，从平衡的角度出发，我们会为数据库预留1-2台Cache服务器宕机的容量，最高不超过Cache集群的10%。

评估出业务指标对数据库的容量需求，我们还需要知道数据库单机所能承载的压力。我们采用的方法不是通过系统Load，CPU或IO利用率来评估的，而是直接模拟真实业务来进行压测，这样做的好处是更真实。因为不同的应用的模型是不同的，比如查询型、插入型、混合型、内存型、IO型等。还有很多因素会影响数据库的性能，比如：数据量大小，查询复杂度，是否有热点等。同时，机器的硬件配置也是不同的，CPU型号，内存大小，SSD还是磁盘都会显著影响数据库的水位。不同应用反映在系统上的瓶颈也不同，可能是CPU，也可能是IO，也可能是网卡。我们之前就曾经碰到某个数据库集群，CPU还很空闲，但是千兆网卡被打满的情况。所以根据真实的业务进行压测，可以最真实的反映出系统的瓶颈，系统的最短板决定了数据库的容量。

根据压测的数据，我们就可以计算出整个集群的总容量。举一个例子：某数据库集群共16台主机，单机的容量是4万QPS，那么整个集群的容量就是64万QPS。假设根据业务的指标，我们估算出双十一数据库的压力为48万QPS，那么该数据库集群的水位就是75%。根据这个思路我们开发了数据库容量平台（Database Capacity Platform），可以非常直观的了解数据库的水位信息，水位非常直观的反映出数据库是否超出了容量。一般我们认为75%是安全水位，水位超过75%则需要进行扩容。

数据库扩容

因为双十一和平时的压力存在非常大的差距，所以我们需要在双11前对数据库集群进行扩容，必须在一个月的时间内完成，这个工作量是非常巨大的。数据库按照业务分为很多个集群，每个集群内由很多台MySQL数据库组成，数据一般按照用户ID或商品ID水平拆分。数据库集群扩容的类型有两种：一种是读写分离，通过增加备库提供读服务来提升集群的能力；另一种是水平扩容，将数据重新分布，拆分到更多台服务器上，达到扩容数据库集群的目的。

第一种方式比较简单，但是因为数据库主备存在延时，只适用于对读一致性要求不高的场景。第二种方式需要重新分布数据，虽然比较复杂，但是理论上没有容量的限制，我们大部分的扩容都采用这种方式。

不仅要考虑扩容，还要考虑缩减。在双十一之后，为了保证不浪费机器资源，我们还要对集群进行缩减。如果是读写分离则比较简单，直接将备库下线即可，但是水平扩容的方式，集群缩减的成本非常高。而且，最困难的地方在于扩容和缩减不能影响业务，必须在线进行，同时要尽量自动化，解放DBA的生产力。

集群的扩容和缩减，我们依靠一套自动化系统（DBFree）来完成，DBFree是阿里内部为MySQL量身打造的自动化运维系统，能够快速资源快速分配、拆库拆表拆实例、扩容和缩减。

如果没有这套系统，要在这么短的时间内完成大量数据库的扩容几乎是不可能完成的任务。

数据库预案

应急预案就是为了保护应用或数据库制定的措施，预案分为降级和限流两种：降级是关闭某些不重要的功能，限流是控制进入系统的流量。对于不同的数据库，我们都有对应的应急预案，当发生压力超出数据库所能提供的容量时，我们可以通过预案来保护数据库，不至于发生雪崩（数据库超出容量，响应时间变慢，导致前端应用出现问题的连锁反应）的情况。

因为数据库是整个系统的最底层，数据库要依赖于上层的应用来保护，以前数据库本身是没有自我保护能力的。今年双十一，我们创新的提出了数据库的自我保护和限流功能，作为数据库的应急预案，极大提升了数据库的稳定性。同时，应用也可以感知到这个错误，并作相应的处理。

数据库新技术

AliMySQL是阿里内部的MySQL分支，不仅修复了很多bug，还根据业务场景，开发了很多新的特性，比如：并行复制，并发控制，自我保护等等。

并行复制：MySQL主备复制是单线程的，如果主库写入量比较大，备库就会产生延迟。如果备库需要提供读服务，延迟是不能接受的。并行复制就是为了解决这个问题而提出来的，并行复制将原来的单线程复制变为多线程复制，有效解决了主备延迟的问题。双十一，很多数据库的备库都提供了读服务，在主库写入压力很大的情况下，主备延迟非常低，并行复制功不可没。

并发控制：这个补丁主要是解决热点更新的问题，比如热点商品更新库存，秒杀，红包等场景。当同时大量更新数据库中的同一行时，就会产生大量的锁等待，数据库的性能就会急剧下降。比如：在极端情况下，并发更新同一行，MySQL的TPS会降低到1000以下。并发控制补丁的作用通过控制并发更新的数量，缓解了热点更新的锁争用问题。经过测试，使用并发控制补丁，并发更新同一行，MySQL的TPS可以稳定在5000左右。今年双十一，没有发生商品超卖的情况，并发控制补丁是幕后英雄。

自我保护：当数据库发现性能很差的SQL或者超出系统的容量时，数据库会进行自我保护，保证数据库的性能和响应时间，不至于持续恶化。数据库的自我保护是阿里巴巴数据库团队率先提出并应用到生产环境的，经历了双十一的检验，极大的提升了数据库的性能和稳定性。

OceanBase

OceanBase是阿里巴巴自主研发的可扩展的关系型数据库，实现了跨行跨表的事务，支持数千亿条记录、数百TB数据上的SQL操作。在阿里巴巴集团下，OceanBase数据库支持了多个重要业务的数据存储，包括收藏夹、直通车报表、天猫评价等。截止到2013年4月份，OceanBase线上业务的数据量已经超过一千亿条，机器总数超过了1000台，经历了多次双十一的考验。

OceanBase的特性包括：分布式，可动态扩展，支持事务，支持SQL，高可用等。它结合了数据库和NoSQL的优点，像NoSQL产品一样，用户不再需要关心数据如何拆分，分布式架构，可以动态扩展。同时，又像传统数据库一样，支持SQL，事务，可以保证强一致性。并且任何单点故障都不会影响可用性。它主要包括以下组件：UpdateServer，RootServer，ChunkServer，MergeServer:

相比较各种NoSQL产品，OceanBase更倾向于传统数据库，因为我们大部分的应用都需要强一致性，支持事务，SQL等特性，NoSQL产品无法满足需要。而OceanBase又提供了比传统数据库更强的扩展能力，用户不再需要关心数据的拆分规则，ChunkServer可以动态扩展。所以，OB是一个分布式的关系型数据库，而不是又一个NoSQL的产品。

OceanBase是阿里集团最重要的自主研发项目之一，我们还在不断加大投入，相信未来它会在阿里集团甚至外部发挥越来越重要的作用。

压测与演练

双十一系统的稳定性与充分的准备工作密不可分，准备环节中最重要的两个部分就是性能压测与预案演练。

双十一前，我们对每个数据库都进行了性能压测，我们自己开发了一个压测工具（ MyTest）来模拟业务真实的压力，可以非常方便的对数据库进行压测。同时，我们还做了一项非常特殊也是风险很大的压测，我们会人为关闭系统中的Cache，这时业务的压力就会全部压在数据库上，这样做可以模拟缓存失效的场景，最真实地模拟出业务对数据库的压力。

另一项工作是预案演练，因为整个系统的应急预案非常多，今年双十一光数据库的预案就有两百多个。我们内部有一套系统对预案进行管理，并且在双十一前进行了多次预案演练，保证预案在紧急情况下是有效的，并且可以快速执行。比如应用降级，限流，数据库宕机，流量切换等预案，在双十一前都被多次演练过。“平时多流汗，战时少流血”，这个道理相信每个人都懂。

总结

双十一是一个庞大的系统化的工程，通过双十一，可以检验我们系统的稳定性，发现系统中的薄弱环节，并加以改进。

双十一就像是一次年终大考，对于数据库技术的发展和自动化运维工具都有巨大的推动作用，也是对团队组织和能力的一种考验。

只有经常打仗的队伍才有战斗力！