Spring Cloud - Seata
分布式事务：
第一阶段要做的事情：
1. 开启全局事务，获取全局事务id；
2. 执行业务逻辑，生成前置镜像、后置镜像，插入undo_log，执行本地事务；
3. 在插入undo_log之前，会发起一个rpc请求，调用TC，搜集行锁信息，生成全局锁。
第二阶段：分布式事务协调者根据事务的状态，到底是进行真正的提交还是回滚。
设计亮点：
1. 应用层基于SQL解析实现了自动补偿，从而最大程度的降低业务侵入性；
2. 将分布式事务中TC（事务协调者）独立部署负责事务的注册、回滚；
3. 通过全局锁实现了写隔离与读隔离；
存在的问题：
1. 性能损耗：前置镜像、后置镜像、undo_log,before commit(与TC通讯，判断锁冲突)....这些操作都需要一次远程通讯RPC，而且是同步的，另外undo log写入时blob字段的插入性能是不高的，每条写SQL都会增加这么多开销，粗略估计会增加5倍响应时间。为了进行自动补偿，需要对所有dml操作生成前后镜像并持久化，性价比不高。
第一阶段要做的事情：
1. 开启全局事务，获取全局事务id；
2. 执行业务逻辑，生成前置镜像、后置镜像，插入undo_log，执行本地事务；
3. 在插入undo_log之前，会发起一个rpc请求，调用TC，搜集行锁信息，生成全局锁。
第二阶段：分布式事务协调者根据事务的状态，到底是进行真正的提交还是回滚。
设计亮点：
1. 应用层基于SQL解析实现了自动补偿，从而最大程度的降低业务侵入性；
2. 将分布式事务中TC（事务协调者）独立部署负责事务的注册、回滚；
3. 通过全局锁实现了写隔离与读隔离；
存在的问题：
1. 性能损耗：前置镜像、后置镜像、undo_log,before commit(与TC通讯，判断锁冲突)....这些操作都需要一次远程通讯RPC，而且是同步的，另外undo log写入时blob字段的插入性能是不高的，每条写SQL都会增加这么多开销，粗略估计会增加5倍响应时间。为了进行自动补偿，需要对所有dml操作生成前后镜像并持久化，性价比不高。
