loveoobaby opened a new issue #563: pack问题汇总反馈 URL: https://github.com/apache/servicecomb-pack/issues/563 大家好！本人最近做分布式事务服务框架，刚开始想直接将pack拿过来使用，但我们发现pack的问题太多了。逼不得已将pack的核心代码基本全部重写，但保持业务逻辑与pack一致。受制于公司政策，代码不方便公开。现将我们遇到的问题进行反馈： 1. 服务发现机制不健全，如果新加入alpha，客户端无法感知； 2. SQL代码复杂。这是由于数据库设计表不合理造成的。saga只有一个表，tcc有三个表，其实两张表最合理，一张表存事务的整体状态，一张表存事务的事件。这样可以使SQL写的很简单。 3. 回滚逻辑复杂，回滚速度慢，如果出现要回滚1000条，立即卡死。建议可以引入状态机来描述分布式事务的状态，回滚逻辑就不需要那么复杂了，代码只需一百多行。下面是我们设计的SAGA状态机，TCC状态机会更复杂一些：  4. gRPC性能较低：gRPC同步模型性能很差，但受制于spring线程模型，只能采用同步模型。 `rpc OnTxEvent (GrpcTxEvent) returns (GrpcAck) {}` 我们是直接用netty手撸了定制的RPC框架，即使是在客户端阻塞的情况下，qps也比gRPC双工异步快。 5. mysql性能较慢：其实这种中间件对性能要求是很高的，一个RPC请求最好在5ms内返回，内网环境下网络需消耗2ms，请求处理要在3ms内返回。使用mysql在高负载下经常超时，目前我们的处理方式是异步批量入库，但这种情况下客户端需将事件发到固定的alpha，以防止事件顺序不对，同时要处理关闭server时清空入库队列； 6. jpa有些不好用：我们在做批量入库时，使用了saveAll方法，但会丢数据，查询时缓存也有影响，查这个事务的数据能出来一条别的事务的数据。我们团队没人会jpa，果断换成mybatis； 7. RPC次数较多：每个分支有两次请求，加上开启与提交，如果有n个分支，SAGA RPC次数是2n+2，TCC是3n+2。我们觉得实在太多了，可以砍掉一部分。我们假定大部分情况下分布式事务是成功的，如果成功率太低，这个接口没有意义。所以，对于分支事务开始会发RPC请求，但结束时不会，除非发生异常会进行RPC请求。这样一个事务正常情况下，SAGA变为n+2，TCC变为2n+2； 经过开发分布式事务，我觉得这玩意就是鸡肋，能不用就不要用！我还是更推荐AP+最终一致性。使用这种框架增加了整个提供的复杂度、耦合性，如果alpha宕机会导致整个系统不可用，而且接口都要求幂等，对普通开发人员来说很容易生产bug。 最后，感谢各位开发者贡献这么好的框架，使本人学会了怎么处理这类问题。非常感谢！
---------------------------------------------------------------- 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
