淘宝TDDL研发历史和背景
分散式关系型数据库服务（Distribute Relational Database Service，简称DRDS）是一种水平拆分、可平滑扩缩容、读写分离的线上分散式数据库服务。前身为淘宝TDDL。
淘宝DRDS/TDDL是阿里巴巴自主研发的分散式数据库服务。DRDS脱胎于阿里巴巴开源的Cobar分散式数据库引擎，吸收了Cobar核心的Cobar-Proxy源代码，实现了一套独立的类似MySQL-Proxy协议的解析端，能够对传入的SQL进行解析和处理，对应用程序遮蔽各种复杂的底层DB拓扑结构，获得单机数据库一样的使用体验，同时借鉴了淘宝TDDL丰富的分散式数据库实践经验，实现了对分散式Join支援，SUM、MAX、COUNT、AVG等聚合函式支援以及排序等函式支援，通过异构索引、小表广播等解决分散式数据库使用场景下衍生出的一系列问题，最终形成了完整的分散式数据库方案。
使用场景
分散式数据库核心诉求在于解决单机数据库的瓶颈，单机数据库在使用过程中不可避免会遇到数据库容量、连线数、事务数、读效能瓶颈，突破这些瓶颈的两种通用的解决模型是单机垂直扩充套件scale up模型和水平扩充套件scale out模型。
单机扩充套件模型和硬件资源强系结，普遍采用升级单机硬件能力的方式，实现数据库服务能力扩充套件，比如原来采用MySQL单机数据库，遇到访问瓶颈时更换磁盘，访问量更高时就需要考虑使用Oracle的商用解决方案、高阶的储存装置、高阶小型机，也就是IOE架构，甚至升级IOE装置，以换取更高的扩充套件和服务能力，这个过程就会存在装置升级和资料迁移的成本。
多机器用水平扩充套件模型使用大量廉价的PC-Server，通过阵列的方式来实现数据库的水平扩容，优势在于成本更低，因为不需要淘汰老装置和系统，不需要频繁迁移资料，需要时，只需扩容服务丛集规模。
使用分散式多机模型也需要付出一定成本，分散式数据库的架构与单机数据库的逻辑和物理分布存在比较大差异，因此需要将单机数据库的资料迁移到分散式架构模型之下，也就是Sharding的资料分片过程，这个过程涉及资料的分散式逻辑设计、数据库迁移和SQL的优化改造，当然这个迁移一次性的，当架构迁移完成之后，就无需再关心数据库扩容和资料迁移问题，因为分散式数据库的服务层已经集成了扩容功能，架构上支援水平能力扩充套件。
2006年之前我们的核心应用普遍采用Oracle数据库，但随着业务快速发展，淘宝的资料量和访问量急剧增加，数据库出现严重访问效能问题，导致数据库频繁宕机、业务停滞，即使当时已经使用Oracle亚洲最大的RAC丛集，单机数据库的扩充套件能力已经达到极限，且需要付出巨大的资金和运维成本，因此我们基于自己的实际情况，逐步开始去IOE，研发分散式关系型数据库服务，实现数据库的高扩充套件和成本可控，目前DRDS已经成为我们内部分散式数据库的标准，并且对外服务于金融、制造、-机构、电商、社交等各行业。
DRDS的整体架构
DRDS/TDDL是典型的水平扩充套件分散式数据库模型，区别于传统单机数据库share anything架构，DRDS/TDDL采用share nothing架构，share nothing架构核心思路利用普通的服务器，将单机资料拆分到底层的多个数据库例项上，通过统一的Proxy丛集进行SQL解析优化、路由和结果聚合，对外暴露简单唯一的数据库连结。整体架构如图1所示，包含DRDS服务模组、DRDS管控模组、配置中心、监控运维、数据库服务丛集、域名服务模组。
通过分散式丛集管理模组实现对丛集节点的管控。在资料安全和服务可用性方面，通过高效的资料同步系统，实现数据库的扩容和数据库例项的主备资料同步。同时依赖例项监控模组和HA模组实现主备的监控和自动化容灾切换。作为成熟的分散式数据库产品，TDDL也具备完善的运维管控系统，能够实现分散式数据库多例项之间的配置管理、变更，以及各种资料同步、扩容等任务管理，降低运维成本。
DRDS/TDDL的功能特性
资料分片
DRDS的基础原理就是Sharding，也就是资料分片。将单机数据库的资料拆分到多个单机数据库上，对外保持逻辑的一致性。后端拆分的数据库为分库，对应的表称为分表，每个分库负责一份资料的读写操作，分散整体访问压力。在系统扩容时，只需水平增加分库数量，并迁移相关资料，即可提高DRDS系统总体容量。
资料分片需要选择一个分片的拆分纬度，也就是资料分布的依据。比如一个使用者订单资讯表，如果按照订单ID做资料拆分，那么相同订单ID的资料就会被拆分到同一个数据库储存节点，如果按照使用者ID做资料拆分，那么同一个使用者的订单就会分布到同一个数据库储存例项的储存节点。
拆分纬度的选择非常重要，一般来说要根据实际业务的场景选择拆分键，总体指导原则是尽量保证每一个数据库节点的资料量和负载更均衡，单条SQL操作尽量落到单个数据库节点执行，不同SQL的查询落到不同的数据库节点。这样可以减少多个节点之间的网络传输，保持分散式查询的效率，均衡负载的同时也便于扩充套件。
平滑扩容
数据库的扩容是数据库运维的常见操作，当数据库的资料储存容量不足时，传统的单机数据库需要提升单机的储存空间来支援更大的资料写入量，而随着资料量膨胀，同样的SQL查询语句，查询的基础资料量增加必然会降低查询效率；同时随着资料量增加，数据库的访问压力通常也会成倍提升，造成单机数据库连线数到达极限，此时单机数据库就需要通过升级硬件规格，使用磁盘阵列，使用高阶的储存介质装置和更高阶的小型机服务器来承载资料量和访问量的增加，这个过程会伴随大量的资料迁移，为了保证资料的一致性通常需要停机资料迁移，对业务影响较大。
DRDS的分散式架构采用平滑扩容的方式来解决上述问题，通过增加更多的底层数据库例项来完成整体丛集扩容。
平滑扩容的前提是使用者需要按照前述的分库分表逻辑，将逻辑数据库拆分为多个物理分库，不同的分库落在不同的底层物理数据库机器上。分库分表的数量通常建议使用者预估未来3-5年的资料量增长情况，按照这个资料量计算总体资料应该拆分为多少个分库，因为单个分库的资料量通常会有一个建议值，超过这个阈值就会造成单个节点效能下降。有了具体的分库数量后，就可以按照分库的逻辑将资料拆分到不同的储存例项节点上，当承载分库的物理数据库机器出现容量和连线数不足等瓶颈问题时，就可以新增物理数据库节点，将原有的分库迁移到新的物理数据库节点上，实现整体逻辑数据库的扩容。
扩容过程实际是物理资料迁移的过程，引擎层按照分库迁移后的逻辑先在物理节点上建立新的分库，然后保留一个时间点进行全量的资料迁移。完成全量迁移后，开始基于先前保留的时间点进行增量的资料追赶。当增量资料追赶到两边的资料几乎一致时，对数据库进行瞬时停写，将最后的资料追平，引擎层进行分库逻辑的路由切换，路由规则切换完成后就完成了核心的扩容逻辑，整个切换过程在毫秒级别完成。
为了保证资料本身的安全，便于扩容回滚，在路由规格切换完成后，迁移前后的逻辑分库资料还会进行实时同步，直到业务确认后，才可清理原有分库资料。
整个扩容过程对上层的业务访问几乎无感知，是完全平滑的扩容，但仍需注意扩容的操作尽量选择在数据库访问，尤其是写入的低谷期进行，避免切换时过多的资料追赶时间。
分散式MySQL执行引擎
分散式数据库的资料有规律地储存在多个底层储存例项上，资料物理储存的变化会造成与原生的数据库引擎不相容，单机数据库所有的资料读取、写入、计算都在单一的物理机上执行，资料状态维持在单机上，主要的效能消耗在于磁盘的资料读取；而分散式架构下，资料和状态需要在多个数据库例项之间以及底层例项和Proxy之间进行传输，这会造成网络I/O消耗，而网络I/O对效能造成消耗相较于本地磁盘I/O和本地计算的效能开销而言要大得多。
因此分散式SQL引擎主要目标是实现与单机数据库SQL引擎的完全相容，实现SQL的智慧下推。能够智慧分析SQL，解析出哪些SQL可以直接下发，哪些SQL需要进行优化改造，优化成什么样，以及路由到哪些例项节点上执行，充分发挥数据库例项的全部能力，减少网络之间的资料传输量，最终对不同例项处理后的少量结果资料进行聚合计算返回给应用呼叫方。这就是分散式SQL引擎的智慧下推功能。
分散式引擎的职责包含SQL解析、优化、执行和合并四个流程，如图4所示。
智慧下核心原则有如下几个：
减少网络传输；减少计算量，尽量将计算下推到下层的资料节点上，让计算在资料所在的机器上执行；充分发挥下层储存的全部能力。基于以上原则实现的SQL引擎，就可以做到服务能力线性扩充套件。比如一个简单的AVG操作，对于一些比较初级的分散式数据库模型而言，常见做法是把AVG直接下发到所有的储存节点，这样造成的结果就是语法相容，语意不相容，最终拿到的是错误结果。而DRDS的智慧下推引擎，对SQL的语法做充分的语意相容性适配，针对AVG操作，只能由引擎将逻辑AVG SQL解析优化为SUM和COUNT的SQL然后进行下推，由底层的数据库例项节点完成SUM和COUNT计算，充分利用底层节点的计算能力，在引擎层将各个储存节点的SUM和COUNT结果聚合计算，最终计算出AVG。这只是一个非常典型的案例，在分散式数据库模型下，多资料表的Join操作，归并排序的相容性非常复杂，下文会针对典型的场景解析TDDL/DRDS如何解决分散式场景下的具体问题。
弹性扩充套件
TDDL/DRDS采用服务和储存分离的架构，DRDS例项服务层通过丛集方式部署，由多个服务节点构成一个服务例项，通过负载均衡以及域名服务对外提供服务，多个服务节点之间无状态同步，平均负载处理使用者请求。服务丛集处理能力不足时，可随时扩充服务节点，增加服务处理能力。同样，业务低谷期也可适当降低丛集规模，做到弹性的服务能力扩充套件。
对于一些大资料量OLAP的场景，对于单个Server节点的内存资源需求高时，也可通过提升单个Server节点的规格，做到垂直的能力扩充套件。
分散式Join和小表广播
分散式场景下的Join操作和单机不同，单机资料的Jion操作发生在单机上，不存在内部网络资料传输。
在分散式架构下的多个数据表Jion，如果参与Join的多表资料切分纬度不同，资料则按照不同的拆分纬度分散在不同的数据库例项上，Join操作可能产生跨多个物理分库的Join，就需要进行多个底层例项的大量资料传输，SQL的执行效率就得不到保证，因此要参与Join操作的资料表要尽量保持拆分纬度统一，让Join操作尽量发生在单机上，减少跨库Join。如果不能保持拆分纬度的统一，存在跨库Join操作，那么原则就是尽量减少Join操作的输出传输。
DRDS通常使用的Join算法基于Nested Loop，对于Join的左右两个表，首先从Join的左表（驱动表）取出资料，然后将所取出资料中Join列的值放到右表并进行IN查询，从而完成Join过程。因此，Join的左表资料量越少，DRDS对右表做IN查询就次数就越少，如果右表的资料量也很少或建有索引，则Join的速度更快。故而在DRDS中，Join驱动表的选择对于Join的优化非常重要。
而在实际数据库场景中，经常有一些源资讯表，资料量较小，更新频度也很低，这些表无需拆分，类似这些源资讯表通常采用单表模式，单表模式下一个逻辑表的资料统一储存在一个分库中，通常储存在“0”库，将这些表定义为“小表”，而其他业务资料量大、更新频率高的表仍旧采用分库分表的拆分模式。那这些“小表”和分库分表进行Join时，基于Nested Loop算法的原则，小表作为Join的驱动表会大大减少右表的IN查询次数，同时DRDS提供的小表广播功能，通过资料实时复制，将“小表”的全量资料和增量变更实时复制到分库分表上，将跨库的Join转化为单机Join操作，减少Server节点的计算，降低资料在多个底层例项之间的传输，Jion的效率提升会非常明显。
异构索引
异构索引是DRDS提升分散式查询效率的解决方案之一，能够解决分散式场景下资料拆分纬度和资料查询使用纬度不一致导致的低效问题。
当资料表被拆分为多个分库分表时，资料在分库分表的分布规则就固定了。但是通常资料的业务使用场景非常复杂，如果资料的查询纬度和资料拆分分布的规则一致，单条SQL会在一个分库分表上执行；如果资料的查询使用纬度和资料拆分分布的规格不一致，单条SQL就很有可能在多个分库分表上执行，出现跨库查询，跨库查询会增加网络I/O的成本，查询效率必然下降。
解决这个问题的思路还是分散式数据库的一贯原则，让SQL执行在单库上完成，实际采用的方式就是用“空间换效率”的方案，也就是将同一份资料表，冗余储存多份，按照不同的业务使用场景进行拆分，保持拆分纬度和使用纬度统一，而多份资料之间会实时资料复制以解决资料一致性问题，这就是“异构索引”方案。当然异构索引表不能无限制滥用，过多的异构索引表会影响同步效率，对源资料表造成同步压力。
最佳实践
分散式SQL优化
SQL优化是数据库使用和运维的日常操作，分散式数据库针对SQL的优化不仅要考虑磁盘I/O的开销，更要关注网络I/O开销。为了优化SQL执行，其核心的优化思想就是减少网络I/O。为此，DRDS会尽量将原本DRDS这一层的工作均衡下发到其底层的各个分库（如RDS 等）来做。这样就可以将原本需要走网络的I/O开销转换为单机的磁盘I/O开销，从而提升查询执行效率。因此，我们在使用DRDS时若遇到了慢SQL，则需针对DRDS的特点将适当改写SQL。
首先是条件查询优化，DRDS的资料按拆分键进行水平切分，查询中若带上拆分键对于减少SQL在DRDS的执行时间很有意义。查询条件尽量带分库键，就可以让DRDS根据分库键的值将查询直接路由到特定的分库，这有助于避免DRDS做全库扫描。含分库键的条件精度越高，越有助于提高查询速度，也只有这样的优化才能充分发挥分散式架构查询的优势，便于后续查询能力的扩充套件。
其次针对Join的优化，选择条件查询资料量少的Join表作为左表（驱动表），降低右表IN查询的次数；在资料量少且变更量少的“广播表”参与的Jion操作，将“广播表”作为驱动表。
针对LIMIT OFFSET、COUNT语句，DRDS实际SQL执行是依次将OFFSET之前的记录资料读取出来，并丢弃，只保留OFFSET之后的资料，这样当OFFSET非常大时，读取的资料记录数很少，效率也很低，因为OFFSET之前的资料读取需要执行大量的磁盘I/O读取操作。优化方式是将SQL优化为对key的OFFSET读取和IN操作两个步骤，先读取OFFSET之后的记录key，内存中快取这些key，然后再通过IN查询获取完整的记录资讯，这样会大大减少磁盘I/O，效率提升非常明显。
分散式事务优化
分散式数据库的事务和SQL查询优化的逻辑是一样的原则，尽量让事务在单库中执行，只有在单库中执行，才可以在保持事务ACID特性的同时，还能线性地扩充套件事务能力。这种单库事务通常称为“强事务”。
实际业务也经常会面临分散式数据库架构下，数据库事务不可避免出现跨库执行。跨库事务必然涉及到一个事务在多个分库上进行事务分支的执行和状态同步，相比单机事务，分散式跨库事务的吞吐量和延迟会大大增加。而事务涉及的分库越多，事务边界越大，事务的延迟也会相应增加，效能就会出现线性衰减。
遇到跨库事务，通常的实践优化方式是通过“最终一致”事务保证事务执行的吞吐量。“最终一致”事务的原理是优先保证核心事务分支的正向执行，然后储存事务中间状态，其他事务分支异步执行，执行完成后达到最终的事务一致，避免跨库事务时间序列执行阻塞，提升事务吞吐量。如图8所示，事务3和事务5是跨库事务，事务分支先在左边库进行，异步的事务分支在右边分库执行，分别在自己所在的分库顺序执行，最终达到事务一致性。
单机数据库迁移到DRDS的流程
单机数据库迁移到分散式数据库要保证的就是业务正常运转、平滑过渡、减少运维，整个迁移分为三个步骤。
第一步，读写保持在原有的数据库上，资料通过复制机制写入分散式数据库，前提是分散式目标库表已经建好；
第二步，验证云上资料是否正确，切部分读取流量到目标的分散式数据库上读取线上压力验证（测试环境提前验证也可保证）；
第三步，业务听写几分钟，读写的流量切换到目标库，资料反向复制到源单机数据库，保证随时可切换回单机数据库，同时也可做云下资料备份。
未来的发展
DRDS作为分散式资料体系中的数据库服务中间层，未来会适配更多底层储存引擎，在充分利用底储存节点的计算能力的同时，优化本身服务的计算能力，解决OLAP场景，成为能够完整覆盖OLTP和OLAP以及其他一些数据库服务场景的完备的分散式数据库服务体系。同时完备分散式数据库逻辑层的运维支援和分散式强一致事务的支援。
