RocketMQ(二)--集群模式、物理部署结构、逻辑部署结构

集群模式

• 集群模式包括
  • 单机模式
  • Master-Slave模式
  • 双Master模式
  • 双主双从模式（异步复制和同步双写）
  • 多主多从模式

双主模式

• 基本概念：一个集群没有Slave，全部是Master。
• 优点：配置简单，单个Master宕机或者重启维护对应用没有影响，即使机器宕机不能恢复的情况下，由于RAID10磁盘的可靠，之前保存的消息也不会丢失（异步刷屏丢失少量消息，同步刷屏不会丢失），性能最高
• 缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前，不可订阅，消费者无法消费消息，消息的实时性会受到影响，但是在实际中，通过监控工具会很快的检测到异常，对MQ进行重启，实时性会提高。工作中，对于实时性要求高的系统不建议此设置。

示意图

多Master 多Slave模式 异步复制

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

示意图

• 当producer产生消息发送给Master1时，当Master1保存成功后，就返回给Producer成功的应答，但是此时Slave1并没有记录消息，此时采用异步的方法将消息同步到Slave1上。
  

多Master 多Slave模式 同步双写

• 概念：每个Master配置一个Slave，有多对Master-Slave，HA采用同步双写模式，主备都写成功了，向应用返回成功。
• 优点： 数据与服务无单电，Master宕机情况下，消息无延迟，服务可用性与数据可用性非常高
• 缺点：性能比异步复制模式地，大约10%左右，发送单个消息的RT会略高，目前主宕机后，备机不能自动切换成主机，后续支持自动切换功能。

示意图

RocketMQ物理部署结构

1. 每个broker节点都会与Name Server（负责Topic的暴露和发现）创建长连接，定期将broker中的topic注册到Name Server上
2. producer或者consumer，创建消息或者消费消息时，会向Name Server中获取需要的Topic的主题信息，包括，在哪个broker上，获取到消息后，然后与broker建立长连接，进行生产消息或者消费消息。
   

RocketMQ 逻辑部署结构

• 流程说明
  1. Producer注册自己的消息到对应的主题
  2. Consumer监听主题，获取到最新的消息
     
• 概念
  • Producer Group：用来表示一个发送消息应用，一个Producer Group下包含多个Producer实例，可以是多台机器，也可以是一台机器的多个进程，或者一个进程的多个Producer对象，一个Producer Group可以发送多个Topic消息，Producer Group作用如下：
    • 标识一类Producer
    • 可以通过运维工具查询这个发送消息应用下有多个Producer实例
    • 发送分布式事务消息时，如果Producer中途意外宕机，Producer会主动回调Producer Group内的任意一台机器来确认事务状态。
  • Consumer Group
    • 用来表示一个消费消息应用，一个Consumer Group下包含多个Consumer实例，可以是多台机器，也可以是多个进程，或者是一个进程的多个Consumer对象，一个Consumer Group下的多个Consumer以均摊方式消费消息，如果设置为广播方式，那么这个Consumer Group下的每个实例都会消费全量数据。