- Published on
rabbitmq集群简介
集群的两种模式
RabbitMQ 支持多种集群模式，主要为了提高消息中间件的可用性和扩展性。两种常见的 RabbitMQ 集群类型是：
普通集群（Cluster）：在普通集群模式下，所有的 RabbitMQ 节点共享相同的 Erlang 分布式数据库，使得每个节点都能访问到完整的队列、交换器和绑定信息。消息队列的实际内容（消息）存储在创建队列的节点上，如果需要从其他节点访问队列中的消息，这些消息会通过集群内部的网络传输。这种模式主要提高了系统的可用性和负载均衡能力，但并不提供消息或队列的冗余。
镜像队列集群（Mirrored Queues）：镜像队列是 RabbitMQ 提供的一种高可用性方案。在这种模式下，队列中的消息会被复制到集群中的其他节点，创建出队列的镜像。如果持有队列主副本的节点发生故障，集群中的一个镜像可以自动接管，成为新的主副本，保证消息的可用性。这种模式提高了消息的可靠性，但可能会增加消息传输的延迟，并且对网络带宽和节点之间的同步有更高的要求。
这两种模式可以根据应用场景和需求来选择，例如，如果应用需要高可用性和消息的冗余备份，可以选择镜像队列集群模式。如果应用更注重性能和低延迟，可能会倾向于使用普通集群模式，并通过其他机制来保证消息的持久性和可靠性。
事务简介
RabbitMQ 支持事务机制，允许发布者（publishers）和消费者（consumers）以原子方式执行一系列操作，确保消息的发送或接收要么完全成功，要么完全失败，从而保证消息处理过程的一致性和完整性。然而，使用事务会带来性能开销，因为它需要更多的磁盘I/O操作来保证操作的原子性和持久性。
RabbitMQ 事务的主要操作包括：
Tx.Select：启动事务模式。这个命令告诉 RabbitMQ 后续的操作将会在事务模式下执行。
Tx.Commit：提交事务。如果事务中的所有消息操作（发布或确认）都成功执行，使用此命令可以将这些更改永久保存到队列中。
Tx.Rollback：回滚事务。如果事务中的某个操作失败，可以使用此命令撤销所有在当前事务中进行的更改。
使用场景和性能考虑：
使用场景：当需要确保消息的完整性和一致性时，事务机制非常有用。例如，当一个应用程序既需要发送消息也需要更新本地数据库时，使用事务可以保证这两个操作要么都成功，要么都不发生。
性能考虑：虽然事务提供了数据一致性的保证，但由于涉及到磁盘的同步写操作，事务的使用可能会显著降低消息吞吐量。因此，在追求高性能的系统中，通常建议使用其他机制，如确认机制（Publisher Confirms 或 Publisher Acknowledgements），来确保消息的可靠传递，同时保持较高的性能。
替代方案：
- Publisher Confirms（发布者确认）：这是一个轻量级的、非事务性的方式，用于确保消息被 RabbitMQ 服务器接收。与事务相比，发布者确认机制在保证消息可靠性的同时，提供了更好的性能。
总的来说，虽然 RabbitMQ 的事务机制可以提供强一致性保证，但由于其对性能的影响，开发者在使用时需要根据实际场景和性能需求做出权衡。在多数情况下，利用发布者确认机制来实现消息的可靠传递会是一个更优的选择。
镜像队列集群通信
在 RabbitMQ 的镜像队列（Mirrored Queues）模式下，消息同步的机制是由主副本节点主动通知其他节点。当在镜像队列模式中创建队列时，队列的主副本会负责管理和存储消息。一旦消息被发布到这个队列，主副本节点就会主动将这些消息复制到其他节点上的镜像队列中。
这个过程可以描述如下：
消息发布：当一个消息被发送到镜像队列时，它首先到达主副本所在的节点。
消息复制：主副本节点随后将消息复制到集群中其他节点上的队列镜像中。这一步是主动由主副本节点发起的，它确保了所有的镜像都有了最新的消息副本。
确认和同步：一旦消息成功复制到所有的镜像中，相应的确认信息会被发送回生产者，如果配置了消息确认的话。这个过程保证了消息的一致性和可靠性。
镜像队列模式主要用于提高队列的可用性和耐用性。如果主副本所在的节点发生故障，集群会自动从剩余的镜像中选举出一个新的主副本，从而保证队列的服务不会中断。
需要注意的是，镜像队列虽然提高了数据的安全性和队列的可用性，但也会因为消息复制过程中涉及的额外网络通信和磁盘I/O操作而增加延迟和降低性能。因此，在使用镜像队列时，需要根据实际的应用场景和性能要求权衡利弊。