一 简介:分库分表的理解
二 具体: 1 当由于单台DB业务增长导致的服务器压力时,就必须横向进行扩展 2 本文仅从中间层观点进行分析
三 现有方案
方案1 sharding家族
Sharding-JDBC是一款轻量级的Java框架，在JDBC层提供上述核心功能，使用方式与正常的JDBC方式如出一辙，面向Java开发的用户。
Sharding-Proxy是一款实现了MySQL二进制协议的服务器端版本，大家可以把它当成升级版的MySQL数据库使用。独立部署后，即可按照正常MySQL操作方式来使用上述所有的核心功能。
设计 在程序端利用设计控制,根据计算出的路由指定数据库节点.
特点 sharding优势
1 程序端进行控制,非常方便.利用代码计算分片字段,控制分片规则.不会产生性能损耗
2 程序能够封装面对不同种类数据库
sharding问题
1 不支持分布式事务,需要利用路由进行事务操作
2 不支持分布式事务,全局DDL需要到每个分片进行执行
3 不支持动态扩容
4 不具有通用性,因为是根据业务进行设计的
过程 通过对片键的换算绝对分片节点,再通过片键的换算定位分表,达到分片分表目的
方案 2 中间件家族
设计 采用开源界的开源中间件进行设计控制,路由规则和分片都配置在中间件,然后指定后端机器
特点 1 开源中间件分为两种
一种是支持分布式事务,比如cetus mycat
一种是不支持分布式事务,比如kingshard
2 开源中间件的优势
1 中间件具有通用性,定义好的分片方法和路由规则,可以应用到多种业务场景
2 中间件大多拥有读写分离特性,可以直接应用
3 开源中间件可能存在的问题
1 中间件本身hang住,导致业务不可用
2 中间件本身发生崩溃或者OOM占用很高,导致业务不可用
3 中间件本身的性能损耗问题,是否可以接受
4 中间件如果上线,程序还是得做一定程度的浅改造
5 中间件本身也不支持动态扩容
6 中间件是否还在开源界维护
7 中间件维护和备份数据等问题
四 存在的普遍问题
1 程序是否采用分布式事务问题
2 全局性DDL操作问题
3 分片集群的查询问题
4 分片集群的扩容问题
5 分片集群的备份数据一致性问题
五 分片集群的普通扩容方案思路
准备条件
1 完全一倍的硬件替换环境
2 需要在分片时准备足够多的桶
3 需要预选准备好新的分片程序
方案
1 按照原集群备份建立相应的最新备份库,并提供账号和备份截止时间给新程序
2 调整原集群binlog保留全部
3 新程序进行消费最新备份数据,根据主键对照原则,新集群插入一条,备份库删除一条,最后原备份库数据全部清空,保证数据的正确过度(类似于pt-archiver)
4 建立canal服务,当新集群消费完毕后,配置指定时间戳进行消费binlog
5 当消费完全后,在业务低峰时期,进行业务切换即可
六 分片集群主键的规划
目的 保证集群本身各个节点的主键不唯一
分类
1 uuid 最原始(不建议用这个),保证唯一
2 业务组合数字串(time+产品ID+用户ID)类似标记唯一,而且还能进行利用
3 通过雪花算法生成(需要时钟校验,否则可能产生冲突)
我们强烈推荐第二种方案,具有业务意义的主键才是我们需要的,我们本身也采用第二种
七 分片集群的查询
1 禁止跨分片的查询,任何分片集群查询都要带上分片条件
2 非实时查询业务
目的 汇总备份并提供查询
1 hbase
2 es+canal
八 总结
1 按照业务角度进行管理划分,不建议采用通用方案
2 预估未来N年的数据量,确定表的字段和索引. 这两项非常重要,如果一旦触发其中一个,操作起来是非常麻烦的