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