上一篇讲了微信支付快速入门,现在讲后端与青橙的对接
前端页面向后端传递订单号,后端根据订单号查询订单,检查是否为当前用户的未支付 订单,如果是则根据订单号和金额生成支付url返给前端,前端得到支付url生成支付二维 码。



(4)qingcheng_service_pay新增服务类
(5)qingcheng_web_portal新增PayController
前端代码就不放了
3. 青橙-支付回调逻辑处理


测试后,在控制台看到输出的消息



(2)OrderServiceImpl新增方法实现

青橙-推送支付通知

服务端推送方案

WebSocket 双向通信

RabbitMQ Web STOMP 插件

STOMP协议

青橙-超时未支付订单处理

如何获取超过60分钟的订单?我们目前有两种实现方案?

2.延时队列实现:
延时队列:延迟队列,即消息进入队列后不会立即被消费,只有到达指定时间后,才会被消费。
延时队列可以用TTL+死信交换机(或者说死信队列)实现
死信交换机和普通的交换机、死信队列和普通队列都没有区别
当消息成为死信后,如果该队列绑定了死信交换机,则消息会被死信交换机重新路由到死信队 列(这就是死信队列了)

其实在MQ里,死信交换机和死信队列是一样的意思,但为了好区分就把正常队列成为死信后发生给死信交换机,死信交换机再发给另一个队列(这个队列通常就叫做死信队列)

2.1消息的TTL(Time To Live)
这是5秒中没被消费,该消息就会被丢失
演示:
按添加

点进去:

5秒内是有数据的:

5秒后就消失了,成为了死信:

2.2死信交换器 Dead Letter Exchanges

我们现在可以测试一下延迟队列:
(1)创建死信交换器 exchange.ordertimeout (fanout)

(2)创建队列queue.ordertimeout (死信队列)

(3)建立死信交换器 exchange.ordertimeout 与队列queue.ordertimeout 之间的 绑定 routingkey为 exchange.ordertimeout.key (随便起,等下对应就行)
点进去刚刚(1)建的交换机绑定(2):

(4)创建队列queue.order,Arguments添加
x-message-ttl=5000 x-dead-letter-exchange: exchange.ordertimeout
x-dead-letter-routing-key: exchange.ordertimeout.key:
测试:向queue.order发布信息:
点进去:


一开始是这个信息在queue.order
然后等10秒之后,该消息会被死信交换机重新路由到死信队列queue.ordertimeout了:
这就是延迟队列了
消息可靠性保障
需求: 100%确保消息发送成功

消息幂等性(乐观锁)



本文介绍了青橙支付系统如何利用WebSocket进行服务端推送,通过RabbitMQ结合Web STOMP插件实现延迟队列处理超时未支付订单。同时讨论了消息的可靠性保障和幂等性设计,确保100%的消息发送成功和避免重复操作。
374

被折叠的 条评论
为什么被折叠?



