这篇我们来回答几个问题:

如何在线上不应影响业务的情况下,进行数据迁移?

什么是分布式事务?

有那些分布式解决方案?

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