幂等性

概念

用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。 举个最简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常， 此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额发现多扣钱 了，流水记录也变成了两条。在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误 立即回滚，但是再响应客户端的时候也有可能出现网络中断或者异常等等。

消息重复消费

消费者在消费 MQ 中的消息时，MQ 已把消息发送给消费者，消费者在给MQ 返回 ack 时网络中断， 故 MQ 未收到确认信息，该条消息会重新发给其他的消费者，或者在网络重连后再次发送给该消费者，但 实际上该消费者已成功消费了该条消息，造成消费者消费了重复的消息。

在生产环境中由于一些不明原因，导致 RabbitMQ 重启，在 RabbitMQ 重启期间生产者消息投递失败，导致消息丢失，需要手动处理和恢复。于是，我们开始思考，如何才能进行 RabbitMQ 的消息可靠投递呢？特别是在这样比较极端的情况下，RabbitMQ 集群不可用的时候，无法投递的消息该如何处理？

为了解决这个问题，可以通过 RabbitMQ 的发布确认来解决，消息生产者将消息投递到 MQ 当 MQ 收到消息后，进行一个反聩，消息生产者通过这个反馈来辨别消息是否成功投递。

延迟队列，队列的内部是有序的，最重要的特性就是体现在它的延时属性上，延迟队列中的元素是希望在指定时间到了以后或之前取出和处理 ，简单来说，延时队列就是用来存放需要在指定时间内被处理的元素的队列。

延迟队列使用场景

• 订单在十分钟之内未支付则自动取消
• 新创建的店铺，如果在十天内都没有上传过商品，则自动发送消息提醒
• 新用户注册成功后，如果三天内没有登录则进行短信提醒
• 用户发起退款，如果三天内没有得到处理则通知相关运营人员
• 预定会议后，需要在预定的时间点前 10 分钟通知各个参会人员参加会议

死信在 RabbitMQ 中指无法被正常消费的消息。通常情况下，生产者将消息投递到 Broker 或是消息队列中，消费者直接从消息队列中取出消息进行消费即可，但由于某些特殊原因导致了消息队列中的某些消息无法被消费，这样的消息如果没有后续的处理，就变成了死信，有死信自然就有了死信队列。

应用场景：为了保证订单业务的消息数据不丢失，就可以使用 RabbitMQ 的死信队列机制，当消息消费发生异常时，将消息投入死信队列中。还有一种场景，用户在商城下单成功并点击去支付后在指定时间未支付时自动失效。

死信的来源

• 消息 TTL 过期
• 队列达到最大长度（队列满了，无法再添加数据到指定的队列中）
• 消息被拒绝（basic.reject 或 basic.nack）并且 requeue = false

在 Fanout 模式中，是将所有的日志详细广播出去，所有与交换机绑定的队列都会收到消息，并且是一摸一样的。对此我们想做一些改变，例如我们希望将日志消息写入磁盘的程序仅接受 error 类型的日志，而不存储那些 warn 或 info 类型的日志从而到达节省磁盘空间。Fanout 这种交换类型并不能给我们带来很大的灵活性，它只能进行广播，在这里我们将使用 Direct 这种类型来替换，这种类型的工作方式是，消息只去到它绑定的 routingKey 队列中。

在上面的这张图中，可以看到 X 绑定了两个队列，绑定类型是 direct。队列 Q1 绑定键为 orange，队列 Q2 绑定键有两个：一个绑定键为 black，另一个绑定键为 green。