标签：网络 后台 数据 闪退 ash 针对 dup 超过 多次点击
电商和p2p行业在做订单支付模块中必然会遇到重复下单问题？
这里主要针对重复下单做个简单的控制。先来说说重复下单的来源：
1、客户端同一时间多次点击下单操作。
这种情况一般大多数都会处理掉，那就是第一次点击下单按钮后将按钮禁用掉。不让点击第二次，但是谁能保证客户端永远都不会出现bug呢？万一没禁掉怎么办？
2、客户端点击一次下单请求到后端，后端响应时间超过约定时间导致响应超时，这时候客户端重试下单操作，或者出现网络错误导致客户端重复下单。
用户不知道我到底是下单了还是没下单，因为没收到服务器的响应结果。
3、客户端（app）下单时出现bug导致下单页面闪退，或者强制退出下单页面再次下单操作。
这中操作后台根本就不知道你到底是重复下单呢？还是要再次下第二笔单？
针对上面三种情况的解决方式：
从技术角度来说无非就是客户端和服务器端两者之间的数据一致性问题。先来看看客户端怎么解决？
设置客户端和服务端的约束：
客户端需要实现这样一个下单界面。用户点击【确认下单】时，应该产生一个独一无二的dedup key，连定订单数据发送给服务器端。在服务器返回之前，该界面应该一直等待，直到服务器响应成功/失败或者超时发生（比如15秒后，收不到服务器响应）。如果超时发生，应该向用户提示是否重试下单或者退出该界面。当用户点击【重试】时，应该用刚刚生成的dedup key来再次发送下单请求——如果用户一直不退出这个流程，每次用户点击重试，都应该用这个dedup key来重试下单，直到服务器正常返回，或者用户放弃返回。
数据库表设计：将UUID设置成唯一的约束，防止出现重复提交。
技术方案只是为了减少这种误操作性导致的重复订单，还是会出现重复性的，没有任何绝对的幂等性，都是采用一下综合的手段进行防止重复。
有时候还是会需要运维的人员进行客服沟通解决。技术+产品+运维。
高并发场景请使用mq解决流量销峰，走消息解决+分布式方式解决服务器压力。
标签：网络 后台 数据 闪退 ash 针对 dup 超过 多次点击
原文地址：https://www.cnblogs.com/sunxuesong/p/11381282.html
