一 功能特点
1 支持最常见的分库分表方法
1 hash 2 datetime 3 mod 等
2 扩展性
支持本地化的分库分表jar包开发并且嵌入
3 读写分离特性
1 读本身支持负载均衡特性
2 当读不可用时(延时到一定程度) 会自动切换到主
3 支持指定读写节点注解
4 全局表
1 支持全局字典表,用于节点的join查询
5 全局ID
支持多种全局ID生成器,如果中间件不考虑这个功能也可以使用java的发号器
6 处理机制
1 所有线上事务操作都需要携带片键
2 如果很复杂需要一个SQL解析引擎,可以将不符合常规的情况SQL进行改写,用于扩展事务和查询语句的支持,这方面可以参考sharding-proxy的SQL解析引擎,算是一个比较核心的功能
7 稳定性
这是一个比较重要的东西,需要有稳健的代码功力
8 查询
1 后端需要ES进行分库分表的数据进行汇总,然后将大部分不支持的查询剥离出来,用ES进行支持
2 用全局表 上面已经说了,可以提供一部分场景的join查询
3 常见的排序和聚合函数场景
处理机制就是在每个节点都进行相应的排序或者聚合函数处理,然后进行汇总在中间件再进行总的排序和聚合函数处理,不过这样会加重中间件的负载,尽量少用
9 扩容
已知的中间件不支持热点扩容和水平扩容 除了阿里的polardb-x产品
10 高可用
建立一个中间件集群,这样即便有单个挂掉,整体业务也不会受影响,协议基础就是raft,配置要能实现实时同步
11 全局 备份和数据恢复
1 备份 不支持全局性的一致性备份,只能保证各自节点的备份有效性
2 数据恢复 同样,当需要恢复数据时 需要手动去每个节点生成回滚语句 然后各自应用 很麻烦
12 我的理解
1 在分库分表前预估N年的数据量,备好硬件,防止后期再进行迁移扩容
2 整体环境尽量就是 支持线上的DML事务和简单的SELECT事务,用ES和HDFS弥补查询能力的不足
3 公司内部尽量有一个开发团队可以熟读源码,后期进行维护