LYJbao的博客

当一个队列中的消息满足下列情况之一时，就会成为死信（Dead Letter）：消费者使用basic.reject或basic.nack声明消费失败，并且消息的Requeue参数设置为false消息是一个过期消息（达到了队列或消息本身设置的过期时间），超时无人消费要投递的队列消息堆积满了（可以给队列设置一个消息上限），最早的消息可能成为死信如果队列通过dead-letter-exchange属性指定了一个交换机，那么该队列中的死信就会投递到这个交换机中。

例如：我们在处理业务时，想要一个操作是幂等的，我们可以准备一个key value，当业务执行时，先判断redis中有没有这个key value，如果没有就写入这个redis，并执行业务后续操作，如果redis中已经存在这个kv了，就直接返回了~当消费者出现异常后，消息会不断重新入列到队列中，再重新发送给消费者，然后再次异常，再次重新入列，无限循环，导致mq的消息处理飙升，带来不必要的压力。那生产者是发送消息后，就一直等着这个回执，还是发送消息后，就干别的事了，等回执来了，再处理呢？其实这都是可以配置的~

Spring的消息发送，代码接收的消息体是一个Object，在数据传输时，它会把你发送的消息序列化为字节发送给MQ，接收消息的时候，还会把字节反序列化为Java对象~注：队列和交换机的声明是放在消费者这边的，这位发送的人他并不需要去关注发送给那个队列，但消费者这边是需要队列自己清楚应该监听那个交换机，监听那个类型的消息的~为了解决以上问题，我们可以使用JSON转换器~上述的方式还是很繁琐的。

此时支付服务会把支付结果发送到交换机中，而短信服务就会去监听这个交换机，但是交换机不会把所有的消息都路由给短信服务，而只把支付成功的消息路由给这个短信服务。这种情况下，就需要使用到这个Direct交换机，短信服务下的队列和这个交换机设置一个key（例如：success），支付服务发消息时，支付成功RoutingKey设为success，失败为fail，交换机就会只把key为success的消息路由给短信服务了~上图中，就是，key为blue，消费者1去消费；一个只能接到新闻，一个只能接到和中国相关的消息~

也就是说，你在使用中，只需要调用Spring AMQP提供的接口就可以了，而Spring AMQP的底层是使用AMQP的（可以理解为AMQP是一种思想，Spring AMQP是它的实现）；RabbitMq给java提供的原生的一些使用方法，过于的复杂不便于日常开发的使用，而Spring-AMQP对RabbitMQ进行了一层封装，让我们在使用中更加的简洁了~修改application.yml，设置preFetch的值为1，确保同一时刻最多投递给消费者1条消息，一条处理完了，才会收到下一条~

publisher：消息发送者consumer：消息的消费者queue：队列、存储消息exchange：交换机，负责路由消息virtual-host：虚拟主机，起到数据隔离的作用结合图来理解：消息发送者不是直接把消息塞到队列中，而是先把消息发到交换机，由交换机把消息路由到队列中；由上图可以发现交换机可以只路由给一个队列，也可以路由给所有队列；消费者监听队列，就可以拿到消息了~RabbitMQ的服务端（消息代理）就包括了交换机和队列两部分 ~

根据上图理解异步调用： 例如正在跨年夜，我们要给跟多人发送新年快乐的消息，同步调用我们可以为，我们自己需要给一个人发送完新年快乐之后，他也给我们回复了同乐，然后我们再给第二个人发送新年快乐~ 异步调用我们可以理解为，我们使用微信的群发功能，我们把消息发出来，微信服务器作为一个消息代理，收到这个消息后，把这个消息广播出来，而我们的微信好友就会去监听这个广播，就会收到你的新年祝福了~上图分析：流程 - 进行支付操作时，我们先去扣除用户余额，扣除失败，可能是余额不足，支付操作结束；为什么想要异步通信呢？