RocketMQ企业级部署方案

背景

公司很多业务在使用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

架构图

RocketMQ企业级部署方案

Topic管理

根据业务场景,我们把Topic创建到不同的Broker集群上,业务场景分两种情况:一种是需要保证消息不丢,但是对吞吐量要求不高,如订单相关信息,比如下图的TopicA就是用来存储订单相关的Topic,那么我们就把这个Topic创建到同步复制、同步刷盘这样角色的Broker集群上;另一种是对吞吐量要求特别高,但是消息容许发生少量丢失,如车辆上报的监控相关信息,比如下图的TopicB就是用来存储车辆上报的监控相关信息的Topic,那么我们就把这个Topic创建到异步复制、异步刷盘这样角色的Broker集群上

RocketMQ企业级部署方案

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章