超清晰的RocketMQ部署双Master模式

工作遇到，在此记录。

RocketMQ官网，里面有官方的部署API介绍，但个人感觉不是很全。

官方下载地址http://rocketmq.apache.org/release_notes/release-notes-4.1.0-incubating/

最好下载红框内的，下载上面源码的还需要编译。所以。。。简单起见嘛~

RocketMQ简单介绍：

  RocketMQ 是阿里巴巴在2012年开源的分布式消息中间件，目前已经捐赠给 Apache 软件基金会，并于2017年9月25日成为 Apache 的顶级项目。经历过淘宝“双十一”的洗礼，RocketMQ以其高性能、低延迟和高可靠，在功能和性能上据说是远超ActiveMQ等，逐渐跻身成为主流消息处理队列。其他的介绍这里就不多说了，直接进入正题。

  

    

 

这里从RocketMQ使用手册中截取了两张我认为比较好理解的图。

生产组(Producer集群)：用于消息的发送

消费组(Consumer集群)：用于消息的订阅处理

如图，Broker集群 分为Master 和 Slave 模式 ，这里Slave不可写，但可读，类似于MySql主备方式。

接下来，详细介绍不同的集群方式：

     单个Master

      这种方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用。（目前项目中用的这种方式，所以更改为多Master模式）

     多Master模式

       一个集群无Slave，全是Master。

      优点：配置简单，单个Master宕机或者重启维护对应用无影响，在磁盘配置为RAID10时，即便机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢，性能最高。

      缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。

      启动方式： 1.先启动NameServer 

                         2.在机器A，启动第一个Master

                         3.在机器B，启动第二个Master 

     多Master多Slave模式，异步复制

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