【阅读笔记】rocketmq 概念与架构（一）

介绍 rocketmq 框架与基本概念

1. 概念

1.1 namesrv(name server)

记录了 broker 集群信息，消息队列的信息以及 key-value 配置，见 RouteInfoManager 和 KVConfigManager。

可以由多个 namesrv 实例组成集群，但相互独立，没有信息交换。

1.2 broker

核心组件，负责存储所有的消息相关信息

支持主从模式
支持 master 写操作，只有当 master 读压力高于某个点（消息堆积），才会将读压力转给 salver
主从切换
4.5.0 版本之前无法做到主从切换。master 宕机，slaver
4.5.0 版本开始支持 master 宕机后可以切换到 slaver（4.5.0版本）
broker 提供了两种方式刷盘方式
- 同步刷盘：消息投放到 broker 之后，会在写入文件之后才返回成功
- 异步刷盘：消息投放 broker 成功后即可返回，同时启动另外的线程来存储消息
当发现broker压力较大时，可独立扩展 broker，只需要将 broker 地址注册到 namesrv 中即可
当其中一台broker机器宕机后，namesrv 不会顷刻间摘除心跳检测（多次无心跳检测才会摘除），而生产者/消费者亦会有轮询的方式，在数次请求无果后，会从可用列表中将该broker剔除掉，并将请求转发到另外的机器上

1.3 producer

生产者的作用就是将消息发送到 MQ，一个生产者发送业务应用系统生成的数据给Broker
RocketMQ提供多范式发送：同步，异步，一站式（OneWay）

1.4 producer group

生产者组，是将同样角色生产者的分组在一起。
同一生产组的不同生产者实例都会被 broker 告知提交或者回滚事务，以避免事务后源生产者崩溃

1.5 consumer

消费消息，从用户应用的角度看，有两种类型的消费者：

PullConsumer 要客户主动拉取消息
PushConsumer 推送消息（实际上还是用拉取实现）

1.6 Message Model 消息模型

有两种

Clustering：同一消费组中只有一个消费者消费消息
Broadcasting：消息将发往所有这个 topic 的订阅者，同一消费组中所有消费者都消费消息

1.7 consumer group

消费组，把同样角色的消费者分组到一起，即消费者组

如果消息模型是 Clustering ，那么同一消息，同一个 group 下只有一个 consumer 消费，
如果是 Broadcasting，同一消息，同一个 group 下所有 consumer 消费。

例如有一消息 A， 有 4 个 consumer c0~c3， 其中
  c0 c1 在 group1，消息模型是 clustering
  c2 c3 在 group2，消息模型是 broadcasting
那么消息 A 会由 c0 或 c1 中的一个和c2，c3消费

1.8 message order

当使用DefaultMQPushConsumer时，需要确定消费消息的方式

大专栏【阅读笔记】rocketmq 概念与架构（一）>

orderly：消费者将锁定每个MessageQueue，以确保每个消息按顺序被使用
concurrently：消费者将同时使用这些消息

1.9 cluster

broker 集群，同一组 namesrv 可以注册多组 broker，每组 broker 就是一个 broker cluster。

cluster 通过 broker 的配置文件配置 brokerClusterName 指定

1.10 topic

消息按 Topic 组织，一个 Topic 可以存在于多个 Broker，一个 Topic 有多个 Consume Queue

1.11 consume queue

表示一个逻辑上的消息队列，这个队列一个元素就代表一个消息，一个元素包含了消息在 Commit log中的逻辑位置

1.12 offset

说明一个消息在 consume queue 中的下标，由0开始

2. 部署

部署方式有

单 master 模式
多 master 模式
多 master 多 slave 异步复制模式
多 master 多 slave 同步双写模式

单 master

只有一个 master节点
优点：配置简单，方便部署
缺点：这种方式风险较大，一旦 broker 重启或者宕机时，会导致整个服务不可用，不建议线上环境使用

多 master 模式

一个集群无 slave，全是 master，例如 2 个 master 或者 3 个 master
优点：配置简单，单个 master 宕机或重启维护对应用无影响。在磁盘配置为 RAID10 时，即使机器宕机不可恢复情况下，由与 RAID10 磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高。
缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到受到影响
备注：当使用多 master 无slave 的集群搭建方式时，master 的 brokerRole 配置必须为 ASYNC_MASTER。如果配置为 SYNC_MASTER，则 producer 发送消息时，返回值的 SendStatus 会一直是 SLAVE_NOT_AVAILABLE

多 master 多 slave模式（异步复制）

每个 master 配置一个 slave，有多对 master-slave。采用异步复制方式，主备有短暂消息延迟，毫秒级。
优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，因为 master 宕机后，消费者仍然可以从 slave 消费，此过程对应用透明。不需要人工干预。性能同多 master 模式几乎一样。
缺点：Master 宕机，磁盘损坏情况，会丢失少量消息。

多 master 多 slave模式（同步双写）

每个 master 配置一个 slave，有多对 master-slave。采用同步双写方式，主备都写成功，向应用返回成功。
优点：数据与服务都无单点， master 宕机情况下，消息无延迟，服务可用性与数据可用性都非常高
缺点：性能比异步复制模式略低，大约低 10%左右，发送单个消息的 RT 会略高。

4.5.0 之前主宕机后，备机不能自动切换为主机，4.5.0 开始支持自动切换功能

异步复制和同步双写的区别是，同步双写在写入消息后，会等待 slave 写完成才返回到应用。