RocketMQ第四节（部署模式、监控面板等）

1：mq的部署模式

部署方式 | RocketMQ

参考官网。

单机模式：抗风险能力差，单机挂机没服务，单机硬盘损坏，丢失数据

多机（多master没有Slave副本）: 多个master采用RAID10磁盘，不会丢失数据，但是某一个master关闭，就获取不到该master的数据了。

多节点（集群）多副本模式-异步复制：多个master多个slave，主从之间异步复制

优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，同时Master宕机后，消费者仍然可以从Slave消费，而且此过程对应用透明，不需要人工干预，性能同多Master模式几乎一样

缺点：master宕机，可能丢失少量消息

多节点（集群）多副本模式-同步双写：多个master多个slave，主从之间同步复制

每个Master配置一个Slave，有多对Master-Slave，HA采用同步双写方式，即只有主备都写成功，才向应用返回成功，这种模式的优缺点如下：

优点：数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；

缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。

2：mq的监控面板

详细参见官网： 

去git下载RocketMQ Dashboard，本地maven 编译运行，修改端口号9000，java -jar 运行项目

RocketMQ Dashboard | RocketMQ

3：mq的知识点总结

mq的消息在服务器存放多久：保存3天

消费过程幂等：ocketMQ无法避免消息重复（Exactly-Once）所以如果业务对消费重复非常敏感，务必要在业务层面进行去重处理。可以借助关系数据库进行去重。首先需要确定消息的唯一键，可以是msgId，也可以是消息内容中的唯一标识字段，例如订单Id等。在消费之前判断唯一键是否在关系数据库中存在。如果不存在则插入，并消费，否则跳过。（实际过程要考虑原子性问题，判断是否存在可以尝试插入，如果报主键冲突，则插入失败，直接跳过）

mq发送状态：

消息发送成功或者失败要打印消息日志，务必要打印SendResult和key字段。send消息方法只要不抛异常，就代表发送成功。发送成功会有多个状态，在sendResult里定义。以下对每个状态进行说明：基本最佳实践 | RocketMQ

状态字段说明见官网地址：基本最佳实践 | RocketMQ