订单失效的几种方法和优势劣势

1.轮训

单机轮训 和集群轮训 ->集群轮训（调度任务中心 xx-job）

优势，单机轮训简单方便

劣势，调度任务中心不是每一个中心都有的，二时效性问题 n分钟扫描一次 不能及时更新数据，n 秒扫描一次数据库表压力过大。

2.redis6 

客户端（客户本地）缓存监听方案

 

 

redis6 新特性 扩展*

第一种模式是普通模式。在这个模式下，实例会在服务端记录客户端读取过的 key，并监测 key 是否有修改。一旦 key 的值发生变化，服务端会给客户端发送 invalidate（失效）消息，通知客户端缓存失效了。在使用普通模式时，有一点你需要注意一下，服务端对于记录的 key 只会报告一次 invalidate 消息，也就是说，服务端在给客户端发送过一次 invalidate 消息后，如果 key再被修改，此时，服务端就不会再次给客户端发送invalidate 消息。只有当客户端再次执行读命令时，服务端才会再次监测被读取的 key，并在 key 修改时发送 invalidate 消息。这样设计的考虑是节省有限的内存空间。毕竟，如果客户端不再访问这个 key 了，而服务端仍然记录 key 的修改情况，就会浪费内存资源。
第二种模式是广播模式。在这个模式下，服务端会给客户端广播所有 key 的失效情况，不过，这样做了之后，如果 key 被频繁修改，服务端会发送大量的失效广播消息，这就会消耗大量的网络带宽资源。所以，在实际应用时，我们会让客户端注册希望跟踪的 key 的前缀，当带有注册前缀的 key 被修改时，服务端会把失效消息广播给所有注册的客户端。和普通模式不同，在广播模式下，即使客户端还没有读取过 key，但只要它注册了要跟踪的 key，服务端都会把 key 失效消息通知给这个客户端。。我们在实际应用时，会给同一业务下的 key 设置相同的业务名前缀，所以，我们就可以非常方便地使用广播模式。
普通模式和广播模式，需要客户端使用 RESP 3 协议，对于使用 RESP 2 协议的客户端来说，就需要使用另一种模式，也就是重定向模式（redirect）。在重定向模式下，想要获得失效消息通知的客户端，就需要执行订阅命令SUBSCRIBE(subscribe 订阅)，专门订阅用于发送失效 key 消息的频道 redis:invalidate。同时，再使用另外一个客户端，执行 CLIENT TRACKING (client tracking 客户跟踪)命令，设置服务端将失效消息转发给使用 RESP 2 协议的客户端。

优势：订单即时发送 redis6 主动 推送到redis 进行订单取消

劣势：需要升级redis ,实例数量发生变化需要重新分配，需要长连接如果长连接失效需要手动补偿

3.RocketMq+延迟列队，死信列队

 优势：消息即时投递，代码量小

 劣势：必须会MQ,需要关注幂等问题

链接：https://www.cnblogs.com/mfrank/p/11184929.html