商城下单逻辑

1、为了保证接口防刷，防止多次点击下单造成数据的冗余，需要保证下单接口的幂等性，本文通过防重令牌的方式，防止订单多次被点击。将服务器（redis）中放一分令牌，页面存一份令牌，在保存订单数据之前需要验证页面带过来的令牌，如果令牌相同则进行创建订单，同时删除令牌（保证获取令牌、令牌比较和令牌的删除是一个原子操作，防止点击过快，两个请求同时获取令牌，同时比较，同时删令牌，这样订单数据就会出现冗余）使用lua脚本
2、令牌验证成功后需要创建订单-验证价格，价格验证成功后需要保存订单，同时锁定库存，由于锁定库存服务是个远程服务，如果在下单过程中锁定库存后续代码出现问题，则库存还是会进行锁定的，而由于订单下单失败，所有的业务会进行回滚，造成库存锁定失败，所以需要采用一种方式保证数据的一致性
3、采用延时队列，库存只要锁定成功则像锁定库存队列中发送库存锁定信息，当订单到点未支付，过一定期限将库存延迟队列中的消息发给交换机，通过路由不同转到另一个释放锁定库存信息的队列。将库存进行解锁
4、当订单下成功后需要像订单延迟队列中发送订单下单信息，当订单到点未支付将延迟队列中的信息按照3中所指进行释放，同时直接将库存锁定信息发送给库存解锁队列，对库存直接进行解锁（库存延迟队列中的消息到点后找到库存解锁状态发现无需进行解锁）

柔性事务-可靠消息+最终一致性方案

mq可靠消息如何保证？

消息丢失

消息发送出去 由于网络问题没有抵达服务器

• 做好容错机制：消息发送后，网络异常进行重试机制，并将数据库中保存发送记录信息及状态
• 做好日志记录：每个消息状态是否都被服务器收到做好记录
• 做好定期重发：每隔一段时间去扫描数据库，对未成功的消息进行重发

消息抵达Broke，Broke要将消息写入磁盘（持久化）才算成功。此时Broke尚未持久化完成，宕机。

• 发送者要必须加入确认回调机制，保证成功的消息，修改数据库的状态信息

自动ACK的状态下。消费者还没来得急消费消息，就被自动确认了

• 接收者可以等消息完全消费完成后对消息进行手动ACK

配置信息

#开启发送端消息确认
spring.rabbitmq.publisher-confirms=true
#开启发送端消息抵达队列确认
spring.rabbitmq.publisher-returns=true
#只要抵达队列，以异步发送优先回调我们这个returnconfirm
spring.rabbitmq.template.mandatory=true

 		/**
 		 * 发送端进行消息回调
         * 只要消息抵达broker就ack=true
         */
        rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
            @Override
            public void confirm(CorrelationData correlationData, boolean b, String s) {
            	//调用该方法则收到消息
				//修改数据库的状态信息
            }
        });

//手动ACK
channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);

消息重复

消息消费成功，事务已经提交，ack时，机器宕机。导致没有ack成功，Broker的消息重新由unack变为ready，并发送给其他消费者

消息消费失败，由于重试机制，自动又将消息发送出去

成功消费，ack时宕机，消息由unack变为ready，Broker又重新发送
解决：
• 消费者的业务消费接口应该设计为幂等性的。比如扣库存有
工作单的状态标志
• 使用防重表（redis/mysql），发送消息每一个都有业务的唯
一标识，处理过就不用处理
• rabbitMQ的每一个消息都有redelivered字段，可以获取是否
是被重新投递过来的，而不是第一次投递过来的

消息积压

消费者宕机积压

消费者消费能力不足积压

发送者发送流量太大
解决：
• 上线更多的消费者，进行正常消费
• 上线专门的队列消费服务，将消息先批量取出来，记录数据库，离线慢慢处理