背景
公司很多业务在使用RocketMQ，前期业务量小，没啥问题，也没有太关注集群的可用性这块，所以全公司的业务公用一个集群，随之公司的业务量增加，业务对RocketMQ集群依赖越来越重，开始思考集群拆分，风险分摊；开始想的是按部门划分，一个部门一个集群，但是部门之间有通过RocketMQ做数据交互的需求，这样会带来的问题是一个应用需要连接两个RocketMQ集群，需要业务方改代码，在开发人不需要改代码的情况下，如何能做到集群无单点、风险分摊，集群未来可以水平扩容呢，我们的方案如下：
集群部署规划
整个集群分三层，分别是应用接入层、Nameserver集群和Broker集群，下面分别对这三部分说明：
接入层
接入层其实就是应用连接MQ集群的地址，目前生产环境我们是直接连接了nameserver的IP地址，如果nameserver扩容或者换服务器了，大家需要修改配置重启服务更新新的nameserver地址，虽然这个事情的机率比较低，但是如果发生了还是比较麻烦，所有我们新的接入方案是负载均衡+域名，大家在程序里面配置连接MQ的地址为：BLB:9876,nameserver1.chj.cloud:9876,nameserver2.chj.cloud:9876，这样同时做了负载均衡和域名的双保险，如果负载均衡器故障，应用会重试去连域名
Nameserver集群
Nameserver本身是无状态的，并且基本没有压力，所以我们计划前期先部署两台；后续需要扩容的时候，需要依次重启broker，让broker也注册到新的nameserver上
Broker集群
Broker负责消息的存储，Broker的部署有多种模式，我们会根据业务需求，部署两种架构：多master多slave（同步复制、同步刷盘）、多master多slave（异步复制、异步刷盘）；集群也可以横向扩容
Broker命名规范：奇数为异步复制+异步刷盘类型，偶数为同步复制+同步刷盘类型，如：broker-1，broker-2
架构图
Topic管理
根据业务场景，我们把Topic创建到不同的Broker集群上，业务场景分两种情况：一种是需要保证消息不丢，但是对吞吐量要求不高，如订单相关信息，比如下图的TopicA就是用来存储订单相关的Topic，那么我们就把这个Topic创建到同步复制、同步刷盘这样角色的Broker集群上；另一种是对吞吐量要求特别高，但是消息容许发生少量丢失，如车辆上报的监控相关信息，比如下图的TopicB就是用来存储车辆上报的监控相关信息的Topic，那么我们就把这个Topic创建到异步复制、异步刷盘这样角色的Broker集群上
