consumer获取，唤起超时处理逻辑

文章插图

如果采用的是RabbitMQ，其本身没有直接支持延迟队列功能，可以针对Queue和Message设置 x-
message-ttl，用消息的生存时间，和死信队列来实现，具体有两种手段，A: 通过队列属性设置，队列
中所有消息都有相同的过期时间，粗粒度，编码简单 B: 对消息进行单独设置，每条消息TTL可以不同，
细粒度，但编码稍微复杂 。
优点：

• 可以随时在队列移除，实现实时取消订单，及时恢复订单占用的资源（如商品）
• 消息存储在mq中，不占用应用服务器资源
• 异步化处理，一旦处理能力不足，consumer集群可以很方便的扩容

缺点：

• 可能会导致消息大量堆积
• mq服务器一旦故障重启后，持久化的队列过期时间会被重新计算，造成精度不足
• 死信消息可能会导致监控系统频繁预警

redis实现
原理：
利用redis的notify-keyspace-events，该选项默认为空，改为Ex开启过期事件，配置消息监听 。每下一
单在redis中放置一个key（如订单id），并设置过期时间 。
优点:

• 消息都存储在Redis中，不占用应用内存 。
• 外部redis存储，应用down机不会丢失数据 。
• 做集群扩展相当方便
• 依赖redis超时，时间准确度高

缺点:

• 订单量大时，每一单都要存储redis内存，需要大量redis服务器资源

被动取消
原理：
在每次用户查询订单的时候，判断订单时间，超时则同时完成订单取消业务 。
优点：

• 实现极其简单
• 不会有额外的性能付出
• 不依赖任何外部中间件，只是应用逻辑的处理

缺点：

• 延迟度不可控，如果用户一直没触发查询，则订单一直挂着，既不支付也未取消，库存也就被占着

2.1.2 支付中心

文章插图

1）重复支付
（2018重复支付事故）
原因：
在第一步发起的时候，用户进入支付方式选择页 。选第一个支付方式并支付完后因为通知延迟，以为支
付失败 。在支付又选了第二种，再次支付 。
应对方案：
程序屏蔽，前端js触发按钮置灰或者遮罩提示（支付成功？遇到问题？），或者在支付方式选择页直接
跳转 。
后端处理，发现不同通道下的支付成功回调，抛消息队列或记录日志 。
数据修复：
首先查支付日志，确认针对同一笔订单收到了不同支付渠道的回调 。
其次，在支付平台管理后端可以查到入账记录，人工介入 。
最后对账阶段会发现对方多帐，我方补单时出现重复订单 。
问题处理：
调取退款接口或者在支付渠道的管理后台操作退款（一定要多次确认无误） 。
2）异常订单
支付但未开单
场景：
用户明明支付成功，但未开通订单
问题分析：
一般支付渠道会间隔性多次回调开单链接，如果支付未开单，银行未回调的可能性比较小，着重排查开
单接口是否可用 。如果可用追查日志是否出现异常记录 。
应对措施：
对账阶段可以查漏，程序自动完成补单，但是处理相对延迟，取决于支付渠道的对账文件下发周期

• 睡一觉醒来，左眼内双变成外双是怎么回事？如何变回来？
• 天蝎座是真的会把双鱼憋疯吗？
• 改革后重组的事业单位，早九晚五，双休，工资三千左右，要去吗？
• 双胞胎两个女儿的症状 怀双胞胎的症状有哪些
• 今日/资讯 盘点十大高仿普拉达女双肩包!2022已更新
• 教育“双减”政策下的教培人该何去何从？
• 双眼皮胶水好用吗，用双眼皮胶水有什么注意事项？
• 今日/资讯 盘点十大高仿普拉达双肩包!2022已更新
• 大蛇无双4 大蛇无双修改器怎么用
• 日本队向国际乒联抗议世乒赛女双决赛关键局擦网判罚，该球到底有没有擦网？你怎么看？