coolbeevip commented on issue #563: pack问题汇总反馈 URL: https://github.com/apache/servicecomb-pack/issues/563#issuecomment-534466559 > > > 1. RPC次数较多：每个分支有两次请求，加上开启与提交，如果有n个分支，SAGA RPC次数是2n+2，TCC是3n+2。我们觉得实在太多了，可以砍掉一部分。我们假定大部分情况下分布式事务是成功的，如果成功率太低，这个接口没有意义。所以，对于分支事务开始会发RPC请求，但结束时不会，除非发生异常会进行RPC请求。这样一个事务正常情况下，SAGA变为n+2，TCC变为2n+2； > > > > > > 无论如何，这个想法很独特（如果是让我选择只能发送一个消息，那我可能会选择只发送子事务的结束消息），但是子事务只发送一个消息会存在一些缺陷 > > > > 1. 无法确定子事务是否已经执行完毕，如果靠判断当收到一个子事务开始事件就意味之前的子事务结束，那么我无法扩展子事务并行的场景 > > 2. 当无法判断一个子事务是否结束就进行补偿，这可能会导致不可预知的问题发生 > > > > 关于 RPC 效率问题，0.5.0版本使用状态机，Alpha 收到 RPC 消息后不会操作数据库，所以吞吐率会提高很多。 > > 第一个问题：其实我们假设子事务是串行执行的。 > 第二个问题：依靠补偿接口有处理无效补偿事件的能力。执行分支事务与RPC发送结束事件本来就无法保证原子性。我们遇到了这样的场景：分支事务执行完成，数据库已经提交，这时宕机，导致alpha没有收到结束事件，原先的逻辑是不会回滚当前分支的，重启业务服务也不会回滚。我们改成回滚当前分支，但如果分支没有完成，已经自动回滚了，这时要求补偿接口不要产生副作用。 > > 用这种框架写业务要求太多，怎么做都有坑。怎么样想办法降低门槛才行，Seata可自动补偿，提供了部分隔离性，可参考一下。 是的，第一原则就是避免分布式事务，可是我的场景面临较多的第三方服务的整合以及一些非关系数据库的业务系统，所以 Seata 的 SQL 模式不太适合我。
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
