RocketMQ官方文档介绍了多种部署方式。我们抛开Local和Cluster集群的差异(Broker和Proxy是否部署在同一个进程),再去分析几种部署方式。
部署方式
单组节点单副本
只部署一个Broker,无灾备能力。所以不推荐生产使用。多组节点单副本
只部署2-3个Master,不部署Slave
问题来了,多个Master之间数据如何同步的?个人猜测是通过双写来实现,后面再去分析吧。
多组节点多副本-异步复制
多组节点多副本-同步双写
主备自动切换模式
单组节点单副本不推荐在生产环境使用。多组节点多副本模式,节点间数据同步存在两种方案,主要是在写入性能和数据同步时效性做取舍。
几种模式优缺点,官方文档已经给出部署方式。除了单组节点单副本模式,我们先一起来看一下这5种部署方式的具体配置参数。
非主备自动切换模式
本地启动双节点NameServer
1 | listenPort=10001 #修改默认端口号,避免在本地启动多个NameServer进程发生端口冲突 |
1 | listenPort=10002 #修改默认端口号,避免在本地启动多个NameServer进程发生端口冲突 |
在idea启动NameServer需要添加如下配置,上述修改端口的配置内容,放入-c指定的配置文件内
多组节点单副本
Broker-1的配置,作为Master节点
1 | brokerClusterName = local #所属集群名称 |
Broker-2和Broker-3的配置,也是作为Master节点进行部署,只需要修改brokerName和listenPort
多组节点多副本
通过组合使用如下brokerName和brokerId参数,就可以配置出想要的多组节点多副本的集群。角色为Master的Broker brokerId=0 slave则为>0,同一个副本的BrokerName必须相同。给出一个副本配置示例如下:
1 | brokerName = broker-a |
1 | brokerName = broker-a |
主备自动切换模式
NameServer需要增加如下配置,进而打开Controller主备自动切换模式。如下举个栗子
新增:
1 | enableControllerInNamesrv = true |
Broker的配置需要进行修改
新增:
1 | enableControllerMode = true #打开controller模式 |
删除:
1 | brokerId = |
是经过测试,发现这两个参数在此部署模式下是不需要的。brokerId自动下发,brokerRole 默认为SYNC_MASTER且不可以覆盖。
测试了关闭其中一个Master,SLAVE能自动被选举为Master,做到灾备自动切换。
总结
比较一下这几种部署模式,引用官网的描述:
单组节点单副本
不建议生产使用多组节点单副本
- 单个Master宕机或重启维护对应用读写无影响
- Master宕机期间,Broker上未被消费的消息不可被订阅,影响时效性
- Master宕机,磁盘损坏的情况下,异步刷盘丢失少量消息,同步刷盘一条不丢
- 性能最高
- 多组节点多副本-异步复制
- 单个Master宕机或重启维护对应用读写无影响
- Master宕机,可以继续从Slave消费,不需要人工干预,不影响时效性
- Master宕机,磁盘损坏情况下会丢失少量消息
- 性能和第2中模式几乎一样
4.多组节点多副本-同步双写
- 单个Master宕机或重启维护对应用读写无影响
- Master宕机,可以继续从Slave消费,不需要人工干预,不影响时效性
- Master宕机,磁盘损坏情况下不会丢失消息
- 性能比异步复制模式略低(大约低10%左右),发送单个消息的RT会略高
- 目前版本在主节点宕机后,备机不能自动切换为主机
5.主备自动切换模式
相比第4中模式,能够完成主备自动切换。
总结一下,个人认为模式3,5比较适合生产部署。3 侧重性能,5 侧重可靠性。4模式由于不具备灾备切换的能力所以不建议部署。除非在5的模式中如果Controller组件经常发生故障,那么考虑用4替换5的模式。