Queue
Topic和Queue是1对多的关系，一个Topic下可以包含多个Queue，主要用于负载均衡。发送消息时，用户只指定Topic，Producer会根据Topic的路由信息选择具体发到哪个Queue上。Consumer订阅消息时，会根据负载均衡策略决定订阅哪些Queue的消息。
Queue不是真正存储Message的地方，真正存储Message的地方是在CommitLog
负载均衡
集群消费模式下，一个消费者集群多台机器共同消费一个topic的多个队列，一个队列只会被一个消费者消费。如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。
kafka,RocketMQ,RabbitMQ性能比较
一个Consumer Group下包含多个Consumer实例，可以是多台机器，也可以是多个进程，或者是一个进程的多个Consumer对象。一个Consumer Group下的多个Consumer以均摊方式消费消息，如果设置为广播方式，那么这个Consumer Group下的每个实例都消费全量数据。
rocketmq天然支持高可用，它可以支持多主多从的部署架构，这也是和kafka最大的区别之一
原因是RocketMQ中并没有master选举功能，所以通过配置多个master节点来保证rocketMQ的高可 用。和所有的集群角色定位一样，master节点负责接受事务请求、slave节点只负责接收读请求，并且 接收master同步过来的数据和slave保持一直。当master挂了以后，如果当前rocketmq是一主多从， 就意味着无法接受发送端的消息，但是消费者仍然能够继续消费。
所以配置多个主节点后，可以保证当其中一个master节点挂了，另外一个master节点仍然能够对外提 供消息发送服务。
当存在多个主节点时，一条消息只会发送到其中一个主节点，rocketmq对于多个master节点的消息发送，会做负载均衡，使得消息可以平衡的发送到多个master节点上。
一个消费者可以同时消费多个master节点上的消息，在下面这个架构图中，两个master节点恰好可以 平均分发到两个消费者上，如果此时只有一个消费者，那么这个消费者会消费两个master节点的数据。
由于每个master可以配置多个slave，所以如果其中一个master挂了，消息仍然可以被消费者从slave节 点消费到。可以完美的实现rocketmq消息的高可用
需要注意的是，在RocketMQ里面，1台机器只能要么是Master，要么是Slave。这个在初始的机器配置 里面，就定死了。不会像kafka那样存在master动态选举的功能。其中Master的broker id = 0，Slave 的broker id > 0。
