在读《RabbitMQ in Action》这本书，写的不错，通俗易懂。除了介绍RabbitMQ基本知识外，作者还介绍了RabbitMQ的业务场景、设计模式等，颇有收获。我在Google论坛里创建了一个RabbitMQ中文讨论组，欢迎点击这里订阅。
The minute you join one node to another to form a cluster something dramatically changes: not every node has a full copy of every queue. In a single node setup all of the information about a queue (metadata, state, and contents) is fully stored in that node (Figure 5.1). However, in a cluster when you create queues, the cluster only creates the full information about the queue (metadata, state, contents) on a single node in the cluster rather than on all of them (the cluster tries to evenly distribute queue creation amongst the nodes). The result is that only the “owner” node for a queue knows the full information about that queue. All of the “non-owner” nodes only know the queue’s metadata and a pointer to the node where the queue actually lives. So when a cluster node dies that node’s queues and associated bindings disappear. Consumers attached to those queues lose their subscriptions, and any new messages that would have matched that queue’s bindings become blackholed.
Not to worry though…we can have our consumers reconnect to the cluster and
recreate the queues right? Only if the queues weren’t originally marked durable. If the queues being recreated were marked as durable, redeclaring them from another node will get you a big ugly 404 NOT_FOUND error. This ensures messages in that queue on the failed node don’t disappear when you restore it to the cluster. The only way to get that specific queue name back into the cluster is to actually restore the failed node. However, if the queues your consumers try to recreate are not durable, the re-declarations will succeed and you’re ready to rebind them and keep trucking.
1. storage space: If every cluster node had a full copy of every queue, adding nodes wouldn’t give you more storage capacity. For example, if one node could store 1GB of messages, adding two more nodes would simply give you two more copies of the same 1GB of messages.
2. performance: Publishing messages would require replicating those messages to every cluster node. For durable messages that would require triggering disk activity on all nodes for every message. Your network and disk load would increase every time you added a node, keeping the performance of the cluster the same (or possibly worse).
Soon there will be an option to replicate the contents of a queue across more than one RabbitMQ cluster node. This will allow the contents of a queue to survive the failure of the queue’s primary owner node. The option will allow you to specify how many copies of a queues (replication factor) should exist in the cluster. So if you specified a replication factor of 2 on the avocado_receipts queue, 2 out of the 5 nodes in the cluster would get a copy of every message put into the avocado_receipts queue. Since the replication factor will be specified per queue, you can precisely balance durability versus performance within your cluster.