[来自IT] 导语：本文根据朱曜鑫老师在年5月10日现场演讲内容整理而成。
朱曜鑫阿里巴巴资深数据库工程师 8年阿里数据库团队工作经历，践行阿里巴巴两次数据库体系升级;阿里巴巴年度数据库技术总负责人，成功组织实施了17年大促支持工作，落地阿里数据库团队新一代技术体系思考。 摘要：阿里数据库架构体系的演进路线和思考过程;我们为什么选择X-DB，新体系结构在实践中如何为业务赋能;X-DB的技术优势和典型业务场景介绍;新技术体系演进过程中的经验介绍。 分享大纲： 双十一业务场景 阿里第四代数据库概述 X-DB生态的组成 X-DB高可用的核心：XPAXOS X-DB高性能的保证：XEngine 用户态文件系统 未来已来 正文 双十一业务场景
双十一是一场人为创造的技术热点，对于阿里来说意义至关重大。无论是一年的销售额还是交易创建高峰都是以指数级别的趋势在增长，这对于阿里的技术来说是一个很大的压力，当然也是因为这样的压力，不断的推动阿里技术体系创新发展。 在双十一接近零点的时候，消费者最关心的是自己的购物车，等待时机进行购买。对于阿里来说，最关心的是这一条交易创建曲线，因为对于技术人员来说，它的走势就决定了双十一的成败。 那么什么才是一次完美的双十一呢?年的双十一就是一次完美双十一。年双十一的交易创建曲线，从零点那一刻开始几乎直线上升到32.5万每秒，并且在这个区间上平稳运行，当购物结束时便开始缓慢下降。如果双十一时刻曲线并没有直线上升，或者中途突然下降，那么就证明我们的交易系统出现问题。 年的双十一又将创建一个什么样的高峰?我们怎样保证跟去年一样完美?对于阿里来说，又将是一场新的挑战。 阿里数据库体系的演进
经过九年双十一的磨练，阿里数据库体系不断演练。年—年，是阿里集中式Qracle时代，但是经过发展，该系统逐渐不能满足业务需求。所以阿里进入到第二个时代——分布式存储，我们转向了开源技术，使用MySQL，并且通过分库分表的方式让数据库可以做到水平扩展。但是后来发现这也不是一个一劳永逸的方式，我们的业务在持续增长，机器数量不断增多。比如，突然间宣布杭州电力供应不上，在用电高峰期，为了保证居民用电，必须限制阿里机房用电，这便遇到了城市资源限制问题。因此我们不得不进入第三个时代——异地多活。我们在全国多个城市创建交易单元，每个交易单元都可以独立对外提供服务，而且为了做到容灾，单元之间进行数据同步。通过这样的方式，一个城市的资源不在成为限制业务发展的瓶颈，同时我们也拥有了MySQL分支——AliSQL。在此基础上我们做了很多改进，性能得到很大提升。另外，我们还可以针对特定的业务场景进行快速开发。 第三代数据库架构支撑了阿里好几年的双十一。今天，业务给我们重新提出了要求，业内的一些技术发展方向也给我们带来了很多思想上的碰撞，我们开始思考这样几个问题：首先，阿里的国际化业务最近都在高速增长，我们需要在全球各个地方进行部署，但是面对全球复杂的网络环境，我们怎样能保证数据传输的性能以及数据的一致性?其次，经过这些年阿里在开源技术上的积累，我们对数据库底层的把控能力也逐步增强，我们是否可以通过自研的方式把最新的软硬件技术进行结合，实现数据库资源利用率最大化?最后，我们如何实现更精确的成本控制，通过采购少量机器，扛过双十一零点的压力高峰? 为了解决这些问题我们进入了第四个时代——X-DB生态，并且X-DB在年的双十一当中通过了考验。 回顾整个历程，其实就是阿里的数据库体系从闭源走向开源再走向自研的过程。那我们第四代的数据库到底是一个什么样的数据库呢? 阿里第四代数据库(X-DB)概述
X-DB名字由来：X代表数学领域的未知，象征潜力无限一切皆有可能! 我们认为数据库从一代进入到下一代必须有一个数量级的提升，所以我们给X-DB定了两大目标：写入性能提升一个数量级达到百万TPS;成本下降一个数量级做到原来的十分之一。 第一，X-DB要全面兼容MYSQL，以便让更多的业务和应用接受X-DB。第二，实现高可用，X-DB要有内部机制可以实现数据库异常宕机后的快速切换，而不需要依赖第三方的HA软件。同时它要克服复杂的网络环境做到全球化部署，并且保证数据一致性。第三，实现高性能，即性能提升一个数量级。第四，实现高扩展，包括容量上的扩展和性能上的扩展。X-DB可以从单机部署扩展到集群部署，通过这种灵活的伸缩性可以快速的调整数据库架构，从而做到对成本的精确控制。 X-DB生态的组成 X-DB高可用的核心——X-PAXOS
X-PAXOS从名字可以看出，它使用了PAXOS协议。PAXOS协议可以说是目前所有分布式一致性协议的终结者，从它问世以来，业内一直都在对它进行研究，也产生了大量的文章和项目，但是真正能做到工业级别，而且是独立PAXOS基础的却非常少。在这样的背景下我们重新打造了一个工业级别的高吞吐的PAXOS基础库。作为一个基础库，X-PAXOS除了服务于X-DB以外，还可以赋能给所有的分布式系统。 X-PAXOS架构
为了实现一个单实例多线程的PAXOS，我们在服务层上加了通用的Worker。通过这些Worker，除了必要的协议串行点以外，绝大部分任务都可以并发执行。同时，对于部分协议串行我们采取了无锁设计，尽可能的提高整个PAXOS的吞吐能力。 另外，日志是保证PAXOS协议做到一致性的工程实现，日志的写入性能很大程度会影响到整个协议的写入性能，所以我们重新开发了一个独立的可插拔的日志模块，它可以通过接口把自身的日志跟PAXOS的日志进行结合。 X-PAXOS部署形态
X-PAXOS在Multi-PAXOS基础上做了大量的改进，上图是一个Multi-Region部署架构。 我们可以这样去理解，region是城市，AZ是机房，这就成为了一个3D部署架构。首先，在满足PAXOS协议的情况下，我们可以对这些副本数进行动态调节。其次，我们可以针对不同的业务需求动态的调整我们的同步策略。 另外，我们重新定义了角色，Loger就是我们对其中的一个状态机进行了裁剪，它只接收日志不保存数据，但是它参与多数态时没有被选举权，这样做的好处是什么呢?在同城商副本部署的情况下，这样的结构可以满足PAXOS协议。同时因为Loger节点不保存数据，所以我们可以节省成本。而且这个Loger节点还可以用于日志流的备份，和日志消息的推送。 还有一个改动点是Learner，跟标准的Learner不一样，这里的Learner只负责日志的接收、消费，并不参与选举和投票。 最后我们实现了灵活的切换策略。当Leader不可用的时候，我可以优先切换到同城的Follower。如果整个城市都不可用，我们可以提前定义切换到哪个城市。 X-PAXOS性能优化
Batching是把多个消息合并成一个消息进行发送，减少中间重复的消耗。Pipelining是不等待上一个消息的反馈结果，直接发送下一个消息，来提高并发度。 一般情况下，远距离传输数据，会因为网络带宽延时浪费时间，所以适合小Batching、大Pipelining。当近距离传输时，网络问题限制比较小，但封包解包可能会消耗系统资源，这时候便适合使用大Batching、小Pipelining。 因此，X-PAXOS做到了自适应的Batching和Pipelining，它会探测整个集群不同节点的网络拓扑，根据它们的网络带宽和延时结合我们自推导的最优解算法，为每个节点定制不一样的Batching和Pipelining策略。 但是Pipelining的引入会产生另外一个问题——日志乱序。所以我们开发了一个高效处理乱序的模块，通过它来屏蔽底层日志乱序带来的影响，同时结合我们的异步化并发提交加大我们在接收端的处理能力。 X-PAXOS性能表现 做完了这些优化之后，我们看一下性能对比：
X-DBvsMySQL5.7GR： 蓝色是X-DB，橘色是MySQL。在同城Insert的场景之下，我们可以做到MySQL的2.4倍。
在跨城的情况下，这个差距会进一步的拉大，表现出了我们Batching和Pipelining优化后的效果。 X-DB高性能的保证——X-Engine
我们为什么要重新开发一个数据库引擎?基于这几点： 1、近几年国产硬盘发展迅猛，但是关系型数据库却没有很大突破，所以我们希望通过自研的方式将最新的软硬件进行结合，重新打造一个性能强大的数据库引擎，来解决资源利用率为问题。 2、基于双十一的交易压力，我们需要一个写入性能强大的数据库引擎，同时也希望可以节约成本。 为了高性能低成本，我们开始自研X-Engine。它有两大核心：数据自动冷热分层和基于数据分层架构下的计算和存储优化。 在高性能方面为了加大吞吐，我们会使用BatchGroup和PipelineCommit，为了减少锁资源的争用，我们会实现LockFree和LatchFree以及自适应的并发控制和FPGA技术。在低成本方面我们会使用数据分成存储、自适应的数据生命周期管理、行列混合存储和针对不同的数据类型做到自适应的Encoding，以及使用压缩技术。 X-Engine架构
X-Engine借鉴了LSM-tree的思想，即所有写入数据不会直接修改已有数据，而是使用CopyonLayout的方式追加到MemTable里面。 在数据存储方面，会记录数据的访问热度，把数据划分为大小不一样的Key-rang，存放在不同的数据文件中。访问热度比较高的数据存放在高速的存储设备上，访问热度较低的数据存储在比较廉价的存储设备上，并且进行压缩处理。 在内存方面，由于X-Engine无论是读还是写或者是元数据管理都使用MemTable，它对读写的吞吐性能要求很高，所以我们采用了Skiplist代替原来的B-Tree，这样更容易实现lock-free减少锁的争用。 FPGA加速
使用LSM-tree的数据库都存在一个问题，它们必须要对数据进行合并，即Compaction操作。Compaction很占用系统资源，它可能会给一个高压态的数据库带来抖动，甚至影响业务。所以，我们在X-Engine上引入FPGA异构计算芯片进行加速。 通过这两张图我们可以对比一下，在没有FPGA的时候，相关的Compaction任务都会交由CPU执行;使用了FPGA之后，CPU只负责Compaction任务的生成和调度，真正执行数据合并的被Offload到FPGA加速单元去操作。 性能对比
蓝色的是X-Engine-CPU，橘色的是X-Engine-FPGA。很明显，X-Engine-CPU性能抖动比较大，而X-Engine-FPGA相对平稳。 这里面存在一个很大的挑战：我们要给FPGA设计一款适合做Compaction的并发流水线，以及通过容错优化解决FPGA内部内存翻转的问题。 如果把图放大，我们还是会发现X-Engine-FPGA曲线也有性能抖动，这也是我们需要进一步优化的地方。 X-DB架构的演进
这是一个标准的应用访问数据库链路图。不同于以前的是，我们把数据库的计算节点从物理级换成了Docker容器。年，阿里巴巴数据库实现了全网百分之百的容器化部署。 不同于其他应用，数据库是有状态的，仅仅依赖容器化无法解决数据库弹性部署问题。所以，我们需要引用一个新技术——存储与计算分离，把数据存放在分布式的存储集群上，通过高速的网络和RDMA技术把整个架构串联起来。 优点： 1、存储容量不再受限于单机物理磁盘的大小。 2、对数据库进行扩容、缩容，不再需要迁移数据。 3、实现了更精确的成本控制。 用户态文件系统
为了进一步提升存储与计算分离的性能，我们开发了一个用户态的文件系统。通过这个文件系统，我们绕过了原来Linux内核态的IOG系统，计算节点跟存储节点可以直接通过RDMA进行数据传输。 一写多读
怎样实现一写多读? 这是一个X-DB集群，我们使用了存储与计算分离，底层共用同一份数据。这里面有一个写节点和多个读节点，由于X-Engine对数据的写入不会直接修改元数据，所以我们通过X-PAXOS把这些日志同步到每一个读节点，读节点会应用这些日志更新MemTable，再结合底层共用的sit文件，就可以做到跟读节点一致的数据。通过这种方式，我们就可以快速搭建一个一写多读的X-DB集群。 TablePartition
光有读的扩展能力也不能满足业务需求，还需要有写的扩展能力。在介绍写的扩展能力之前，我先引入一个概念——TablePartition。TableFamily类似于分库分表中的逻辑总表，Table1、2、3就是每一张物理值子表。在X-DB，我们还会将每一张子表分为多个Partition，并且有元数据记录Partition对应哪个MemTable以及数据文件位置。 动态计算节点扩容
这个架构图同样是一个使用了存储和计算分离的X-DB集群。我们的应用通过X-DRIVER联系X-DB集群，对于TablePartition的分距信息，有一份会存放在X–DRIVER。如果需要对TablePartition1和2进行数据修改，它会被路由到第一个X-SERVER上，如果需要对TablePartition3和4进行修改，它会被路由到第二个X-SERVER上，同时这些修改都会通过X-PAXOS同步到集群的每一个节点。 那么怎样做写节点呢?如下图所示：
只需要把TablePartition2的写入切换到第4个X-SERVER，TablePartition4的写入切换到第3个X-SERVER，然后更新元数据。通过这样的切换方式，整个集群的写入点从原来的两个变成四个，整个集群的TPS能力提高了一倍。 因此，通过X-DB各种组件的配合，以及架构调整，我们实现了数据库架构的高度扩展。
所有新技术的落地都会经历预研、验证、部署三个阶段，在年，阿里已经在其中一个交易单元对第四代数据库架构(X-DB)进行了充分验证。今年我们也会继续往前推进，做到两个百分百：百分百全网存储与计算分离覆盖、百分百X-DB部署。同时第四代数据库架构更深入的技术也会重新投入到这个循环当中。