背景
2016年Q3季度初，在美团外卖上单2.0项目上线后，商家和商品数量急速增长，预估商品库的容量和写峰值QPS会很快遇到巨大压力。随之而来也会影响线上服务的查询性能、DB（数据库，以下统一称DB）主从延迟、表变更困难等一系列问题。
要解决上面所说的问题，通常有两种方案。第一种方案是直接对现有的商品库进行垂直拆分，可以缓解目前写峰值QPS过大、DB主从延迟的问题。第二种方案是对现有的商品库大表进行分库分表，从根本上解决现有问题。方案一实施起来周期较短，但只能解决一时之痛，由此可见，分库分表是必然的。
在确定分库分表的方案之后，我们调研了外卖订单、结算以及主站等业务的分库分表实现方案，也调研了业界很多分库分表中间件。在综合考虑性能、稳定性及实现成本的前提下，最终决定自主研发客户端分库分表中间件MTDDL来支撑外卖商品分库分表项目，这也就是MTDDL的由来。
当然，在MTDDL的设计研发过程中，我们充分考虑了MTDDL的通用性、可扩展性、功能的全面性和接入的便利性。到目前为止一共开发了四期，实现了MySQL动态数据源、读写分离、分布式唯一主键生成器、分库分表、连接池及SQL监控、动态化配置等一系列功能，支持分库分表算法、分布式唯一主键生成算法的高可扩展性，而且支持全注解的方式接入，业务方不需要引入任何配置文件。
下面就部分业界方案及MTDDL的设计目标详细展开下，然后从源码的角度来剖析下MTDDL的整个逻辑架构和具体实现。
业界调研
业界组件简介实现方案功能特性优点缺点AtlasQihoo 360开发维护的一个基于MySQL协议的数据中间层项目。它实现了MySQL的客户端与服务端协议，作为服务端与应用程序通信，同时作为客户端与MySQL通信proxy-based实现读写分离、单库分表功能简单，性能跟稳定性较好不支持分库分表MTAtlas原美团DBA团队在开源Atlas基础上做的一系列升级改造proxy-based在读写分离、单库分表的基础上，完成了分库分表的功能开发在Atlas基础上支持了分库分表当时还处于测试阶段，暂不推荐业务方使用TDDL淘宝根据自己的业务特点开发了TDDL框架，主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制，它是一个基于集中式配置的JDBC datasource实现client-based实现动态数据源、读写分离、分库分表功能齐全分库分表功能还未开源，当前公布文档较少，并且需要依赖diamond（淘宝内部使用的一个管理持久配置的系统）ZebraZebra是原点评内部使用数据源、DAO以及监控等和数据库打交道的中间件集client-based实现动态数据源、读写分离、分库分表、CAT监控功能齐全且有监控接入较为复杂，当时只支持c3p0、Druid、Tomcat JDBC等连接池，且分库分表算法只支持Groovy表达式不易扩展设计目标
MTDDL（Meituan Distributed Data Layer），美团点评分布式数据访问层中间件，旨在为全公司提供一个通用数据访问层服务，支持MySQL动态数据源、读写分离、分布式唯一主键生成器、分库分表、动态化配置等功能，并且支持从客户端角度对数据源的各方面（比如连接池、SQL等）进行监控，后续考虑支持NoSQL、Cache等多种数据源。
功能特性
- 动态数据源
- 读写分离
- 分布式唯一主键生成器
- 分库分表
- 连接池及SQL监控
- 动态化配置
逻辑架构
下图是一次完整的DAO层insert方法调用时序图，简单阐述了MTDDL的整个逻辑架构。其中包含了分布式唯一主键的获取、动态数据源的路由以及SQL埋点监控等过程：
具体实现
动态数据源及读写分离
在Spring JDBC AbstractRoutingDataSource的基础上扩展出MultipleDataSource动态数据源类，通过动态数据源注解及AOP实现。
动态数据源
MultipleDataSource动态数据源类，继承于Spring JDBC AbstractRoutingDataSource抽象类，实现了determineCurrentLookupKey方法，通过setDataSourceKey方法来动态调整dataSourceKey，进而达到动态调整数据源的功能。其类图如下：
动态数据源AOP
ShardMultipleDataSourceAspect动态数据源切面类，针对DAO方法进行功能增强，通过扫描DataSource动态数据源注解来获取相应的dataSourceKey，从而指定具体的数据源。具体流程图如下：