php网站源码删除培训总结心得体会

在前面的章节中我们简单介绍过一些RabbitMQ的工作模式，RabbitMQ共提供了七种工作模式进行消息传递，这里我们来详细介绍。

1. Simple(简单模式)

P：生产者

C：消费者

特点：一个生产者一个消费者，消息只能被消费一次，也称为点对点（Point-to-Point）模式。我们上期写的示例就是这个模式

适用场景：消息只能被单个消费者处理。

2. Work Queue（工作队列） 

一个生产者，多个消费者，将消息分给不同的消费者，每个消费者收到不同的消息。

特点：消息不会被重复处理

使用场景：集群环境中做异步处理，例如12306短信通知服务，订票成功后，订单消息会发送给RabbitMQ，短信服务从RabbitMQ中获取订单信息并发送通知信息 。

3. Publish/Subscribe(发布/订阅)

 X表示交换机，生产者将消息发送给Exchange，由交换机按一定的规则路由到一个或多个队列中。

特点：一个生产者多个消费者，生产者发送一条消息，交换机（Fanout）转发给所有绑定的队列。

适用场景：消息需要被多个消费者同时接收的场景，如实时通知或者广播消息。例如电商平台下单后，同时触发 “用户通知”“库存扣减”“订单统计” 多个操作。

RabbitMQ有四种类型的交换机，不同类型有不同的路由策略：

1. Fanout：广播，将消息交给所有绑定到交换机的队列（Publish/Subcribe模式）
2. Direct：定向，把消息交给符合指定routing key的队列（Routing模式）
3. Topic：通配符，把消息交给符合routing pattern（路由模式）的队列（Topics模式）
4. Headers：headers类型的交换机不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配，headers类型的交换机性能会很差，而且也不实用，基本不会看到它的存在。

Exchange只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与Exchange绑定，或者没有符合路由规则的队列，那么消息就会丢失

注意：简单模式 和 工作队列模式 也会使用交换机转发消息，不会在生产者把消息直接发送给队列的情况，通常这两种模式使用的是Direct交换机，routing key通常为队列名。

• routing key：路由键，生产者将消息发送给交换机时指定的一个字符串，用来告诉交换机把消息转发到哪个队列。每个消息只能有一个routing key
• binding key：绑定，队列在绑定到交换机时，需要指定 BindingKey 作为匹配规则，只接收routing key对应的消息。一个队列可以有多个binding key，通过多次绑定实现

 4. Routing（路由模式）

路由模式是发布订阅模式的变种，在发送订阅的基础上，增加routing key，发布订阅模式是无条件将消息转发给所有队列，路由模式Exchange会根据routing key的规则来转发。

适用场景，需要根据特定规则分发消息的场景，例如系统打印日志，日志等级分为error,warning,info,debug,就可以通过这种模式把不同日志发送到不同的队列，最终输出到不同的文件。

5. Topics（通配符模式）

路由模式的升级版，在 Routing的基础上，增加了通配符的功能，即队列的bingding key可以写作通配符的模式来匹配不同的routing key

通配符规则：

• *（星号）：匹配一个单词（如"order.*"匹配"order.create"但不匹配"order.create.success"）。
• #（井号）：匹配零个或多个单词（如"order.#"匹配所有以"order."开头的 Routing Key）。

适用场景：需要灵活匹配和过滤消息的场景 

6. RPC（RPC通信） 

在PRC通信中，没有生产者和消费者，通过两个队列实现了一个远程过程调用

1. 客户端发送请求：将请求消息发送到服务端队列，并附带一个回调队列地址和唯一请求 ID（correlation ID）。
2. 服务端处理并响应：接收请求、处理逻辑，然后将结果发送到回调队列，同时携带相同的 correlation ID。
3. 客户端匹配响应：根据 correlation ID 将响应与请求关联，实现 “伪同步” 效果。

 

适用场景：

• 需要异步解耦但又需即时结果的场景。例如微服务间的轻量级通信。
• 跨语言服务调用（RabbitMQ 支持多语言客户端）。

7. Publisher Confirms（发布确认）

Publisher Confirms模式是RabbitMQ提供的一种确保消息可靠发送到RabbitMQ服务器的机制，在这种模式下，生产者可以等待RabbitMQ服务器的确认，确保消息已经被服务器接收并处理。在默认模式下，生产者发送消息后不会收到任何反馈，若网络故障或交换机异常，消息可能丢失。而发布确认机制可以解决这一问题：

1. 生产者发送消息：生产者将Channel设置为confirm模式后，发送消息会附带唯一的序列号（Sequence Number）。
2. RabbitMQ 确认：交换机收到消息后，异步返回一个确认帧（Confirm Frame），包含相同的序列号。
3. 生产者处理确认：根据序列号匹配确认结果，标记消息为 “已确认” 或 “未确认”。

适用场景：对数据安全性要求高的场景，例如金融交易，订单处理