A的博客

假设当前使用的是 RabbitMQ，且只有一个消费者在处理消息，该消费者处理一条消息平均耗时 100 毫秒（即每秒处理 10 条消息）。那么增加到 10 个消费者后，如果每个消费者的处理能力相同且不存在资源竞争等问题，理论上处理速度可提升到每秒 100 条消息。案例：在一个电商订单处理系统中，订单创建成功后会发送一条消息到 MQ，原本单个消费者负责处理订单消息并更新库存、生成物流订单等操作。当消息大量堆积时，可启动多个消费者实例，每个实例都能独立地从 MQ 中获取订单消息并进行处理。但在实际情况中，若消费者

通过RabbitMQ本身所提供的机制基本上已经可以保证消息不丢失 , 但是因为一些特殊的原因还是会发送消息丢失问题 , 例如 : 回调丢失 , 系统宕机, 磁盘损坏等 , 这种概率很小 , 但是如果想规避这些问题 , 进一步提高消息发送的成功率, 也可以通过程序自己进行控制。, 之后再向MQ发送消息 , 消费方接收消息消费完毕之后 , 向发送方发送一条签收消息 , 发送方接收到签收消息之后 , 修改消息状态表中的消息状态为。消息从发送，到消费者接收，会经理多个过程 , 其中的每一步都可能导致消息丢失。

RabbitMQ Streams 是一种持久复制的数据结构，可以完成与队列相同的任务：它们缓冲来自生产者的消息，供消费者读取。但是，流在两个重要方面与队列不同：消息的存储和使用方式。流对消息的仅追加日志进行建模，这些消息可以重复读取，直到它们过期。流始终是持久和复制的。对这种流行为的更技术性的描述是“非破坏性消费者语义”。要从 RabbitMQ 中的流中读取消息，一个或多个使用者订阅该流并根据需要多次读取相同的消息。流中的数据可以通过 RabbitMQ 客户端库或专用二进制协议插件和关联的客户端使用。

最重要的变化是 我们现在希望将消息发布到我们的交易所，而不是 无名的。交换机是一个非常简单的东西。第一个队列绑定了绑定键，第二个队列绑定了绑定键 有两个绑定，一个带有绑定键，另一个带有绑定键 跟。首先，每当我们连接到 Rabbit 时，我们都需要一个全新的空队列。为此，我们可以创建一个具有随机名称的队列，或者更好的是 - 让服务器为我们选择一个随机的队列名称。正如你可能从名称中猜到的那样，它只是将接收到的所有消息广播到它所知道的所有队列。在之前的教程中，我们对交换机一无所知，但仍然能够将消息发送到队列。

我们的RPC将按以下方式工作：对于一个RPC请求，客户端发送带有两个属性的消息：replyTo，设置为专门为该请求创建的匿名独占队列；correlationId，设置为每个请求的唯一值。请求被发送到一个名为 rpc_queue 的队列。RPC工作者（又名：服务器）正在该队列上等待请求。当出现请求时，它执行任务并将带有结果的消息发送回客户端，使用来自replyTo字段的队列。客户端在回复队列上等待数据。当出现消息时，它检查correlationId属性。

使用消息确认和 prefetchCount 可以建立一个工作队列通过使用消息确认（message acknowledgments）和 prefetchCount，您可以设置一个工作队列。消息确认确保在处理完消息后，消费者向 RabbitMQ 确认消息已经处理完成，从而使消息不会在队列中丢失或重复处理。而 prefetchCount 则可以控制每个消费者一次获取的消息数量，以确保任务的公平分发。持久性选项让任务即使在 RabbitMQ 重新启动后也能够存活。

如果这是您第一次使用 RabbitMQ，并且您没有看到“已发送” 消息，那么你可能会挠头，想知道什么可以 错了。由于它将异步推送我们消息，因此我们提供了一个 以对象的形式进行回调，该对象将缓冲消息，直到 我们已准备好使用它们。在下图中，“P”是我们的生产者，“C”是我们的消费者。我们的消费者会收听来自 RabbitMQ，所以与发布单个消息的发布者不同，我们将让使用者保持运行以侦听消息并将其打印出来。我们打开一个连接和一个 channel，并声明我们将要从中使用的队列。请注意，我们也在此处声明队列。

打开任务资源管理器Win10，WIn11 的快捷键都是Ctrl+Shift+Esc，找到rabbitmq服务-右键-开始/重新启动。选择图中选中进行下载，最后会下载一个rabbitmq-server-x.x.x的安装包文件，注意要放到无中文路径下，避免有问题。【注意】不要安装在中文或带空格的文件路径下，双击下载的安装包rabbitmq-server-x.x.x。安装路径，我这里又新建了一层RabbitMQ-Server，然后无脑下一步。，我这里是64位的就下载64-bit对应的，会看到右上角已经在下载了。