| 组件 | 简介 |
|---|---|
| atlas | qihoo 360开发维护的一个基于mysql协议的数据中间层项目。它实现了mysql的客户端与服务端协议，作为服务端与应用程序通信，同时作为客户端与mysql通信。 |
| cobar | 阿里巴巴b2b开发的关系型分布式系统，管理将近3000个mysql实例。 在阿里经受住了考验，后面由于作者的走开的原因cobar没有人维护 了，阿里也开发了tddl替代cobar。 |
| mycat | 社区爱好者在阿里cobar基础上进行二次开发，解决了cobar当时存 在的一些问题，并且加入了许多新的功能在其中。目前mycat社区活 跃度很高，目前已经有一些公司在使用mycat。 |
| tddl | 淘宝根据自己的业务特点开发了tddl（taobao distributed data layer 框架，主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制，它是一个基于集中式配置的 jdbc datasource实现，具有主备，读写分离，动态数据库配置等功能。 |
| zebra | 点评集团统一使用的mysql数据库访问层的中间件。主要提供对业务开发透明、读写分库、分库分表能力，并提供了端到端sql监控的集成方案 |
mtddl（meituan distributed data layer），美团点评分布式数据访问层中间件，旨在为全公司提供一个通用数据访问层服务，支持mysql动态数据源、读写分离、分布式唯一主键生成器、分库分表、动态化配置等功能，并且支持从客户端角度对数据源的各方面（比如连接池、sql等）进行监控，后续考虑支持nosql、cache等多种数据源。
下图是一次完整的dao层insert方法调用时序图，简单阐述了mtddl的整个逻辑架构。其中包含了分布式唯一主键的获取、动态数据源的路由以及sql埋点监控等过程：
在spring jdbc abstractroutingdatasource的基础上扩展出multipledatasource动态数据源类，通过动态数据源注解及aop实现。
multipledatasource动态数据源类，继承于spring jdbc abstractroutingdatasource抽象类，实现了determinecurrentlookupkey方法，通过setdatasourcekey方法来动态调整datasourcekey，进而达到动态调整数据源的功能。其类图如下：
shardmultipledatasourceaspect动态数据源切面类，针对dao方法进行功能增强，通过扫描datasource动态数据源注解来获取相应的datasourcekey，从而指定具体的数据源。具体流程图如下：
我要评论/**配置参考*/
<bean id="multipledatasource" class="com.sankuai.meituan.waimai.datasource.multi.multipledatasource">
/** 数据源配置 */
<property name="targetdatasources">
<map key-type="java.lang.string">
/** 写数据源 */
<entry key="dbproductwrite" value-ref="dbproductwrite"/>
/** 读数据源 */
<entry key="dbproductread" value-ref="dbproductread"/>
</map>
</property>
</bean>
/**
* dao使用动态数据源注解
*/
public interface wmproductskudao {
/** 增删改走写数据源 */
@datasource("dbproductwrite")
public void insert(wmproductsku sku);
/** 查询走读数据源 */
@datasource("dbproductread")
public void getbyid(long sku_id);
}
众所周知，分库分表首先要解决的就是分布式唯一主键的问题，业界也有很多相关方案：
| 序号 | 实现方案 | 优点 | 缺点 |
|---|---|---|---|
| 1 | uuid | 本地生成，不需要rpc，低延时，扩展性好，基本没有性能上限 | 无法保证趋势递增，uuid过长128位，不易存储，往往用字符串表示 |
| 2 | snowflake或mongodb objectid | 分布式生成，无单点；趋势递增，生成效率快 | 没有全局时钟的情况下，只能保证趋势递增；当通过ntp进行时钟同步时可能会出现重复id；数据间隙较大 |
| 3 | proxy服务 + 数据库分段获取id | 分布式生成，段用完后需要去db获取，同server有序 | 可能产生数据空洞，即有些id没有分配就被跳过了，主要原因是在服务重启的时候发生；无法保证有序，需要未来解决，可能会通过其他接口方案实现 |
综上，方案3的缺点可以通过一些手段避免，但其他方案的缺点不好处理，所以选择第3种方案。目前该方案已由美团点评技术工程部实现——分布式id生成系统leaf，mtddl集成了此功能。
美团点评分布式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封装了所有的分库分表算法。其类图如下：
分库分表流程图如下：
public class modstrategyhandle implements shardstrategy {
@override
public string getshardtype() {
return "mod";
}
@override
public datatablename handle(string tablename, string datasourcekey, int tableshardnum,
int dbshardnum, object shardvalue) {
/** 计算散到表的值 */
long shard_value = long.valueof(shardvalue.tostring());
long tableposition = shard_value % tableshardnum;
long dbposition = tableposition / (tableshardnum / dbshardnum);
string finaltablename = new stringbuilder().append(tablename).append("_").append(tableposition).tostring();
string finaldatasourcekey = new stringbuilder().append(datasourcekey).append(dbposition).tostring();
return new datatablename(finaltablename, finaldatasourcekey);
}
}
mtddl不仅支持分库分表取模算法，还支持分库分表算法的扩展，通过新增分库分表策略类实现shardstrategy接口即可。shardstrategy接口包含两个方法：getshardtype用来指定分库分表策略，handle用来实现具体的数据源及分表计算逻辑。其类图如下：
为了尽可能地方便业务方接入，mtddl采用全注解方式使用分库分表功能，通过shardinfo、shardon、idgen三个注解实现。
shardinfo注解用来指定具体的分库分表配置：包括分表名前缀tablename、分表数量tableshardnum、分库数量dbshardnum、分库分表策略shardtype、唯一键生成策略idgentype、唯一键业务方标识idgenkey；shardon注解用来指定分库分表字段；idgen注解用来指定唯一键字段。具体类图如下：
// 动态数据源
@datasource("dbproductsku")
// tablename：分表名前缀，tableshardnum：分表数量，dbshardnum：分库数量，shardtype：分库分表策略，idgentype：唯一键生成策略，idgenkey：唯一键业务方标识
@shardinfo(tablename="wm_food", tableshardnum=100, dbshardnum=1, shardtype="mod", idgentype=idgentype.leaf, idgenkey=leafkey.sku)
@component
public interface wmproductskusharddao {
// @shardon("wm_poi_id") 将该注解修饰的对象的wm_poi_id字段作为shardvalue
// @idgen("id") 指定要设置唯一键的字段
public void insert(@shardon("wm_poi_id") @idgen("id") wmproductsku sku);
// @shardon 将该注解修饰的参数作为shardvalue
public list<wmproductsku> getskusbywmpoiid(@shardon long wm_poi_id);
}
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），效果图如下：
实现方案
采用spring aop技术对所有dao方法进行功能增强处理，通过美团点评分布式会话跟踪组件mtrace进行sql调用数据埋点及上报，进而实现从客户端角度对sql执行耗时、qps、调用量、超时率、失败率等指标进行监控。整体架构图如下：
实现效果
登录美团点评的服务治理平台octo选择服务查看去向分析，效果图如下：
为了满足业务方一些动态化需求，如解决线上db紧急事故需动态调整数据源或者分库分表相关配置，要求无需重启在线修改立即生效，mtddl从1.0.3版本开始正式引入动态化配置相关功能。
实现方案
在spring容器启动的时候自动注册数据源及分库分表相关配置到美团点评的统一配置中心mcc，在mcc配置管理页面可以进行动态调整，mcc客户端在感知到变更事件后会刷新本地配置，如果是数据源配置变更会根据新的配置构造出一个新数据源来替换老数据源，最后再将老的数据源优雅关闭掉。具体流程图如下：
动态化数据源
目前支持dbcp、dbcp2、c3p0等数据源，效果图如下：
支持动态化配置分库分表数量、分库分表策略、唯一键生成策略、唯一键业务方标识等，效果图如下：
mtddl到目前为止总共开发了四期，后续考虑逐步开源，具体版本迭代如下：
| 项目名 | 功能 | 开始时间 | 结束时间 | 正式版本 | 快照版本 | 版本备注 |
|---|---|---|---|---|---|---|
| mtddl一期 | 动态数据源 | 2016.05.30 | 2016.06.16 | 0.0.1 | 0.0.1-snapshot | mtddl第一版 |
| 读写分离 | ||||||
| 分布式唯一主键生成器 | ||||||
| 分库分表 | ||||||
| mtddl二期 | 分布式唯一主键生成算法可扩展 | 2016.08.23 | 2016.09.05 | 1.0.1 | 1.0.1-snapshot | mtddl接入优化 |
| 支持零配置接入mtddl | ||||||
| 优化shardkey配置方式 | ||||||
| mtddl三期 | 连接池及sql监控 | 2016.09.06 | 2016.09.20 | 1.0.2 | 1.0.2-snapshot | mtddl监控完善 |
| 缓存优化 | ||||||
| mtddl四期 | 唯一主键生成注解化 | 2016.10.11 | 2016.11.08 | 1.0.3 | 1.0.3-snapshot | mtddl配置动态化 |
| 动态化配置 |
如对本文有疑问， 点击进行留言回复！！
网友评论