RabbitMq的常见问题个人笔记

RabbitMq的常见问题

RabbitMq有哪几种交换机类型？

Rabbitmq共有四种类型的交换机，分别为Direct Exchange（直连交换机）；Fanout Exchange（扇出交换机）；Topic Exchange（主题交换机）；Header Exchange（头交换机）。

RabbitMq消息分发有哪几种模式？

模式1：简单模式（Simple / HelloWorld 单生产单消费）**

简单的发送与接收，没有特别的处理。
业务场景：适用于简单的消息传递场景，例如一个生产者对应一个消费者的情况。
举例：将发送的电子邮件放到消息队列，然后邮件服务在队列中获取邮件并发送给收件人。

模式2：工作模式（Work单发送多接收）

一个生产者端，多个消费者端。示例中为了保证消息发送的可靠性，不丢失消息，使消息持久化了。同时为了防止接收端在处理消息时down掉，只有在消息处理完成后才发送消息确认。
业务场景：适用于执行资源密集型任务，单个消费者处理不过来，需要多个消费者进行处理的情况。
举例：一个订单的处理需要10秒，有多个订单可以同时放到消息队列，然后让多个消费者同时处理，这样可以并行处理，而不是单个消费者的串行情况。另一个例子是12306的短信服务。

模式3：发布、订阅模式(Publish/Subscribe)
使用场景：发布、订阅模式，生产者端发送消息，多个消费者同时接收所有的消息。
业务场景：适用于需要向多个消费者发送消息的场景，即消息将被广播到所有的消费者中。
举例：更新商品库存后需要通知多个缓存和多个数据库。中国气象局提供气象信息，腾讯、网易等都能拿到相同的气象信息。

模式4：路由模式（Routing）
生产者按routing key发送消息，不同的消费者端按不同的routing key接收消息。
业务场景：适用于有选择地接收消息的场景，即发送消息到交换机时需要指定路由键，消费者将队列绑定到交换机时也需要指定路由键，仅消费指定路由键的消息。
举例：如在商品库存中增加了1台iphone12，iphone12促销活动消费者指定routing key为iphone12，只有此促销活动会接收到消息，其它促销活动不关心也不会消费此routing key的消息。

模式5：通配符（或主题）模式（Topics ，按topic发送接收)
生产者端不只按固定的routing key发送消息，而是按字符串“匹配”发送，消费者端同样如此。
与之前的路由模式相比，它将信息的传输类型的key更加细化，以“key1.key2.keyN…”的模式来指定信息传输的key的大类型和大类型下面的小类型，让消费者端可以更加精细的确认自己想要获取的信息类型。而在消费者端，不用精确的指定具体到哪一个大类型下的小类型的key，而是可以使用类似正则表达式(但与正则表达式规则完全不同)的通配符在指定一定范围或符合某一个字符串匹配规则的key，来获取想要的信息。“通配符交换机”（Topic Exchange）将路由键和某模式进行匹配。此时队列需要绑定在一个模式上。符号“#”匹配一个或多个词，符号“*”仅匹配一个词。

业务场景：适用于根据主题接收消息的场景，即路由键和某模式进行匹配，此时队列需要绑定在一个模式上。
举例：iphone促销活动可以接收主题为iphone的消息，如iphone12、iphone13等。

什么是死信队列、延迟队列？

死信队列：由消息TTL过期、队列已满无法加入或消息被拒绝等无法被消费的消息，如果后续没处理，则变成了死信。死信被处理的队列就是死信队列。

延时队列：消息延时消费，用例如：

1.订单在十分钟之内未支付则自动取消

2.新创建的店铺，如果在十天内都没有上传过商品，则自动发送消息提醒。

3.用户注册成功后，如果三天内没有登陆则进行短信提醒。

4.用户发起退款，如果三天内没有得到处理则通知相关运营人员。

5.预定会议后，需要在预定的时间点前十分钟通知各个与会人员参加会议。

延时队列可设置消息设置TTL，也可设置队列TTL。

两者的区别是：

1. 消息属性设置TTL：这种方式是在发送消息到队列时，通过消息的属性来设置消息的TTL（Time To Live）。如果消息在队列中待的时间超过设定的TTL，那么这个消息将会被丢弃。这种方式的判断是在消息即将发送给消费者时进行的。如果当前队列有严重的消息积压情况，那么已过期的消息也许还能存活较长时间。
2. 队列设置TTL：这种方式是在创建队列时，通过队列的属性来设置整个队列的TTL。如果消息在队列中待的时间超过设定的TTL，那么这个消息将会被丢弃。过期的消息会出现在队列头，从队列头开始扫描（定时扫描）到没有过期的消息前，将这一段的消息全部抛弃。

如何保证消息消费的幂等性？

1、生成全局id，存入redis或者数据库，在消费者消费消息之前，查询一下该消息是否有消费过。

2、如果该消息已经消费过，则告诉mq消息已经消费，将该消息丢弃（手动ack）。

3、如果没有消费过，将该消息进行消费并将消费记录写进redis或者数据库中。

如何防止消息丢失？

先分析消息丢失的原因，什么情况下会丢失消息。

生产者到交换机：开启RabbitMq事务，或使用消息确认机制（可以异步确认，效率高），两者不能共存。

RabbitMq自身问题：消息持久化发送，交换机持久化，队列持久化。

交换机到消费者（路由失败）：

消费者消费消息时：手动ack，然后定时任务重新发送消息。

如何解决消息积压问题？

检查消息积压的原因，消息产生是否合理？

消息消费是否出现问题，有问题处理问题。

是否时消费速度过慢？消息消费的机制，是否有消息确认机制，由单确认改为批量确认或异步确认。优化消费者性能。或增加消费者节点。或者将消息分片处理，减少消息单个处理的时间。

分布式项目中如何可保证消息的顺序消费？

如何保证RabbitMQ消息顺序消费_rabbitmq怎么保证消息顺序消费-CSDN博客