一 简介:分库分表的理解
二 具体: 1 当由于单台DB业务增长导致的服务器压力时,就必须横向进行扩展
2 本文仅从中间层观点进行分析
三 现有方案
方案1 sharding家族
-
Sharding-JDBC是一款轻量级的Java框架，在JDBC层提供上述核心功能，使用方式与正常的JDBC方式如出一辙，面向Java开发的用户。
-
Sharding-Proxy是一款实现了MySQL二进制协议的服务器端版本，大家可以把它当成升级版的MySQL数据库使用。独立部署后，即可按照正常MySQL操作方式来使用上述所有的核心功能。
-
Sharding-Sidecar从Service Mesh的理念中应用而生，面向于云原生架构
设计 在程序端利用sharding家族进行设计控制,根据计算出的路由指定数据库节点.
特点 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 全局事务控制的问题,即便是支持全局事务控制的中间件,也极度依赖mysql自身的XA事务.但是mysql xa 到了5.7后续版本才逐渐完善
2 全局事务DDL的一致性和代价问题,这也是一个针对多分片非常头疼的问题,不论对于哪种场景下
3 一旦采用分片,后续的查询限制问题,需要改造业务
4 分片集群的扩容问题,这是一个非常麻烦的事情,可以摆放在分片方案的首位
5 分片集群的备份数据一致性问题
五 分片集群的普通扩容方案思路
准备条件
1 完全一倍的硬件替换环境
2 需要在分片时准备足够多的桶
方案1
1 利用备份工具备份各个分片的数据,并记录下此时的主库binlog相关信息
2 利用备份恢复到新建立的集群中,一式两份.
3 利用修改好的新算法程序并行进行每个节点多余数据的删除
4 利用主库binlog相关信息搭配canal进行每个节点的同步
5 停止业务,保证新旧集群的数据一致
6 流量进行切换
7 旧集群进行下线处理
方案2
1 准备好相应的新程序,硬件环境,一个超级账户
2 新程序接入线上从库,通过超级账户执行两件事
1 停止复制进程
2 记录此时的同步binlog信息
3 新程序开始进行操作
1 读取从库数据,以新的算法进行录入新集群
2 对录入的数据进行校验,校验成功后对从库进行删除操作
4 当执行完时,从库就没有数据了,数据都在新集群了
5 利用从库同步的binlog信息进行canal消费
6 当canal消费追上主库后停止业务
7 流量进行切换
8 就集群进行下线处理
9 注意:确保mysql主库必须保留足够时间的binlog文件
六 分片集群主键的规划
目的 保证集群本身各个节点的主键不唯一
分类
1 uuid 最原始(不建议用这个),保证唯一
2 业务组合数字串(time+产品ID+用户ID)类似标记唯一,而且还能进行利用
3 通过雪花算法生成(需要时钟校验,否则可能产生冲突)
我们强烈推荐第二种方案,具有业务意义的主键才是我们需要的,我们本身也采用第二种
七 分片集群的查询
1 实时跨分片的业务尽量改造或者避免,效率很低
2 非实时查询业务我强烈建议采用canal+es方式,es汇总集群所有数据进行后台查询
八 总结
几个关键点
1 在哪个阶段进行分片,是否具有通用性
2 是否需要支持分布式事务
3 集群的分片扩容和查询问题
4 集群的全局事务ID规划
九 补充点
找到适合业务具体的方案,稳定适合才是重要的,具体问题具体分析.本篇文章只是个人观点.
扫一扫
1310
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
