水平拆分的解决方案
由于水平拆分牵涉的逻辑比较复杂,当前也有了不少比较成熟的解决方案。这些方案分为两大类:客户端架构和代理架构。
客户端架构
通过修改数据访问层,如JDBC、Data Source、MyBatis,通过配置来管理多个数据源,直连数据库,并在模块内完成数据的分片整合,一般以Jar包的方式呈现。
这是一个客户端架构的例子:
可以看到分片的实现是和应用服务器在一起的,通过修改Spring JDBC层来实现
客户端架构的优点是:
-
应用直连数据库,降低外围系统依赖所带来的宕机风险
-
集成成本低,无需额外运维的组件
缺点是:
-
限于只能在数据库访问层上做文章,扩展性一般,对于比较复杂的系统可能会力不从心
-
将分片逻辑的压力放在应用服务器上,造成额外风险
代理架构
通过独立的中间件来统一管理所有数据源和数据分片整合,后端数据库集群对前端应用程序透明,需要独立部署和运维代理组件
这是一个代理架构的例子:
代理组件为了分流和防止单点,一般以集群形式存在,同时可能需要Zookeeper之类的服务组件来管理
代理架构的优点是:
-
能够处理非常复杂的需求,不受数据库访问层原来实现的限制,扩展性强
-
对于应用服务器透明且没有增加任何额外负载
缺点是:
-
需部署和运维独立的代理中间件,成本高
-
应用需经过代理来连接数据库,网络上多了一跳,性能有损失且有额外风险
各方案比较
出品方 | 架构模型 | 支持数据库 | 分库 | 分表 | 读写分离 | 外部依赖 | 是否开源 | 实现语言 | 支持语言 | 最后更新 | Github星数 | |
---|---|---|---|---|---|---|---|---|---|---|---|---|
MySQL Fabric | MySQL官方 | 代理架构 | MySQL | 有 | 有 | 有 | 无 | 是 | python | 无限制 | 4个月前 | 35 |
Cobar | 阿里巴巴 | 代理架构 | MySQL | 有 | 无 | 无 | 无 | 是 | Java | 无限制 | 两年前 | 1287 |
Cobar Client | 阿里巴巴 | 客户端架构 | MySQL | 有 | 无 | 无 | 无 | 是 | Java | Java | 三年前 | 344 |
TDDL | 淘宝 | 客户端架构 | 无限制 | 有 | 有 | 有 | Diamond | 只开源部分 | Java | Java | 未知 | 519 |
Atlas | 奇虎360 | 代理架构 | MySQL | 有 | 有 | 有 | 无 | 是 | C | 无限制 | 10个月前 | 1941 |
Heisenberg | 百度熊照 | 代理架构 | MySQL | 有 | 有 | 有 | 无 | 是 | Java | 无限制 | 2个月前 | 197 |
TribeDB | 个人 | 代理架构 | MySQL | 有 | 有 | 有 | 无 | 是 | NodeJS | 无限制 | 3个月前 | 126 |
ShardingJDBC | 当当 | 客户端架构 | MySQL | 有 | 有 | 有 | 无 | 是 | Java | Java | 当天 | 1144 |
Shark | 个人 | 客户端架构 | MySQL | 有 | 有 | 无 | 无 | 是 | Java | Java | 两天前 | 84 |
KingShard | 个人 | 代理架构 | MySQL | 有 | 有 | 有 | 无 | 是 | Golang | 无限制 | 两天前 | 1836 |
OneProxy | 平民软件 | 代理架构 | MySQL | 有 | 有 | 有 | 无 | 否 | 未知 | 无限制 | 未知 | 未知 |
MyCat | 社区 | 代理架构 | MySQL | 有 | 有 | 有 | 无 | 是 | Java | 无限制 | 两天前 | 1270 |
Vitess | Youtube | 代理架构 | MySQL | 有 | 有 | 有 | 无 | 是 | Golang | 无限制 | 当天 | 3636 |
Mixer | 个人 | 代理架构 | MySQL | 有 | 有 | 无 | 无 | 是 | Golang | 无限制 | 9个月前 | 472 |
JetPants | Tumblr | 客户端架构 | MySQL | 有 | 有 | 无 | 无 | 是 | Ruby | Ruby | 10个月前 | 957 |
HibernateShard | Hibernate | 客户端架构 | 无限制 | 有 | 有 | 无 | 无 | 是 | Java | Java | 4年前 | 57 |
MybatisShard | MakerSoft | 客户端架构 | 无限制 | 有 | 有 | 无 | 无 | 是 | Java | Java | 11个月前 | 119 |
Gizzard | 代理架构 | 无限制 | 有 | 有 | 无 | 无 | 是 | Java | 无限制 | 3年前 | 2087 |
如此多的方案,如何进行选择?可以按以下思路来考虑:
-
确定是使用代理架构还是客户端架构。中小型规模或是比较简单的场景倾向于选择客户端架构,复杂场景或大规模系统倾向选择代理架构
-
具体功能是否满足,比如需要跨节点
ORDER BY
,那么支持该功能的优先考虑 -
不考虑一年内没有更新的产品,说明开发停滞,甚至无人维护和技术支持
-
最好按大公司->社区->小公司->个人这样的出品方顺序来选择
-
选择口碑较好的,比如github星数、使用者数量质量和使用者反馈
-
开源的优先,往往项目有特殊需求可能需要改动源代码
按照上述思路,推荐以下选择:
-
客户端架构:ShardingJDBC
-
代理架构:MyCat或者Atlas