背景
2016年Q3季度初，在美团外卖上单2.0项目上线后，商家和商品数量急速增长，预估商品库的容量和写峰值QPS会很快遇到巨大压力。随之而来也会影响线上服务的查询性能、DB（数据库，以下统一称DB）主从延迟、表变更困难等一系列问题。
要解决上面所说的问题，通常有两种方案。第一种方案是直接对现有的商品库进行垂直拆分，可以缓解目前写峰值QPS过大、DB主从延迟的问题。第二种方案是对现有的商品库大表进行分库分表，从根本上解决现有问题。方案一实施起来周期较短，但只能解决一时之痛，由此可见，分库分表是必然的。
在确定分库分表的方案之后，我们调研了外卖订单、结算以及主站等业务的分库分表实现方案，也调研了业界很多分库分表中间件。在综合考虑性能、稳定性及实现成本的前提下，最终决定自主研发客户端分库分表中间件MTDDL来支撑外卖商品分库分表项目，这也就是MTDDL的由来。
当然，在MTDDL的设计研发过程中，我们充分考虑了MTDDL的通用性、可扩展性、功能的全面性和接入的便利性。到目前为止一共开发了四期，实现了MySQL动态数据源、读写分离、分布式唯一主键生成器、分库分表、连接池及SQL监控、动态化配置等一系列功能，支持分库分表算法、分布式唯一主键生成算法的高可扩展性，而且支持全注解的方式接入，业务方不需要引入任何配置文件。
下面就部分业界方案及MTDDL的设计目标详细展开下，然后从源码的角度来剖析下MTDDL的整个逻辑架构和具体实现。
业界调研
设计目标
MTDDL（Meituan Distributed Data Layer），美团点评分布式数据访问层中间件，旨在为全公司提供一个通用数据访问层服务，支持MySQL动态数据源、读写分离、分布式唯一主键生成器、分库分表、动态化配置等功能，并且支持从客户端角度对数据源的各方面（比如连接池、SQL等）进行监控，后续考虑支持NoSQL、Cache等多种数据源。
功能特性
1.动态数据源
2.读写分离
3.分布式唯一主键生成器
4.分库分表
5.连接池及SQL监控
6.动态化配置
逻辑架构
下图是一次完整的DAO层insert方法调用时序图，简单阐述了MTDDL的整个逻辑架构。其中包含了分布式唯一主键的获取、动态数据源的路由以及SQL埋点监控等过程：
具体实现
动态数据源及读写分离
在Spring JDBC AbstractRoutingDataSource的基础上扩展出MultipleDataSource动态数据源类，通过动态数据源注解及AOP实现。
动态数据源
MultipleDataSource动态数据源类，继承于Spring JDBC AbstractRoutingDataSource抽象类，实现了determineCurrentLookupKey方法，通过setDataSourceKey方法来动态调整dataSourceKey，进而达到动态调整数据源的功能。其类图如下：
动态数据源AOP
ShardMultipleDataSourceAspect动态数据源切面类，针对DAO方法进行功能增强，通过扫描DataSource动态数据源注解来获取相应的dataSourceKey，从而指定具体的数据源。具体流程图如下：
配置和使用方式举例
分布式唯一主键生成器
众所周知，分库分表首先要解决的就是分布式唯一主键的问题，业界也有很多相关方案：
综上，方案3的缺点可以通过一些手段避免，但其他方案的缺点不好处理，所以选择第3种方案。目前该方案已由美团点评技术工程部实现——分布式ID生成系统Leaf，MTDDL集成了此功能。
分布式ID生成系统Leaf
美团点评分布式ID生成系统Leaf，其实是一种基于DB的Ticket服务，通过一张通用的Ticket表来实现分布式ID的持久化，执行update更新语句来获取一批Ticket，这些获取到的Ticket会在内存中进行分配，分配完之后再从DB获取下一批Ticket。整体架构图如下：
每个业务tag对应一条DB记录，DB MaxID字段记录当前该Tag已分配出去的最大ID值。
IDGenerator服务启动之初向DB申请一个号段，传入号段长度如 genStep = 10000，DB事务置 MaxID = MaxID + genStep，DB设置成功代表号段分配成功。每次IDGenerator号段分配都通过原子加的方式，待分配完毕后重新申请新号段。
唯一主键生成算法扩展
MTDDL不仅集成了Leaf算法，还支持唯一主键算法的扩展，通过新增唯一主键生成策略类实现IDGenStrategy接口即可。IDGenStrategy接口包含两个方法：getIDGenType用来指定唯一主键生成策略，getId用来实现具体的唯一主键生成算法。其类图如下：
分库分表
在动态数据源AOP的基础上扩展出分库分表AOP，通过分库分表ShardHandle类实现分库分表数据源路由及分表计算。ShardHandle关联了分库分表上下文ShardContext类，而ShardContext封装了所有的分库分表算法。其类图如下：
分库分表流程图如下：
分库分表取模算法
分库分表目前默认使用的是取模算法，分表算法为 (#shard_key % (group_shard_num * table_shard_num))，分库算法为 (#shard_key % (group_shard_num * table_shard_num)) / table_shard_num，其中group_shard_num为分库个数，table_shard_num为每个库的分表个数。
例如把一张大表分成100张小表然后散到2个库，则0-49落在第一个库、50-99落在第二个库。核心实现如下：
分库分表算法扩展
MTDDL不仅支持分库分表取模算法，还支持分库分表算法的扩展，通过新增分库分表策略类实现ShardStrategy接口即可。ShardStrategy接口包含两个方法：getShardType用来指定分库分表策略，handle用来实现具体的数据源及分表计算逻辑。其类图如下：
全注解方式接入
为了尽可能地方便业务方接入，MTDDL采用全注解方式使用分库分表功能，通过ShardInfo、ShardOn、IDGen三个注解实现。
ShardInfo注解用来指定具体的分库分表配置：包括分表名前缀tableName、分表数量tableShardNum、分库数量dbShardNum、分库分表策略shardType、唯一键生成策略idGenType、唯一键业务方标识idGenKey；ShardOn注解用来指定分库分表字段；IDGen注解用来指定唯一键字段。具体类图如下：
配置和使用方式举例
连接池及SQL监控
DB连接池使用不合理容易引发很多问题，如连接池最大连接数设置过小导致线程获取不到连接、获取连接等待时间设置过大导致很多线程挂起、空闲连接回收器运行周期过长导致空闲连接回收不及时等等，如果缺乏有效准确的监控，会造成无法快速定位问题以及追溯历史。
再者，如果缺乏SQL执行情况相关监控，会很难及时发现DB慢查询等潜在风险，而慢查询往往就是DB服务端性能恶化乃至宕机的根源（关于慢查询，推荐阅读《MySQL索引原理及慢查询优化》一文）。MTDDL从1.0.2版本开始正式引入连接池及SQL监控等相关功能。
连接池监控
实现方案
结合Spring完美适配c3p0、dbcp1、dbcp2、mtthrift等多种方案，自动发现新加入到Spring容器中的数据源进行监控，通过美团点评统一监控组件JMonitor上报监控数据。整体架构图如下：
连接数量监控
监控连接池active、idle、total连接数量，Counter格式：（连接池类型.数据源.active/idle/total_connection），效果图如下：
获取连接时间监控
监控获取空闲连接时间，Counter格式：（ds.getConnection.数据源.time），效果图如下：
SQL监控
实现方案
采用Spring AOP技术对所有DAO方法进行功能增强处理，通过美团点评分布式会话跟踪组件MTrace进行SQL调用数据埋点及上报，进而实现从客户端角度对SQL执行耗时、QPS、调用量、超时率、失败率等指标进行监控。整体架构图如下：
实现效果
登录美团点评的服务治理平台OCTO选择服务查看去向分析，效果图如下：
动态化配置
为了满足业务方一些动态化需求，如解决线上DB紧急事故需动态调整数据源或者分库分表相关配置，要求无需重启在线修改立即生效，MTDDL从1.0.3版本开始正式引入动态化配置相关功能。
实现方案
在Spring容器启动的时候自动注册数据源及分库分表相关配置到美团点评的统一配置中心MCC，在MCC配置管理页面可以进行动态调整，MCC客户端在感知到变更事件后会刷新本地配置，如果是数据源配置变更会根据新的配置构造出一个新数据源来替换老数据源，最后再将老的数据源优雅关闭掉。具体流程图如下：
动态化数据源
目前支持dbcp、dbcp2、c3p0等数据源，效果图如下：
分库分表动态化
支持动态化配置分库分表数量、分库分表策略、唯一键生成策略、唯一键业务方标识等，效果图如下：
版本迭代
MTDDL到目前为止总共开发了四期，后续考虑逐步开源，具体版本迭代如下：
美团点评技术博客原文链接：http://tech.meituan.com/mtddl.html
