就算你说的先拿交易id，那么总有一个api叫create_deal_id吧。
那么这个api在高并发下可能会挂，但是挂了你总不要往数据库插数据吧？


现在的case是：客户端调用create_deal_id，500了，无人值守的自动化客户端，不能弹窗，总得反复重试吧？
重试了999下，第1000下好了。看起来ok

但是最终数据库有1000个id，前999个都是脏数据。

这就是问题的根源。

【 在 hgoldfish 的大作中提到: 】
: 这个事务一致性你自己程序保证吧。一般都是业务逻辑代码前开启事务，后结束事务。我看你这不是500错误，应该是nginx报的504或者或者502。
: 机器扛不住正常，网络发生错误也正常，后者你连500错误都接不到。你关注从技术上解决就错了。
: 交易ID不是交易结束后产生的，而是一开始就产生的。交易量太大上消息队列。重试脚本重试的时候没有确定只重试明确失败的动作？不去关注业务逻辑，ssh一样遇到这些坑。只是ssh性能强，不像php那样子动不动就扛不住。
: ...................
--
FROM 39.185.114.*