cobar

ShardingSphereAtlasMycat对⽐

sharding+proxy

sharding+proxy分库分表的路由通常在应⽤层(APP)与DB层之间实现，中间层根据偏向DB还是偏向应⽤层可分为：DBproxy和

JDBCproxy。

⽆论是DBproxy还是Jdbcproxy都有很多开源实现，如下图简单做⼀个对⽐

实现⽅案业界组件原⼚功能特性备注

DBproxy-bad

多语⾔⽀持

Atlas360读写分离、静态分表

Meituan

Atlas

美团读写分离、单库分表

⽬前已经在原⼚逐步下

架。

Cobar

阿⾥

（B2B）

Cobar中间件以Proxy的形式位于前台应⽤和实际数据库

之间，对前台的开放的接⼝是MySQL通信协议

开源版本中数据库只⽀持

MySQL，并且不⽀持读

写分离。

MyCAT阿⾥

是⼀个实现了My什么是换手率 SQL协议的服务器，前端⽤户可以把它

看作是⼀个数据库代理，⽤MySQL客户端⼯具和命令⾏

访问，⽽其后端可以⽤MySQL原⽣协议与多个MySQL

服务器通信

MyCAT基于党员推优 阿⾥开源的

Cobar产品⽽研发

Heinberg百度

热重启配置、可⽔平扩容、遵守MySQL原⽣协议、⽆语

⾔限制。

KingshardKingshard

由Go开发⾼性能MySQLProxy项⽬，在满⾜基本的读

写分离的功能上，Kingshard的性能是直连MySQL性能

的80%以上。

JDBC-bad⽀

持多ORM框架，

⼀般有语⾔限制。

TDDL阿⾥淘宝动态数据源、读写分离、分库分表

TDDL分为两千层糕 个版本,⼀

个是带中间件的版本,⼀

个是直接JAVAlibrary

的版本。

Zebra美团点评实现动态数据源、读写分离、分库分表、CAT监控

功能齐全且有监控，接⼊

复杂、限制多。

MTDDL美团点评

动态数据源、读写分离、分布式唯⼀主键⽣成器、分库分

表、连接池质量管理计划 及SQL监控

DB-bad解决

⽅案

Vitess

⾕歌、

Youtube

集群基于ZooKeeper管理，通过RPC⽅式进⾏数据处理，

总体分为，rver，commandline，gui监控3部分

Youtube⼤量应⽤

DRDS阿⾥

DRDS（DistributedRelationalDatabaService）专

注于解决单机关系型数据库扩展性问题，具备轻量(⽆状

态)、灵活、稳定、⾼效等特性，是阿⾥巴巴集团⾃主研发

的中间件产品。

逐渐下沉为DB服务

ShardingSphere⽤户群

分库分表成本

Sharding+Proxy本质上只全国十大名校排名 解决了⼀个问题，那就是单机数据容量问题，但它有哪些成本呢？前⾯提了每种proxy都有⽐较⼤的硬伤。

1、应⽤限制

ng后对应⽤和SQL的侵⼊都很⼤，需要SQL⾜够简单，这种简单的应⽤导致DB弱化为存储。

不能跨维度join、聚合、⼦查询等。

3.每个分⽚只能实现Localindex，不能实现诸如唯⼀键、外键等全局约束。

2、Sharding业务维度选择

1.有些业务没有天然的业务维度，本⾝选择⼀个维度就是个问题。

2.⼤部分业务需要多维度的⽀持，多维度的情况下。

哪个业务维度为主？

其它业务维度产⽣了数据冗余，如果没有全局事务的话，很难保证⼀致性，全局事务本⾝实现很难，并且响应时间⼤幅度下降，业务相

互依赖存在重⼤隐患，于是经常发⽣“风控把⽀付给阻塞了”的问题。

多维度实现⽅式，数据库同步还是异步？同步依赖应⽤端实现双写，异步存在实效性问题，对业务有限制，会发⽣“先让订单飞⼀会的

问题”。

多维度数据关系表（mapping）维护。

3、Shardingkey选择（⾮业务维度选择）

1.⾮业务维度选择，会存在“我要的数据到底在那个集群上”的问题。

2.业务维度列如何选择Shardingkey？

3.热点如何均摊，数据分布可能有长尾效应。

4、Sharding算法选择

算法可以⽐较好的分散热点数据，但对范围查询需要访问多个分⽚。反之Range算法⼜存在热点问题。所以要求在设计之初就

要清楚⾃⼰的业务常⽤读写类型。

2.转换算法成本很⾼。

5、⾼可⽤问题

1.⾼可⽤的扩散问题（⼀个集群不可⽤，整个业务“不可⽤”）。

2.如何应对脑裂的情况？

多主模式数据冲突解决⽅案不成熟，基本上还没公司接⼊⽣产系统。

未解决写⼊容量，存在⽊桶原则，降低了写⼊容量。

5.第三⽅依赖，MHA（判断主库真死、新路由信息⼴播都需要⼀定的时间成本）最快也需要15s。

6.虽然有GTID，仍然需要⼿⼯恢复。

6、数据⼀致性（其实这个严格上不属于分库分表的问题，但这个太重要了，不得不说）支教感悟与收获

双⼀⽅超前思维 案(redo、binlog提交持久化)严重影响了写⼊性能。

2.即使双⼀⽅案，主库硬盘挂了，由于异步复制，数据还是会丢。

3.强⼀致场景需求，⽐如⾦融⾏业，MySQL⽬前只能做到双⼀＋半同步复制，既然是半同步，随时可能延迟为异步复制，还是会丢数

据。

？上⾯说过，多写模式问题很多，距离接⼊⽣产系统还很远。

Cluster？先搞出来再说吧。

7、DBProxy

1.依赖⽹络层（LVS）实现负载均衡，跨IDC依赖DNS，DNS+LVS+DBproxy+MySQL⽹络链路过长，延迟增加、最重要的是

存在全公司层⾯⽹络单点。

2.部分产品对Prepare不友好，需要绑定connection。

8、JDBCProxy

1.语⾔限制，需要单独对某语⾔写Driver，应⽤不友好。

2.并未实现DB层的透明使⽤。

9、全局ID

1.很简单的应⽤变成了很复杂的实现。

2.采⽤MySQL⾃增ID，写⼊扩⼤，单机容量有限。

3.利⽤数据库集群并设置相应的步长，绝对埋坑的⽅案。

4.依赖第三⽅组件，RedisSequence、TwitterSnowflake，复杂度增加，还引⼊了单点。

、Random算法，说好的连续性呢？还有⼀定⽐例冲突。

6.业务属性字段+时间戳+随机数，冲突⽐例很⾼，依赖NTP等时间⼀致服务。

10、DoubleresourceforAP

1.同样的数据需要双倍的⼈⼒和产品。

2.产品的重复，Hadoop、Hive、Hba、Phoenix。

3.⼈⼒的重复。

4.数据迁移的复杂实现，Canal、databus、puma、dataX？

5.实时查询？普遍T+1查询。

业务表变更导致AP业务统计失败，“⽼板问为啥报表显⽰昨天订单下降这么多，因为做个了DDL。”

11、运维友好度(DDL、扩容等)

1.运维的复杂性是随着机器数量指数级增长的，Google在F1之前维护了⼀个100多个节点的MySQLsharding就痛得不⾏了，不

惜重新写了⼀个Spanner和F1搞定这个问题。

2.传统RDBMS上DDL锁表的问题，对于数据量较⼤的业务来说，锁定的时间会很长，如果使⽤pt-osc、gh-ost这样第三⽅⼯具来

实现⾮阻塞DDL，额外的空间开销会⽐较⼤，另外仍然需要⼈⼯的介⼊确保数据的⼀致性，最后切换的过程系统可能会有抖动，pt-

osc还需要两次获取metalock，虽然这个操作本事很轻量，可糟糕的是如果它被诸如DDL的锁阻塞，它会阻塞所有的DML，于是

悲剧了。

12、与原有业务的兼容性

1.时间成本，如果业务⼀开始设计时没有考虑分库分表或者中间件这类的⽅案，在应对数据量暴增的情况下匆忙重构是很⿇烦的事情。

2.技术成本，如果没有强有⼒和有经验的架构师，很难在业务早期做出良好的设计，另外对于⼤多数⾮互联⽹⾏业的开发者来说更是不

熟悉。

13、Sharding容量管理

1.拆分不⾜，需要再次拆分的问题，⼯作量巨⼤。

2.拆分充⾜，⼤部分业务增长往往⽐预期低很多，经常发⽣“⼜被PM妹纸骗了，说好的百万级流量古风网名男生 呢”的问题，即时业务增长得⽐较

好，往往需要⼀个很长的周期，机器资源浪费严重。

14、运维成本，⼈⼒成本

不解释，SRE、DBA兄弟们懂的。