1、阿里巴巴分布式数据层平台生长和演变

业务数据从本来的单库单表形式变成了数据被拆分到多个数据库，甚至少个表中，若是在数据访谒层做一下功能的封装和管控，所有分库分表的逻辑和数据的跨库把持都交给应用的开发人员来实现，则对开发人员的要求变得相对高一点，稍有不慎，可能会对平台的业务网罗数据带来较大的影响。

在2006年阿里巴巴B2B团队以开源编制研发了Cobar这一关系型数据的分布式措置体系。该体系在很洪流平上处理了最后使用Oracle数据库由于存储数据变得越来越大带来的扩展性问题，并且为开发人员供给了一个使用相对简单的用户体验，在那时Cobar均匀天天措置近50亿次的SQL把持。但跟着阿里巴巴业务场景越来越复杂，Cobar平台功能上的束缚对满足某些业务场景显得力有未逮，例如：

1）不支撑跨库情形下的毗连、分页、排序、子查询把持。

2）SET语句实行会被忽略，措置事务和字符集设置除外。

3）分库情形下，insert语句必需包含拆分字段列名。

4）分库情形下，update语句不能更新拆分字段的值。

5）不支撑SAVEPOINT把持。

6）使用JDBC时，不支撑rewriteBatchedStatements=true参数设置（默认为false）。

7）使用JDBC时，不支撑useServerPrepStmts=true参数设置（默认为false）。

8）使用JDBC时，BLOB、BINARY、VARBINARY字段不能使用setBlob()或setBinaryStream()编制设置参数。

2008年阿里巴巴内部基于淘宝业务生长的必要，在Cobar的根本上重新研发了分布式数据层框架TDDL（Taobao Distributed Data Layer，外号：头都大了），针对分库分表场景，供给了对各类业务场景的支撑加倍完满，开发人员体验加倍友爱，管控才能大幅晋升。

今朝TDDL已经成为阿里巴巴集团内部业务默认使用的分布式数据层中心件，支持着今天阿里巴巴上千个应用，均匀天天SQL挪用超千亿次。从架构角度（如图5-3所示），TDDL相沿了Cobar之前在应用和后端数据库之间的定位，经由过程添加对SQL的解析实现了更为精准的路由节制，以及对跨库join、统计等计较的支撑，填补了之前Cobar在功能上的束缚和限定，成为一个完好支撑SQL语法兼容的平台。

图5-3TDDL架构示意图

三层数据源每层都按JDBC标准实现，使得对前端应用没有任何代码侵入。

Matrix层（TDataSource）实现分库分表逻辑，底下持有多个GroupDs实例。

Group层（TGroupDataSource）实现数据库的主备/读写分手逻辑，底下持有多个AtomDs实例。

Atom层（TAtomDataSource）实现数据库毗连（ip、port、password、connec-

tionProperties）等信息的动态推送，持有原子的数据源。

经由过程TDDL实现一次来自应用的SQL哀求，完好的交互流程（如图5-4所示）中浮现了各个办事组件所起到的浸染。

图5-4TDDL针对一次SQL哀求完好措置流程

恰是有了如许的架构和设计，特别是添加了对SQL语义的解析，使得TDDL比力之前的Cobar在功能上晋升了一个新的层级，对付Cobar不支撑的跨库数据聚合、子查询、group by、order by等特征都有了很好的支撑，从而成为在分库分表手艺业界被良多手艺同仁认可的一套分布式数据层框架，总结来说，TDDL供给了以下利益：

• 数据库主备和动态切换。

• 带权重的读写分手。

• 单线程读重试。

• 集中式数据源信息办理和动态变换。

• 支撑MySQL和Oracle数据库。

• 基于JDBC标准，很随意扩展支撑实现JDBC标准的数据源。

• 无Server、client-jar情势存在，应用直连数据库。

• 读写次数，并发度流程节制，动态变换。

• 可分析的日志打印，日志流控，动态变换。

跟着阿里巴巴集团业务的多元化，特别是对付除电商规模以外业务的不竭扩展和并购，TDDL这种无Server的形式对付故障的定位和对运转情形的要求（必需是阿里巴巴内部办事情形），支撑这些新兴业务有了不少坚苦，所以在2014年，阿里巴巴已经研发出新一代分布式数据库产物DRDS（Distributed Relational Database Service），该产物比力TDDL在业务场景的支撑、故障的定位、运维管控等方面又有了一个全面的晋升，今天DRDS已经成为阿里云上用于处理关系型数据库线性扩展问题的标准云产物，办事了几百家阿里巴巴集团外部的客户。

2、数据尽可能均匀拆分

不管是接纳何种分库分表框架或平台，其焦点的思绪都是将本来保留在单表中太大的数据停止拆分，将这些数据分手保留到多个数据库的多个表中，按捺由于单表数据太大给数据的访谒带来读写机能的问题。所以在分库分表场景下，最重要的一个准绳就是被拆分的数据尽可能的均匀拆分到后端的数据库中，若是拆分得不均匀，还会产生数据访谒热点，同样存在热点数据由于添加过快而又面临数据单表数据过大的问题。

而对付数据以什么样的维度停止拆分，大师看到良多场景中都是对业务数据的ID（大局部场景此ID是以自增的编制）停止哈希取模的编制将数据停止均匀拆分，这个简单的编制确其实良多场景下都是非常适宜的拆分编制，但并不是在所有的场景中如许拆分的编制都是最优选择。也就是说数据若何拆分并没有所谓的清规戒律，更多的是必要连系业务数据的构造和业务场景来抉择。

下面以大师最熟悉的电商订单数据拆分为例，订单是任何一个电商平台中都市有的业务数据，每个淘宝或天猫用户在平台上提交订单后都市在平台后端生成订单相干的数据，一样平常记实一条订单数据的数据库表构造如图5-5所示。

订单数据首要由三张数据库表构成，主订单表对应的就是用户的一个订单，每提交一次都市生成一个主订单表的数据。在有些情形下，用户可能在一个订单中选择不合卖家的商品，而每个卖家又会按照该订单中是本身供给的商品计较相干的商品优惠（比如满88元免快递费）以及放置相干的物流配送，所以会出现子订单的概念，即一个主订单会由多个子订单构成，而真正对应到详细每个商品的订单信息，则是保留在订单详情表中。

图5-5　订单相干数据表构造示意

若是一个电商平台的业务生长安康的话，订单数据是斗劲随意出现由于单个数据库表中的数据太大而形成机能的瓶颈，所以必要对它停止数据库的拆分。此时从理论上对订单拆分是可以由两个维度停止的，一个维度是经由过程订单ID（一样平常为自增ID）取模的编制，即以订单ID为分库分表键；一个是经由过程买家用户ID的维度停止哈希取模，即以买家用户ID为分库分表键。

两种方案做一下比力：

若是是按照订单ID取模的编制，比如按64取模，则可以保证主订单数据以及相干的子订单、订单详情数据均匀落入到后端的64个数据库中，准绳上很好地满足了数据尽可能均匀拆分的准绳。

经由过程接纳买家用户ID哈希取模的编制，比如也是按64取模，手艺上则也能保证订单数据拆分到后端的64个数据库中，但这里就会出现一个业务场景中带来的一个问题，就是若是有些卖家是生意量很是大的（如许的群体不在少数），那这些卖家产生的订单数据量（特别是订单详情表的数据量）会比其他卖家要多出不少，也就是会出现数据不均匀的征象，终极导致这些卖家的订单数据地点的数据库会相对其他数据库提早进入到数据归档（为了按捺在线生意数据库的数据的增大带来数据库机能问题，淘宝将3个月内的订单数据保留进在线生意数据库中，跨越3个月的订单会归档到后端专门的归档数据库）。

所以从对“数据尽可能均匀拆分”这条准绳来看，按照订单ID取模的编制看起来是更能保证订单数据停止均匀拆分，但我们临时不要这么快下结论，让我们继续从下面几条准绳和最佳理论角度多思虑不合的拆分维度带来的优错误错误。

3、尽量减少事务鸿沟

不管是TDDL平台仍是DRDS，接纳分库分表的编制将业务数据拆分后，若是每一条SQL语句中都能带有分库分表键，如图5-6所示是以自增的订单ID以8取模，将订单均匀分布到8个数据库的订单表中，经由过程度布式办事层在对付SQL解析后都能精准地将这条SQL语句推送到该数据地点的数据库上实行，数据库将实行的成效再前往给分布式办事层，分布式办事层再将成效前往给应用，整个数据库访谒的过程跟之前的单机数据库把持没有任何不合。这个是在数据停止了分库分表拆分后，SQL语句实行服从最高的编制。

图5-6DRDS对带分库分表键的SQL哀求措置

但不是所有的业务场景在停止数据库访谒时每次都能带分库分表键的。比如在买家中心的界面中，要表示买家test1曩昔三个月的订单列表信息，由于该买家test1的订单按订单ID取模的编制分布到了不合的数据库中，此时SQL语句中就没有了分库分表键值，则出现了如图5-7所示的情形，分布式数据层会将获取test1订单的SQL语句推送到后端所稀有据库中实行，然后将后端数据库前往的成效在分布式数据层停止聚合后再前往给前端应用。

图5-7DRDS对不带分库分表键的SQL哀求停止全表扫描措置

此时就出现了我们所说的全表扫描。此时我们来诠释一下这里“事务鸿沟”的界说，所谓的事务鸿沟便是指单个SQL语句在后端数据库上同时实行的数目，上面示例中就是事务鸿沟大的典范示例，即一条SQL语句同时被推送到后端所稀有据库中运转。事务鸿沟的数目越大，会给体系带来以下弊端：

体系的锁辩说概率越高。若是事务鸿沟大的SQL哀求斗劲多，在一次SQL哀求措置过程中天然对付后端的数据库把持的数据库记实笼盖斗劲广，当有多个近似的SQL哀求并行实行时，则出现数据锁形成的资源访谒互斥的概率会大大添加。

体系越难以扩展。若是有大量的SQL哀求都是如许全表扫描，或者从极端角度声名这个问题，若是每一次的SQL哀求都必要全表扫描实行，你会创造整个平台的数据库毗连数目是取决于后端单个数据库的毗连才能，也就意味着整个数据库的才能是无法经由过程添加后端数据库实例来扩展的。所以若是有大量的全表扫描的SQL哀求对付体系的扩展才能会带来不小的影响。

团体机能越低。对付机能，这里想强调的是对体系团体机能的影响，而不是单次SQL的机能。应用发送获取买家test1订单列表SQL的哀求（如图5-8轨范①）时，分布式数据层会并行的将这条SQL语句推送（如图5-8轨范②）到后端8台数据库上运转，由于订单数据停止了均匀的拆分，单个数据库订单表的数据量巨细都使得数据库处于最佳机能默示的状态，所以意味着每一个数据库前往的计较成效都是在一个可期望的时辰内（比如100毫秒），将成效前往到分布式数据层（如图5-8轨范③），分布式数据层将从各个数据库前往来的成效在内存中停止聚合或排序等把持（如图5-8轨范④），末了前往订单列表给应用（如图5-8轨范⑤）。

6、简单就是美

在真实的世界中，选择的坚苦往往是由于布满着各类勾引，选择A方案，有这些好处；而选择B方案，也会有别的一些好处。

若是在“尽量减小事务鸿沟”与“数据尽可能均匀拆分”两个准绳间产生了辩说，那么请选择“数据尽可能均匀拆分”作为优先考虑准绳，由于事务鸿沟的问题相对来说更好处理，无论是做全表扫描或做异构索引复制都是可以处理的。而写入或单机容量若是出现不服衡，那么措置起来难度就斗劲大。

虽然复杂的切分轨则或数据的异构索引可以给体系的机能和扩展性带来明显的收益，但厥后面所带来的体系运维复杂度上升也是不能轻忽的一个成效。