就算你说的先拿交易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.*

知道是脏数据state=UNUSED，直接删掉不就成了。

【 在 hydxiaoc (就不告诉你) 的大作中提到: 】
: 就算你说的先拿交易id，那么总有一个api叫create_deal_id吧。
: 那么这个api在高并发下可能会挂，但是挂了你总不要往数据库插数据吧？
: 现在的case是：客户端调用create_deal_id，500了，无人值守的自动化客户端，不能弹窗，总得反复重试吧？
: ...................
--
FROM 125.78.148.*

业务上当然不知道是脏数据啊，只是看到短时间内刷了几百万个id，谁知道是不是真有几百万个客户想要这些id呢。
【 在 hgoldfish 的大作中提到: 】
: 知道是脏数据state=UNUSED，直接删掉不就成了。
:
--
FROM 39.185.114.*

改你们自己的客户端呗。而且交易id直接扔redis啥的，就那个简单的API我单机24核一天就可以跑10亿。

【 在 hydxiaoc (就不告诉你) 的大作中提到: 】
: create操作，在服务器看来，是合法的create。
: 也就是说，如果用户量真上来，这里流程完全是合法的。现在是1w的用户量，被我们自己的客户端“模拟”成1000w用户量了。
--
FROM 125.78.148.*

ddos攻击不能防止。你想了也没用，尽可能提升你们的服务器性能比较实在。

【 在 hydxiaoc (就不告诉你) 的大作中提到: 】
: 当然，换句话说，我们的服务器现阶段没有考虑过ddos的攻击。
: 用户这么搞完全可以ddos搞死我们。
--
FROM 125.78.148.*