淘宝分布式数据库是如何实现高可用的
每年的双十一购物节，即是电商们和“剁手族”们的狂欢节，也是各电商和各银行背后ＩＴ人的考验时刻。每年的这个晚上，从运行中心到研发中心，大家都严阵以待，通宵值班，确保我行系统的平稳运行。在挺过凌晨零点到凌晨两点这个交易高峰时段后，大家才会轻轻地松了一口气。淘宝网在２０１４年双十一的交易总金额为５７１亿元，交易峰值达到２８５万笔／分钟，比２０１３年双十一期间７９万笔／分钟的交易峰值，系统处理能力提高了３倍以上。像淘宝网这样的交易峰值是我们传统银行系统不敢轻易想象的，他们是怎样做到这点的呢？
相对于银行交易系统的数据强一致性和数据零丢失的要求，互联网企业在传统业务范围（如门户，社交，娱乐，教育等方面），他们更强调的是系统高可用性和系统高容错能力，在业务上能够接受数据不一致，甚至接受数据部分丢失的状况。但是淘宝网做的并不是传统的互联网业务，而正是传统银行的支付结算类业务，数据不一致也是同样不能容忍的。那么在双十一购物节这一疯狂的交易压力下，他们的交易系统是如何做到数据的一致性和数据零丢失的呢？
淘宝网整个交易系统是个复杂的系统，由各种不同功能的模块组成，比如说其中有负责存储大量小文件的淘宝文件系统（ＴＦＳ），负责对高频使用的数据进行内存缓存功能的淘宝ＫＶ缓存系统（Ｔａｉｒ），对图像进行分发以降低网络流量的内容分发网络（ＣＤＮ），负责内部通讯调度的高性能服务框架（ＨＳＦ），负责存储海量数据的分布式数据库（ＯｃｅａｎＢａｓｅ），负责负载均衡的ＬＶＳ服务器，负责可靠信息传递的消息中间件系统，负责网站内容展示的网站应用框架（ＷＥＢＸ）。另外还有高性能低消耗的基于Ｘ８６架构的服务器。在这些技术中，ＯｃｅａｎＢａｓｅ分布式数据库是技术集大成者，最关键和最成功的系统之一。
二、淘宝ＯｃｅａｎＢａｓｅ分布式数据库
数据库是整个系统的根基，到底是什么样的数据库支撑了淘宝网这样的交易量和并发量，支撑起正在迅速扩大的一个全球化生态体系。
ＯｃｅａｎＢａｓｅ数据库是为了解决阿里巴巴集团旗下的淘宝网的大规模数据问题而诞生的，淘宝网的数据规模及其访问量对关系数据库提出了很大挑战：数百亿条的记录、数十ＴＢ的数据、数万ＴＰＳ、数十万ＱＰＳ，让传统的关系数据库不堪重负，单纯的硬件升级已经无法使得问题得到解决，分库分表也并不总是奏效。为此，淘宝需要研发适合互联网规模的分布式数据库，这个数据库不仅要能够解决海量数据量问题，还要能够做到可扩展、低成本、易用。为此，淘宝研发了千亿级海量数据库ＯｃｅａｎＢａｓｅ，实现了数千亿条记录、数百ＴＢ数据上的跨行跨表事务。支持跨行跨表事务的特点，应用程序将因此而简单；数据分布式存储的特点，解决了容量问题，避免了分库分表策略给业务应用带来的复杂影响，解决了系统横向性能扩容问题；系统的自动容错处理，简化了系统的管理，提高了系统的可用性。
１、ＯｃｅａｎＢａｓｅ分布式数据库的系统架构
下图是ＯｃｅａｎＢａｓｅ分布式数据库的架构图，该系统主要由客户端，根服务器，更新服务器，基线数据服务器，整合应用服务器五部分组成。
图一：整体架构图
下面对关键性的组件做个简单的介绍：
客户端：用户使用ＯｃｅａｎＢａｓｅ的方式和Ｍｙｓｑｌ数据库完全相同，支持ＪＤＢＣ、Ｃ客户端访问，等等。基于Ｍｙｓｑｌ数据库开发的应用程序、工具能够直接迁移到ＯｃｅａｎＢａｓｅ。主要的客户端类型有ＭｙＳｑｌ客户端、Ｊａｖａ客户端、Ｃ客户端。
根服务器（ＲｏｏｔＳｅｒｖｅｒ）：管理集群中的所有服务器，负责子表（ｔａｂｌｅ）数据分布以及副本管理。ＲｏｏｔＳｅｒｖｅｒ一般为一主一备，主备之间数据强同步。
更新服务器（ＵｐｄａｔｅＳｅｒｖｅｒ）：存储ＯｃｅａｎＢａｓｅ系统的增量更新数据。ＵｐｄａｔｅＳｅｒｖｅｒ一般为一主一备，主备之间可以配置不同的同步模式。部署时，ＵｐｄａｔｅＳｅｒｖｅｒ进程和ＲｏｏｔＳｅｒｖｅｒ进程往往共用物理服务器。
基线数据服务器（ＣｈｕｎｋＳｅｒｖｅｒ）：存储ＯｃｅａｎＢａｓｅ系统的基准数据。基准数据一般存储两份或者三份，可配置。
整合应用服务器（ＭｅｒｇｅＳｅｒｖｅｒ）：接收并解析用户的ＳＱＬ请求，经过词法分析、语法分析、查询优化等一系列操作后转发给相应的ＣｈｕｎｋＳｅｒｖｅｒ或者ＵｐｄａｔｅＳｅｒｖｅｒ。如果请求的数据分布在多台ＣｈｕｎｋＳｅｒｖｅｒ上，ＭｅｒｇｅＳｅｒｖｅｒ还需要对多台ＣｈｕｎｋＳｅｒｖｅｒ返回的结果进行合并。客户端和Ｍｅｒｇｅ Ｓｅｒｖｅｒ之间采用原生的Ｍｙｓｑｌ通信协议，Ｍｙｓｑｌ客户端可以直接访问ＭｅｒｇｅＳｅｒｖｅｒ。
ＯｃｅａｎＢａｓｅ支持部署多个机房，每个机房部署一个包含ＲｏｏｔＳｅｒｖｅｒ、 ＭｅｒｇｅＳｅｒｖｅｒ 、ＣｈｕｎｋＳｅｒｖｅｒ以及ＵｐｄａｔｅＳｅｒｖｅｒ的完整ＯｃｅａｎＢａｓｅ集群，每个集群由各自的ＲｏｏｔＳｅｒｖｅｒ负责数据划分、负载均衡，集群服务器管理等操作，集群之间数据同步通过主集群的主ＵｐｄａｔｅＳｅｒｖｅｒ往备集群同步增量更新操作日志实现。客户端配置了多个集群的ＲｏｏｔＳｅｒｖｅｒ地址列表，使用者可以设置每个集群的流量分配比例，客户端根据这个比例将读写操作发往不同的集群。
２、ＯｃｅａｎＢａｓｅ分布式数据库的实现了哪些关键功能
对于ＯｃｅａｎＢａｓｅ所实现的功能中，以下几点我觉得特别重要：
<!--[if !supportLists]-->l <!--[endif]-->支持强一致性和跨行跨表事务：像普通数据库（Ｏｒａｃｌｅ，ＤＢ２，ＳＱＬ ＳＥＲＶＥＲ），特别是像我们熟悉的ＡＳ／４００ ＤＢ２一样支持事务控制（Ｃｏｍｍｉｔ Ｃｏｎｔｒｏｌ），将有利于简化应用程序的处理逻辑，减少异常错误处理的开销，提高开发效率。
<!--[if !supportLists]-->l <!--[endif]-->支持海量数据：支持数千亿条记录，数百ＴＢ的数据量。在ＡＳ／４００上困扰我们的大文件问题得到解决。
<!--[if !supportLists]-->l <!--[endif]-->高性能：支持数十万ＴＰＳ、数百万ＱＰＳ的访问量。
<!--[if !supportLists]-->l <!--[endif]-->强大的容错功能：系统故障自动识别和切换，数据零丢失。系统故障自动切换，客户服务不受影响，系统可用率１００％，正式我们一直追求的目标。
<!--[if !supportLists]-->l <!--[endif]-->灵活的扩展性：具有灵活的横向扩展性能，自动负载均衡。在ＡＳ／４００上遇到的高ＣＰＵ，高Ｉ／Ｏ问题得到有效解决，简单地说，加机器就行。
<!--[if !supportLists]-->l <!--[endif]-->成本低：采用Ｘ８６硬件架构，硬件成本低廉。相对ｉ系统小型机和ｚ系统大型机，硬件成本得到控制。同时功耗低，绿色环保，降低运维成本。
<!--[if !supportLists]-->l <!--[endif]-->支持ＯＬＡＰ应用：数据实时采集和处理。
三、如何扩展数据库性能
为了提高系统性能，我们往往采取将数据分拆的方式处理，常见的处理办法有以下三种选择：
１、根据业务范围垂直拆分数据库
根据业务范围垂直拆分数据库，支持同一数据库下的跨行跨表事务。根据业务特征，比如信用卡业务、储蓄卡业务、彩票业务、黄金业务等范围，将数据集中分布到不同的数据库上，在一个数据库内实现事务控制功能，跨数据库的事务需求不与支持，需上层应用系统自行保证交易原子的完整性。但我们业务间耦合度比较高，根据业务范围拆分的能力有限，扩展性受限制。因为耦合度高，跨库事务一致性需求强烈存在，如果不支持跨库事务，则程序复杂度将大大提高，从而影响到系统的稳定性和开发的效率。
２、根据业务范围水平拆分数据库
通常的做法是根据某个业务字段，通常取用户编号，哈希后取模，根据取模的结果将数据分布到不同的数据库服务器上，客户端请求通过数据库中间层路由到不同的分区。这种方式目前也存在一定的弊端，如服务器扩展操作复杂，有些范围查询需要访问所有服务器，性能低下。
３、建立一个分布式数据系统
参考分布式表格系统的做法，例如Ｇｏｏｇｌｅ Ｂｉｇｔａｂｌｅ系统，将大表划分为几万、几十万甚至几百万个子表，子表之间按照主键有序，如果某台服务器发生故障，它上面服务的数据能够在很短的时间内自动迁移到集群中所有的其它服务器。这种方式解决了可扩展性的问题，少量突发的服务器故障或者增加服务器对使用者基本是透明的，能够轻松应对促销或者热点事件等突发流量增长。另外，由于子表是按照主键有序分布的，很好地解决了范围查询的问题。但万事有其利必有一弊，分布式表格系统虽然解决了可扩展性问题，但往往无法支持事务，例如Ｂｉｇｔａｂｌｅ只支持单行事务，针对同一个ｕｓｅｒ＿ｉｄ下的多条记录的操作都无法保证原子性。
四、如何实现跨行跨表的事务管理功能
从上述三种方法上看，数据跨机分布后，跨行跨表事务功能难以实现。当前实现跨机事务的常见办法有利用两阶段提交协议（Ｔｗｏ－ｐｈａｓｅ Ｃｏｍｍｉｔ，２ＰＣ）支持分布式事务，但这个方案在实现多台主机环境跨机事务一致性方面性能比较低。如Ｇｏｏｇｌｅ的Ｐｅｒｃｏｌａｔｏｒ系统中使用了两阶段提交协议，但Ｐｅｒｃｏｌａｔｏｒ系统中事务的平均响应时间达到２～５秒，只能应用在类似网页建库这样的场景下。其实，我们在３Ｇ系统建设中实现了双机的事务一致性方案，利用每台ＡＳ／４００主机的自身事务控制功能，通过类二阶段提交协议实现了双机事务，并成功支撑了现在的交易量。但如果要利用现在这套机制实现多机的分布式事务，复杂度将大大提交，系统稳定性和并行处理能力将受到极大的考验。
淘宝技术人员通过分析发现，虽然在线业务的数据量十分庞大，例如几十亿条、上百亿条甚至更多记录，但最近一段时间（例如一天）的修改量往往并不多，通常不超过几千万条到几亿条，因此，ＯｃｅａｎＢａｓｅ决定采用单台更新服务器来记录最近一段时间的修改增量，而以前的数据保持不变，称为基准数据。基准数据以类似分布式文件系统的方式存储于多台基准数据服务器中，每次查询都需要把基准数据和增量数据融合后返回给客户端。这样，写事务都集中在单台更新服务器上，避免了复杂的分布式事务，高效地实现了跨行跨表事务；另外，更新服务器上的修改增量能够定期分发到多台基准数据服务器中，避免成为瓶颈，实现了良好的扩展性。
因此说，ＯｃｅａｎＢａｓｅ分布式数据库是根据淘宝业务特征而研发出来的，该数据库是否能够满足更多的应用场景，这是需要结合实际情况做进一步测试验证的。
五、如何解决单点性能问题
ＯｃｅａｎＢａｓｅ架构的优势在于既支持跨行跨表事务，又支持存储服务器线性扩展。当然，这个架构也有一个明显的缺陷：更新服务器单点。这个问题限制了ＯｃｅａｎＢａｓｅ集群的整体读写性能。为了避免单台更新服务器的处理能力形成性能瓶颈，淘宝技术团队在内存、网络、磁盘等方面进行优化。
１、内存操作的优化
根据业务特征，数据库每天更新的次数相对读取次数来说，数量是有限的，同时每次更新的数据量是比较小的，因此一天的修改量大概２０ＧＢ左右，如果内存数据结构膨胀２倍，占用内存只有４０ＧＢ。而当前主流的服务器都可以配置９６ＧＢ内存，一些高档的服务器甚至可以配置１９２ＧＢ，３８４ＧＢ乃至更多内存。因此内存大小方面一般不存在问题，但考虑极端情况，如双十一促销或批量更新大量数据，更新服务器设计成支持当内存表达到一定大小时，可自动或者手工冻结并转储到ＳＳＤ中，另外支持通过定期合并或者数据分发的方式将更新服务器上的数据分散到集群中所有基准数据服务器中，这样不仅避免了更新服务单机数据容量问题，还能够使得读取操作往往只需要访问更新服务器内存中的数据，避免访问ＳＳＤ磁盘，提高了读取性能。
２、网络框架的优化
给更新服务器配置四块或更多块的千兆网卡或者万兆网卡，并根据更新服务器全内存操作、收发的网络包一般比较小的特点，对网络框架做了专门的优化，大大提高了每秒收发网络包个数，使得网络不会成为瓶颈。
３、硬盘操作的优化
将数据的写入操作分为两类，一类是数据库事务操作日志写入ＳＡＳ磁盘，另外一类是其他数据写入ＳＳＤ硬盘。更新服务器上配置了一块带有缓存模块的ＲＡＩＤ卡，操作日志只需要写入到ＲＡＩＤ卡的缓存模块即可，该ＲＡＩＤ卡再写入到ＳＡＳ磁盘上。该ＲＡＩＤ卡自带电池，在服务器断电时能够确保将缓存中的数据刷入ＳＡＳ磁盘，不会出现丢数据的情况。另外，更新服务器实现了将多个用户的操作日志组成一组，汇总提交写入，以减少磁盘Ｉ／Ｏ次数。对于其他数据，则采取批量的顺序写方式写入到ＳＳＤ硬盘中，通过ＳＳＤ硬盘高效的读取能力提高读取能力。
四、如何避免数据丢失
如上图一所示，ＵｐｄａｔｅＳｅｒｖｅｒ采取了主备高可用架构，备机可以是一台或多台。在正常情况下，系统将选择一台服务器作为主服务器，所有数据的写操作，均需在主服务器上发生。如果主服务器发生故障，系统将自动将该服务器下线，并选择一台最新的备份服务器作为主服务器继续提供服务。
ＵｐｄａｔｅＳｅｒｖｅｒ为主备高可用架构，更新操作流程如下：
１、将更新操作发送到备机；
２、将更新操作的ｒｅｄｏ日志写入主机硬盘；
３、将ｒｅｄｏ日志应用到主机的内存表格中；
４、返回客户端写入成功。
ＯｃｅａｎＢａｓｅ要求将ｒｅｄｏ日志同步到主备的情况下才能够返回客户端写入成功，即使主机出现故障，备机自动切换为主机，也能够保证新的主机拥有以前所有的更新操作，严格保证数据不丢失。另外，为了提高可用性，ＯｃｅａｎＢａｓｅ还增加了一种机制，如果主机往备机同步ｒｅｄｏ日志失败，比如备机故障或者主备之间网络故障，主机可以将备机从同步列表中剔除，本地更新成功后就返回客户端写入成功。主机将备机剔除前需要通知ＲｏｏｔＳｅｒｖｅｒ，后续如果主机故障，ＲｏｏｔＳｅｒｖｅｒ能够避免将不同步的备机切换为主机。
ＯｃｅａｎＢａｓｅ的高可用机制保证主机、备机以及主备之间网络三者之中的任何一个出现故障都不会对用户产生影响，然而，如果三者之中的两个同时出现故障，系统可用性将受到影响，但仍然保证数据不丢失。如果应用对可用性要求特别高，可以增加备机数量，从而容忍多台机器同时出现故障的情况。
ＯｃｅａｎＢａｓｅ主备同步也允许配置为异步模式，支持最终一致性。这种模式一般用来支持异地容灾。例如，用户请求通过杭州主站的机房提供服务，主站的ＵｐｄａｔｅＳｅｒｖｅｒ内部有一个同步线程不停地将用户更新操作发送到青岛机房。如果杭州机房整体出现不可恢复的故障，比如地震，还能够通过青岛机房恢复数据并继续提供服务。
总体上说，ＯｃｅａｎＢａｓｅ是融合了分布式存储系统和关系数据库这两种技术。通过分布式存储技术将基准数据分布到多台基准服务器，实现数据复制、负载均衡、服务器故障检测与自动容错等功能；更新服务器相当于一个高性能的内存数据库，底层采用关系数据库技术实现。ＯｃｅａｎＢａｓｅ相当于ＧＦＳ ＋ ＭｅｍＳＱＬ，基准服务器的实现类似ＧＦＳ，更新服务器的实现类似ＭｅｍＳＱＬ，目标是成为可扩展的、支持每秒百万级单行事务操作的分布式数据库。
上述资料是我通过相关书籍，网络文档，相关博客内容整理而成，其中难免可能会有部分描述与实际存在差异，敬请谅解。希望这篇文章，能够对那些对云计算和大数据处理抱有好奇心，对淘宝网的技术成就抱有好奇心的同事，能有所帮助。ＯｃｅａｎＢａｓｅ是淘宝经过多年实践，从经验和教训中逐步构建出来，它不一定是最好的，但肯定是最适合淘宝网的。当前我们招行把云计算，大数据处理技术作为我们的重点研究对象，了解淘宝网及其他互联网公司的技术历程，了解他们在某个技术上的考量和决策，对我们是有很大参考意义的。
https://blog.csdn.net/pengkunstone/article/details/46825829