【11月必读】+后端开发+业务文章分享后端开发业务文章分享+个人终结与理解探讨： (1)超时取消订单的业务实现方案探讨。

【11月必读】+后端开发+业务文章分享

RabbitMQ延时队列+死信队列为主：

延时队列的超时消息将进入死信队列

时间轮算法兜底：

1.创造一个31槽位的数组，代表31分钟

2.让1个指针指向第0个位置（用于添加），一个指针指向第1个位置（用于删除）

3.每分钟两个指针都向右移1次（%31，取模右移），分别执行相应的添加删除（删除的时候顺便获取相应的元素进行处理）

主要是这两种场景：

1.用户重复点击提交按钮；

2.服务请求超时情况下，程序逻辑发起多次的请求；

例如：客户端可以用一个boolean isSubmit=true;发起请求时修改为false这样的简单程序逻辑判断！

以下讲的方案都是针对服务端的

插入操作向注册用户，生成订单这些都是要做幂等性处理的。

更新操作分为两种：一种是没有加减运算的，一种是有加减运算的。

没有加减运算像是用户修改个人信息这类接口是不需要做幂等性处理的

有加减运算像是转账是需要做幂等性处理。

以下例子采用什么方案合适？各位大佬可能有不同的见解，欢迎评论区探讨！

1.第一种方案：唯一索引，如手机号，邮箱等；

2.第二种方案：insert之前先select;

(根据Java阿里巴巴手册，数据库中具有唯一性字段的要加上唯一性索引，故个人推荐第一种方案，简单规范)

1.订单流程采用状态机方案：生成->支付->完成：状态机[1-下单、2-已支付、3-完成、4-撤销等状态。]


update `order` set status=3 where id=123 and status=2;

2.如果是生成订单操作，可以采用Token方案：客户端执行两次请求，第一次获取token,第二次携带此token完成生成订单这个操作。

token是随机生成的字符串，保证唯一，然后存在redis即可。使用时在redis查询，使用后在redis删去。（相当于一种凭证的做法）

【画重点：或者token是自己采用雪花算法生成的全局唯一性订单号也可以（这样还不需要Redis了）；甚至还可以由前端来做这件事，这样只需要一次请求】

这一步用其他方案像防重表都不是很合适，因为防重表总得有唯一字段吧，订单唯一字段订单号，然而订单号是我提交订单时在服务端通过雪花算法或者数据库主键自增的，这个insert操作是不幂等的。