这个事务一致性你自己程序保证吧。一般都是业务逻辑代码前开启事务，后结束事务。我看你这不是500错误，应该是nginx报的504或者或者502。

机器扛不住正常，网络发生错误也正常，后者你连500错误都接不到。你关注从技术上解决就错了。

交易ID不是交易结束后产生的，而是一开始就产生的。交易量太大上消息队列。重试脚本重试的时候没有确定只重试明确失败的动作？不去关注业务逻辑，ssh一样遇到这些坑。只是ssh性能强，不像php那样子动不动就扛不住。

【 在 hydxiaoc (就不告诉你) 的大作中提到: 】
: no，我们想要的是：500了就不要写数据库发消息，所谓的事务一致性。机器扛不住是很正常的。你不能告诉我500，实际活干完了
: ssh映像中没遇到这种坑
--
FROM 125.78.148.*