十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
公司很多业务在使用RocketMQ,前期业务量小,没啥问题,也没有太关注集群的可用性这块,所以全公司的业务公用一个集群,随之公司的业务量增加,业务对RocketMQ集群依赖越来越重,开始思考集群拆分,风险分摊;开始想的是按部门划分,一个部门一个集群,但是部门之间有通过RocketMQ做数据交互的需求,这样会带来的问题是一个应用需要连接两个RocketMQ集群,需要业务方改代码,在开发人不需要改代码的情况下,如何能做到集群无单点、风险分摊,集群未来可以水平扩容呢,我们的方案如下:
创新互联-专业网站定制、快速模板网站建设、高性价比安阳县网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式安阳县网站制作公司更省心,省钱,快速模板网站建设找我们,业务覆盖安阳县地区。费用合理售后完善,10余年实体公司更值得信赖。
整个集群分三层,分别是应用接入层、Nameserver集群和Broker集群,下面分别对这三部分说明:
接入层其实就是应用连接MQ集群的地址,目前生产环境我们是直接连接了nameserver的IP地址,如果nameserver扩容或者换服务器了,大家需要修改配置重启服务更新新的nameserver地址,虽然这个事情的几率比较低,但是如果发生了还是比较麻烦,所有我们新的接入方案是负载均衡+域名,大家在程序里面配置连接MQ的地址为:BLB:9876,nameserver1.chj.cloud:9876,nameserver2.chj.cloud:9876,这样同时做了负载均衡和域名的双保险,如果负载均衡器故障,应用会重试去连域名
Nameserver本身是无状态的,并且基本没有压力,所以我们计划前期先部署两台;后续需要扩容的时候,需要依次重启broker,让broker也注册到新的nameserver上
Broker负责消息的存储,Broker的部署有多种模式,我们会根据业务需求,部署两种架构:多master多slave(同步复制、同步刷盘)、多master多slave(异步复制、异步刷盘);集群也可以横向扩容
Broker命名规范:奇数为异步复制+异步刷盘类型,偶数为同步复制+同步刷盘类型,如:broker-1,broker-2
根据业务场景,我们把Topic创建到不同的Broker集群上,业务场景分两种情况:一种是需要保证消息不丢,但是对吞吐量要求不高,如订单相关信息,比如下图的TopicA就是用来存储订单相关的Topic,那么我们就把这个Topic创建到同步复制、同步刷盘这样角色的Broker集群上;另一种是对吞吐量要求特别高,但是消息容许发生少量丢失,如车辆上报的监控相关信息,比如下图的TopicB就是用来存储车辆上报的监控相关信息的Topic,那么我们就把这个Topic创建到异步复制、异步刷盘这样角色的Broker集群上