在哪里做网站设计线上营销手段

1. 简单模式

• P：生产者
• C：消费者
• Queue：队列

特点： 一个生产者，一个消费者。

• 也称为点对点模式
  适用场景： 消息只能被单个消费者处理

2. 工作队列模式

• 一个生产者有多个消费者
  • 队列会将消息分派给不同的消费者
  • 每个消费者都会接收到不同的消息
• 适用场景：集群环境中做异步处理

如果队列中有 10 条消息，那么 C1 和 C2 是共同消费这 10 条消息，消息不会重复消费

比如 12306 短信通知服务，订票成功后，订单消息会发送到 RabbitMQ，短信服务从 RabbitMQ 中获取订单信息，并发送通知信息（在短信服务之间进行任务分配）

3. 发布订阅模式

• X：表示交换机

交换机

Exchange：交换机（X）

作用：生产者将消息发送到 Exchange，由交换机将消息按一定规则路由到一个或多个队列中（上图中生产者将消息投递到队列中，实际上这个在 RabbitMQ 中不会发生）

类型

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

1. Fanout：广播，将消息交给所有绑定到交换机的队列（Publish/Subscribe 模式）
   • 在 RabbitMQ 工作流程中，交换机和队列之间是有绑定关系的（一对一，一对多，一对无）
2. Direct：定向，把消息交给符合指定 routing key 的队列（Routing 模式）
   • Routing Key：路由键。生产者将消息发送给交换器时，指定的一个字符串，用来告诉交换机应该如何处理这个消息
   • Binding Key：绑定。RabbitMQ 中通过 Binding 将交换器于队列关联起来，在绑定的时候一般会指定一个 Binding Key，这样 RabbitMQ 就知道如何正确地将消息路由到队列了

比如下图：如果在发送消息时，设置了 RoutingKey 为 orange，消息就会路由到 Q1
当消息的 Routing Key 与队列绑定的 BindingKey 相匹配时，消息才会被路由到这个队列

Bindingkey 其实也属于路由键中的一种，官方解释为：the routingkey to use for the binding。可以解释为：在绑定的时候使用的路由键。大多数时候，包括官方文档和 RabbitMQ Java API 中都把 BindingKey 和 RoutingKey 看做 RoutingKey，为了避免混淆，可以这么理解

1. 在使用绑定的时候，需要的路由键是 BindingKey
2. 正在发送消息的时候，需要的路由键是 RoutingKey

3. Topic：通配符，把消息交给符合 routing pattern（路由模式）的队列（Topic 模式）
4. headers：此类型不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中的 headers 属性进行匹配。headers 类型的交换器性能会很差，而且也不实用，基本上不会看到他的存在

Publish/Subscribe 模式

一个生产者 P，多个消费者 C1、C2，X 代表交换机消息复制多份，每个消费者接收相同的消息

• 生产者发送一条消息，经过交换机转发到多个不同的队列，多个不同的队列就有多个不同的消费者
• 适合场景：消息需要被多个消费者同时接收的场景。如：实时通知或者广播通信

比如中国气象局发布“天气预报”的消息送入交换机，新浪、百度、搜狐、网易等门户网站介入消息，通过对类绑定到该交换机，自动获取气象局推送的气象数据

4. Routing（路由模式）

• 路由模式是发布订阅模式的变种，在发布订阅基础上，增加路由 key
• 发布订阅模式是无条件的将所有消息分发给所有消费者，路由模式是 Exchange 根据 RoutingKey 的规则，将数据筛选后发给对应的消费者队列
• 适用场景：需要根据特定规则分发消息的场景

比如系统打印日志，日志等级分为 error、warning、info、debug，就可以通过这种模式，把不同的日志发送到不同的队列，最终输出到不同的文件

5. Topics（通配符模式）

• 路由模式的升级版，在 Routingkey 的基础上，增加了通配符的功能，使之更加灵活
• Topics 和 Routing 的基本原理相同
  • 即：生产者将消息发给交换机，交换机根据 RoutingKey 将消息转发给与 RoutingKey 匹配的队列，类似于正则表达式的方式来定义 RoutingKey 的模式
  • 不同之处在：RoutingKey 的匹配方式不同，Routing 模式是相等匹配，Topics 模式是通配符匹配
    • 如果 RoutingKey 是 b.a.c，就会发到 Q1
    • * 表示一个单词，# 表示多个单词
• 适用场景：需要灵活匹配和过滤消息的场景

6. RPC（RPC 通信）

在 RPC 通信的过程中，没有生产者和消费者，比较像 RPC 远程调用，大概就是通过两个队列实现了一个可回调的过程

1. 客户端发送消息到一个指定的队列，并在消息属性中设置 replyTo 字段，这个字段制定了一个回调队列，用于接收服务端的响应
2. 服务端接受到请求后，处理请求并发送响应消息到 replyTo 指定的回调队列
3. 客户端再回调队列上等待响应消息。一旦收到响应，客户端会检查消息的 correlatiodId 属性，以确保它是所期望的相应

7. Publisher Confirms（发布确认）

Publisher Confirms 模式是 RabbitMQ 提供的一直确保消息可靠发送到 RabbitMQ 服务器的机制。在这种模式下，生产者可以等待 RabbitMQ 服务器的确认，以确保消息已经被服务器接受并处理

1. 生产者将 Channel 设置为 confirm 模式(通过调用 channel.confirmSelect() 完成) 后，发布的每一条消息都会获得一个唯一的 ID，生产者可以将这些序列号与消息关联起来，以便跟踪消息的状态
2. 当消息被 RabbitMQ 服务器接收并处理后，服务器会异步地向生产者发送一个确认 (ACK) 给生产者 (包含消息的唯一 ID)，表明消息已经送达

通过 Publisher Confirms 模式，生产者可以确保消息被 RabbitMQ 服务器成功接收，从而避免消息丢失的问题

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

工作模式的使用案例

简单模式

safj