seata是一个分布式事物解决方案。虽然它使用起来比较简单，对代码来说无侵入，也支持高可用。但是也是有着非常大的开销。它常用的方案就是把整个事物管理依赖一个数据库。
看官网给出的一致事物提交的执行流程
我们不得不注意到，这个过程中，有多次的数据库操作：一起看一片文章中的开销计算。
一条Update的SQL，则需要全局事务xid获取（与TC通讯）、before image（解析SQL，查询一次数据库）、after image（查询一次数据库）、insert undo log（写一次数据库）、before commit（与TC通讯，判断锁冲突），这些操作都需要一次远程通讯RPC，而且是同步的。另外undo log写入时blob字段的插入性能也是不高的。每条写SQL都会增加这么多开销,粗略估计会增加5倍响应时间（二阶段虽然是异步的，但其实也会占用系统资源，网络、线程、数据库）。
为了进行自动补偿，需要对所有交易生成前后镜像并持久化，可是在实际业务场景下，这个是成功率有多高，或者说分布式事务失败需要回滚的有多少比率？这个比例在不同场景下是不一样的，考虑到执行事务编排前，很多都会校验业务的正确性，所以发生回滚的概率其实相对较低。按照二八原则预估，即为了20%的交易回滚，需要将80%的成功交易的响应时间增加5倍，这样的代价相比于让应用开发一个补偿交易是否是值得？值得我们深思。 作者：蚊子squirrel 链接：https://www.jianshu.com/p/917cb4bdaa03 来源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
其它问题：
如果程序执行过程中发生了中断，事物没有完成回滚，我们应该怎么做？
