前言

数据迁移

全量

全量迁移的过程如下：

• 业务系统停机。

• 数据库迁移，校验数据一致性。

• 然后业务系统升级，接入新的数据库。

缺点：

• 需要业务系统停机

• 迁移时间较长，对业务影响较大。如果是异构数据的话，需要使用程序来处理，迁移时间更长。

全量+增量

• 先同步数据到最近的某个时间戳（ 创建时间 ）。

• 然后发布系统升级维护的通知。

• 然后同步最近一段时间变化的数据。

• 最后升级系统，接入新的数据库。

全量+增量的同步相比全量同步的方式，大大的减少了系统停机的时间，对业务影响较小。

binlog+全量+增量

分布式事务

XA分布式事务

XA分布式事务的组件：

• 应用程序（Application Program，简称AP）: 用于定义事务边界，即事务的开始和结束，并且在事务边界内对资源进行操作。

• 资源管理器（Resource Manager，简称RM）: 如数据库、文件系统，并且提供访问资源的方式。

• 事务管理器（Transaction Manager，简称TM）：负责分配事务标识，监控事务的执行进度，并且负责事务的提交、回滚等。

• xa_start 负责开启或者恢复一个事务分支

• xa_end 负责取消当前线程与事务分支的关联

• xa_prepare 询问RM是否准备好提交事务分支

• xa_commit 通知RM提交事务分支

• xa_rollback 通知RM回滚事务分支

• xa_recover 需要恢复的XA事务

完整的 XA 事务处理流程如下：

主流的XA框架有：Atomikos、Narayana、Seata

• 同步阻塞：全局事务包含了多个独立的事务分支，这一组事务分支要么都不成功，要不都失败，各个分支的ACID特性共同构成了全局事务的ACID特性。如果对读操作很敏感，需要将数据库的隔离级别设置为SERIALIZABLE，性能特别的差。

• 单点故障：TM存在单点故障，需要考虑TM高可用性。
• 数据不一致：极端情况下，会出现事务失败问题，需要监控和人工处理。即二阶段commit请求后，发送网络故障，只有一部分RM收到请求，其他节点没有收到Commit请求的情况。

柔性事务

• 基本可用（Basically available），分布式事务参与方不一定同时在线。

• 柔性状态（Soft state），允许系统状态更新有一定的延迟，出现一些中间状态，这个延迟对客户来说不一定能够察觉。

• 最终一致性（Eventually consistent），通常是通过消息传递的方式保证系统的最终一致性。

• TCC: 通过手动补偿处理

• AT: 通过自动补偿处理

TCC介绍

• Try： 准备操作，完成所有的业务检查，预留业务资源。

• Confirm： 真正执行的业务逻辑，不做任意的业务检查，只使用Try阶段预留的业务资源。因此Try操作成功，Confirm必须能成功。同时，Confirm操作必须保证冥等性，保证一笔分布式事务能切只能成功一次。

• Cancel： 释放Try阶段预留的业务资源，同样Cancel操作也必须满足冥等性。

AT

Seata框架对AT的支持如下：

• 第一阶段，业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
• 第二阶段，提交异步化，非常快速的完成，回滚的话通过一阶段的回滚日志进行反向补偿。

柔性事务下的事务特性

• 原子性： 正常情况下保证

• 一致性： 某个时间点，数据存在不一致，但是最终是一致的。

• 隔离性： 某个时间点，A能读到B事务未提交的结果，即会脏读现象。

• 持久性： 和本地事务一样，只要commit则数据就会被持久化。

链接：https://juejin.cn/post/6933003178661462023