这篇我们来回答几个问题:
如何在线上不应影响业务的情况下,进行数据迁移?
什么是分布式事务?
有那些分布式解决方案?
MySQL 怎么实现分布式事务?那个容易落地?
怎么保障MySQL 高可用?
有那些开源分布式数据库中间件?
如何在线上不应影响业务的情况下,进行数据迁移?
数据迁移有两种方式,一种是有损迁移,一种是无损迁移。这里的"损" 指的是有损于业务:
停机迁移:发公告,停机迁移。一般停机迁移时间都是在业务低峰期,比如半夜...
平滑迁移: 所谓的不停服更新也是类似。
停机迁移
偷个大佬的图
平滑迁移
平滑迁移这里按数据在新库中的完整度分为两种类型(这两种方案都使用双写方案):
全量迁移
大致流程如下:
新库上线,配置主从复制,将旧库数据同步到新中,打开数据校验
让新主库运行一段时间,观察运行状态,平稳则,打开双写
新来的请求同时写入新旧库,以旧库操作事务返回结果为准,若旧库成功则算成功,失败则算失败,失败需要记录日志,检验排斥为何出错。
数据校验服务和新旧数据同步仍然进行中,直到新旧两库数据一致,迁移完成
进入放量灰度测试,直至所由请求都迁移到新库。
增量迁移
增量同步使用于旧库数据不在频繁做删改的情况,比如日志,用户订单,优惠券
打开双写,新写请求都写新库
查询聚合新老库
直至老库数据删改不再活跃(数据大部分过期)
什么是分布式事务?
一条事务在分解为多个子事务,在多个实例中进行就是分布式事务。
有那些分布式事务解决方案?
分布式大概由三种方案,2PC、3PC、TCC,这里主要分享2PC。
MySQL 怎么实现分布式事务?那个容易落地?
使用的是XA 两阶段事务。
XA 规范其实就是两阶段协议,2PC由两个角色:
协调者:负责事务协调,事务的发起,事务提交/事务回滚 都由协调者集中处理
资源管理者: 事务的执行者
大致流程:
协调者收到客户端请求
向资源管理者发起事务 -- 阻塞等待资源管理者返回消息
资源管理者收到事务请求,写入日志,挂起(不提交),返回协调者状态 -- 阻塞等待协调者下一步协调
协调者依据状态做提交/回滚
资源管理者返回就绪 -- 向资源管理者发送提交事务 -- 事务执行成功
资源管理者返回失败 -- 向资源管理者发送回滚事务 -- 事务执行失败
3PC 和 2PC 最大区别在于:
3PC 在 2PC 任务发起阶段前加入准备阶段,询问各资源管理者资源就绪状态,就绪则继续进行下一阶段,未就绪则继续尝试直到超时
3PC 加入了超时等待,2PC 没有超时机制,系统上任一环节出现故障都会导致整个系统阻塞,3PC 加入超时机制,有效缓解该状况。
怎么保障MySQL 高可用?
MySQL 是通过引入分布式支持来保障高可用,常见方案有:
MGR 组复制:一个组由若干个节点组成,一个事务提交需要经过 (N/2) + 1 过半数节点提交,才算事务提交成功。MGR 引入有效解决了半异步复制可能导致的数据不一致问题。
MMM 双主热备多从:双主热备任何时刻只能由一个主库可以写入,写入的故障主库下线后配置好的VIP会自动地址偏移切换备主继续工作。
MMM 缺点:主节点和备主不配置主从复制的话,主节点下线后备主和故障主节点会存在数据不一致的情况,所以备主需要和主节点之间要配置主从复制
MMM 社区已经缺少维护,开发资源可能不太新。
MySQL Culster : 使用NDB 的引擎整合多个MySQL 实例,支持自动水平扩容,自动读写负载均衡。
有那些开源分布式数据库中间件?
MyCat
TDDL
DBLE