本文探讨RocketMQ的高可用方案，包括Master/Slave模式、Dledger的Raft选举以及阿里和网易云音乐的HA方案。RocketMQ的Name Server天然高可用，Broker的高可用涉及主从复制和故障切换策略。Dledger通过raft协议保证数据一致性，而HAController和Nydus方案则通过组件控制状态机切换实现高可用。
本文由作者授权网易云发布，未经许可，请勿转载。
作者：李海燕，网易杭州研究院云计算技术部工程师
一、前言
RocketMQ是阿里捐赠给Apache并于2018年作为顶级项目孵化的分布式消息引擎，目前已经加入CNCF成为云原生核心消息中间件。国内厂商如美团，滴滴、爱奇艺、顺丰和民生银行等都在使用，网易集团内部云音乐和严选也在使用RocketMQ，并对周边功能进行了扩展定制。
鉴于RocketMQ的广泛使用，网易杭州研究院云中间件团队将基于轻舟中间件平台，通过和网易云音乐、严选共建使RocketMQ上云，简化RocketMQ部署和运维工作，实现集团内RocketMQ标准化。
本文主要分两部分：调研RocketMQ的集群高可用方案
云原生时代RocketMQ on K8s集群设计概要
二、基本概念
2.1 RocketMQ基本概念
RocketMQ架构如下图所示(以经典Master/Slave模式为例):
核心概念：Name Server：无状态集群(数据可能暂时不一致)，提供命名服务，更新和发现Topic-Broker服务。
Broker：负责存储、转发消息，分为Master和Slave。Broker启动后需要将自己的Topic和Group等路由信息注册至所有Name Server；随后每隔30s定期向Name Server上报路由信息。
生产者：与 Name Server 任一节点建立长链接，定期从 Name Server 读取路由信息，并与提供 Topic 服务的对应 Master Broker 建立长链接。
消费者：与 Name Server 任一节点建立长链接，定期从 Name Server 拉取路由信息，并与提供 Topic 服务的 Master Broker、Slave Broker 建立长连接。Consumer 既可以从 Master Broker 订阅消息，也可以从 Slave Broker 订阅消息，订阅规则由 Broker 配置决定。支持Pull和Push两种模型。
Topic：表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。
支持的features：普通消息收发
普通顺序消息(Normal Ordered Message)：普通顺序消费模式下，消费者通过同一个消费队列收到的消息是有顺序的，不同消息队列收到的消息则可能是无顺序的。
严格顺序消息(Strictly Ordered Message)：严格顺序
最低0.47元/天 解锁文章
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
