https://www.processon.com/diagraming/61a18a895653bb136f893ecc
当用户点击立即购买或者提交订单的这个时候数据库就会记录一笔订单
此项业务主要是用到了rabbitMQ中的死信队列，大致流程就是，
- 当用户提交订单的时候将消息存储到rabbitMQ当中，
- 设置的订单超时时间是一个小时，
- 当用户一个小时未支付rabbitMQ就会将次订单号自动发送到死信队列，
- 然后监控订单状态的系统去对接此死信队列，判断此订单号是否支付，然后修改对应的支付状态。
当用户点击付款的这个时候，可选择微信支付或者支付宝支付
以微信支付为例，当用户选中微信支付的时候服务器会调用统一的微信支付接口，而微信支付接口需要与微信服务器建立连接，其中在建立连接时就需要三个必要的参数，分别是商户账号AppId，商户编号，商户key（秘钥），
通过上述参数来构造PayConfig接口实现类，通过此实现类去建立微信的连接，建立连接之后就需要与微信的服务器进行通信，通过必要的参数来获得，支付链接，通过支付链接来生成二维码，从而实现微信二维码支付，上述提到的必要参数包括：支付说明、订单号、支付模式、支付金额、交易的类型、支付完成时微信回调方法的接口（需要内网穿透）。
成功调用微信服务器对应接口之后，可得到用户支付的的必要参数，如支付短连接和支付金额，商品信息等等，通过这些必要参数由前端生成支付界面，然后用户就可自行支付，
当用户扫码并付款后，这个时候会有较为多的消息需要处理
比如(对微信服务器支付后结果的处理、订单状态的修改、支付流水的记录、支付积分的累计、消费劵的领取)，通过上述的分析我们清晰的意识到如果上述问题用同步的方式处理那将是一个非常耗时的任务，所以当时我们采取了MQ（消息队列）来处理消息，又基于rabbitMQ强大的功能性，我们选择了此面向消息的中间件。
此需求的处理显而易见肯定是在高并发的场景之下完成，我们设计了三个系统来保证消息的完整性，有消息的生产系统、消息的补偿系统、消息消费后后续系统操作，
消息的生产系统：在消息的生产系统包含了crud的大多操作，所以这个时候就需要事务，通过事务的具有的特性来完成以下步骤：
- 支付相关消息的编写（支付流水的记录，支付状态的修改等等），
- 将投递给MQ的消息存储到数据库，
- 将消息投递给MQ。完成上述事务之后，
这个时候消息的主要操作就到了rabbitMQ当中，rabbitMQ需要判断消息是否到达了交换机与队列，如果到达到了最终的队列就将消息消费掉之后进行删除，只要在交换机或者队列的任意一个步骤出错就什么都不做。
消息的补偿系统：定时扫描数据库中未被消费的消息，将未被消息的消息进行重复投递。
消息消费的后续系统操作：上述两个系统保证了消息的可靠性投递，这最后一个系统就将这些消息来进行业务处理，主要包含了以下业务：支付流水的记录，消费积分的记录，订单状态的修改，消费劵的领取等等。
