ShardingSphere&Atlas&Mycat对比

sharding + proxy

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

无论是DB proxy还是Jdbc proxy都有很多开源实现，如下图简单做一个对比

实现方案	业界组件	原厂	功能特性	备注
DB proxy-based 多语言支持	Atlas	360	读写分离、静态分表
	Meituan Atlas	美团	读写分离、单库分表	目前已经在原厂逐步下架。
	Cobar	阿里（B2B）	Cobar 中间件以 Proxy 的形式位于前台应用和实际数据库之间，对前台的开放的接口是 MySQL 通信协议	开源版本中数据库只支持 MySQL，并且不支持读写分离。
	MyCAT	阿里	是一个实现了 MySQL 协议的服务器，前端用户可以把它看作是一个数据库代理，用 MySQL 客户端工具和命令行访问，而其后端可以用MySQL 原生协议与多个 MySQL 服务器通信	MyCAT 基于阿里开源的 Cobar 产品而研发
	Heisenberg	百度	热重启配置、可水平扩容、遵守 MySQL 原生协议、无语言限制。
	Kingshard	Kingshard	由 Go 开发高性能 MySQL Proxy 项目，在满足基本的读写分离的功能上，Kingshard 的性能是直连 MySQL 性能的80%以上。
JDBC - based 支持多 ORM 框架，一般有语言限制。	TDDL	阿里淘宝	动态数据源、读写分离、分库分表	TDDL 分为两个版本, 一个是带中间件的版本, 一个是直接 JAVA library 的版本。
	Zebra	美团点评	实现动态数据源、读写分离、分库分表、CAT监控	功能齐全且有监控，接入复杂、限制多。
	MTDDL	美团点评	动态数据源、读写分离、分布式唯一主键生成器、分库分表、连接池及SQL监控
DB - based 解决方案	Vitess	谷歌、Youtube	集群基于ZooKeeper管理，通过RPC方式进行数据处理，总体分为，server，command line，gui监控 3部分	Youtube 大量应用
	DRDS	阿里	DRDS（Distributed Relational Database Service）专注于解决单机关系型数据库扩展性问题，具备轻量(无状态)、灵活、稳定、高效等特性，是阿里巴巴集团自主研发的中间件产品。	逐渐下沉为DB服务

ShardingSphere用户群

分库分表成本

Sharding + Proxy 本质上只解决了一个问题，那就是单机数据容量问题，但它有哪些成本呢？前面提了每种 proxy 都有比较大的硬伤。

1、应用限制

1. Sharding 后对应用和 SQL 的侵入都很大，需要 SQL 足够简单，这种简单的应用导致 DB 弱化为存储。
2. SQL 不能跨维度 join、聚合、子查询等。
3. 每个分片只能实现 Local index，不能实现诸如唯一键、外键等全局约束。

2、Sharding 业务维度选择

1. 有些业务没有天然的业务维度，本身选择一个维度就是个问题。
2. 大部分业务需要多维度的支持，多维度的情况下。

• 哪个业务维度为主？
• 其它业务维度产生了数据冗余，如果没有全局事务的话，很难保证一致性，全局事务本身实现很难，并且响应时间大幅度下降，业务相互依赖存在重大隐患，于是经常发生“风控把支付给阻塞了”的问题。
• 多维度实现方式，数据库同步还是异步？同步依赖应用端实现双写，异步存在实效性问题，对业务有限制，会发生“先让订单飞一会的问题”。
• 多维度数据关系表（mapping）维护。

3、Sharding key 选择（非业务维度选择）

1. 非业务维度选择，会存在“我要的数据到底在那个集群上”的问题。
2. 业务维度列如何选择 Sharding key ？
3. 热点如何均摊，数据分布可能有长尾效应。

4、Sharding 算法选择

1. Hash 算法可以比较好的分散热点数据，但对范围查询需要访问多个分片。反之 Range 算法又存在热点问题。所以要求在设计之初就要清楚自己的业务常用读写类型。
2. 转换算法成本很高。

5、高可用问题

1. 高可用的扩散问题（一个集群不可用，整个业务“不可用”）。
2. 如何应对脑裂的情况？
3. MGR 多主模式数据冲突解决方案不成熟，基本上还没公司接入生产系统。
4. PXC 未解决写入容量，存在木桶原则，降低了写入容量。
5. 第三方依赖，MHA（判断主库真死、新路由信息广播都需要一定的时间成本） 最快也需要 15s。
6. 虽然有 GTID，仍然需要手工恢复。

6、数据一致性（其实这个严格上不属于分库分表的问题，但这个太重要了，不得不说）

1. MySQL 双一方案( redo、binlog 提交持久化) 严重影响了写入性能。
2. 即使双一方案，主库硬盘挂了，由于异步复制，数据还是会丢。
3. 强一致场景需求，比如金融行业，MySQL 目前只能做到双一＋半同步复制，既然是半同步，随时可能延迟为异步复制，还是会丢数据。
4. MGR ？上面说过，多写模式问题很多，距离接入生产系统还很远。
5. InnoDB Cluster ？先搞出来再说吧。

7、DB Proxy

1. 依赖网络层（LVS）实现负载均衡，跨 IDC 依赖 DNS，DNS + LVS + DBproxy + MySQL 网络链路过长，延迟增加、最重要的是存在全公司层面网络单点。
2. 部分产品对 Prepare 不友好，需要绑定 connection。

8、JDBC Proxy

1. 语言限制，需要单独对某语言写 Driver，应用不友好。
2. 并未实现 DB 层的透明使用。

9、全局 ID

1. 很简单的应用变成了很复杂的实现。
2. 采用 MySQL 自增 ID，写入扩大，单机容量有限。
3. 利用数据库集群并设置相应的步长，绝对埋坑的方案。
4. 依赖第三方组件，Redis Sequence、Twitter Snowflake ，复杂度增加，还引入了单点。
5. Guid、Random 算法，说好的连续性呢？还有一定比例冲突。
6. 业务属性字段 + 时间戳 + 随机数，冲突比例很高，依赖 NTP 等时间一致服务。

10、Double resource for AP

1. 同样的数据需要双倍的人力和产品。
2. 产品的重复，Hadoop、Hive、Hbase、Phoenix。
3. 人力的重复。
4. 数据迁移的复杂实现，Canal、databus、puma、dataX ？
5. 实时查询？普遍 T+1 查询。
6. TP 业务表变更导致 AP 业务统计失败，“老板问为啥报表显示昨天订单下降这么多，因为做个了 DDL。”

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

1. 运维的复杂性是随着机器数量指数级增长的，Google 在 F1 之前维护了一个 100 多个节点的 MySQL sharding 就痛得不行了，不惜重新写了一个 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 兄弟们懂的。