RocketMQ 笔记
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。