延迟导致的“不幂等”问题
场景描述：
一个用户对一个商品进行下单，出于各种原因，在较短时间内，用户多次点击了下单按钮，如果手机端没有预防该情况的发生，那么将会产生多个相同的请求（请求接口相同+请求参数相同），如果服务处理不当将有可能产生多个订单，致使脏数据生成，可能导致应用服务的其它功能异常（风险不可评估）。
场景分析：
一个合理的下单步骤包括三步骤：商品选择->提交购买(生成唯一订单流水编号)->确认购买
步骤二：
生成 一个随机唯一订单流水编号关联 用户信息+商品信息 ，该流水编号作为交易意向标识，用户可以继续交易或者放弃交易，且可用于追溯用户该笔交易的流水
步骤三：
用户提交交易意向标识，完成商品交易。
步骤二是必不可少的，仅有“用户信息+商品信息”不能作为唯一标识来确定用户该次交易操作（商品不应有唯一性）。
解决方案：
对于同一请求高并发的情况（极短时间内，相同请求发起多次）
可以添加粒度为“用户唯一标识”或者“唯一订单流水编号”的锁保证同一时刻只能有一个进程访问；
对于网络延迟的情况（相同请求发起多次，两次连续请求的达到服务的时间间隔较长[`而导致锁失效`]）
1、将订单流水编号作为唯一键，当数据插入数据库时，成功则继续剩余的业务流程；失败则舍弃剩余的业务流程。
2、在写入操作执行前，先校验数据库中记录的状态，再决定是否继续执行剩余流程。
3、上传参数中包含token，token的使用是一次性，当token与当前会话状态中保持的token凭证必须一致才继续之后的流程，而流程结束后，会话保持的token要么被删除要么被更新。
开发时至少需要考虑这两种网络状况！（我是这么认为的）
高并发导致的“不幂等”问题
场景描述：
在商城交易系统中，有一个“秒拍商品”功能，不可预知的用户可能对有限的商品进行抢购，由于在商品出售过程中，商品作为临界资源被多个进程争用，如果不做防范，可能导致抢购到商品的用户数量多于商品的实际数量。
场景分析：
1、拒绝相同请求发起多次（由客户端进行限制）。
2、创建“待抢购”商品的队列。
3、获取临界资源标识（当pop[原子操作]取到值时，认为成功获取了临界资源，否则认为没有获取到临界资源，减少锁的使用可以避免因为网络问题带来加解锁的复杂性而造成业务处理的复杂性）决定继续之后的流程
解决方案：
一次商品抢购活动完整流程应当如此：
商品准备（队列准备）->活动进行（消费队列）->活动结束（监测队列）
