消息队列的技术选型

消息队列企业级应用场景分析

1. 消息队列：在消息的传输过程中保存消息的容器，生产者和消费者不直接通讯，依靠队列保证消息的可靠性，避免了系统间的相互影响。
2. 消息队列主要角色：服务端、客户端<生产者、订阅者>
3. 消息队列主要作用：业务解耦、异步调用、流量削峰
   • 解耦优点：提升系统稳定性、通过广播消息避免多次调用、对于无需关注调用结果的场景可以通过消息队列异步处理

消息队列选型对比分析，为什么使用RocketMQ

功能对比	成熟度	顺序消息	延时消息	事务消息	消息过滤	消息查询	消费失败重试	批量发送
kafka	日志领域	支持	不支持	不支持	支持	不支持	不支持	支持
RabbitMQ	成熟	支持	不支持	不支持	不支持	不支持	支持	不支持
RocketMQ	成熟	支持	特定LV	支持	支持	支持	支持	不支持

实用性	部署方式	集群管理	选主方式	主从切换	数据可靠性	性能	可用性	堆积能力
kafka	集群	Zookeeper	自动选举	自动切换	高	非常高	分布式、主从	非常好
RabbitMQ	集群	Erlang天然支持	最早加入的节点	自动切换	高	中	主从	一般
RocketMQ	集群	Name Server	不支持	不支持自动切换	高	高	分布式、主从	非常好

• Kafka：系统间的数据流通道
• RabbitMQ：可靠消息传输
• RocketMQ：高性能可靠消息传输

MQ高可用及高扩展解决方案剖析

1. RocketMQ 架构
   • Broker主从部署，自身信息注册在 NameServer 中
   • Client 从 NameServer 中获取 Broker 信息
   • NameServer 节点相互独立，无数据交互
2. 可靠性分析
   • 同步刷盘：性能低，可靠性高
   • 异步刷盘：性能高，可靠性低

• 异步复制
• 同步双写

3. 可用性分析
   • 主从模式 Master 宕机：Broker 可读不可写
   • 集群搭建方式
     • 单 Master 模式
     • 多 Master 模式
     • 多 Maste r多 Slave 模式-异步复制
     • 多 Master 多 Slave 模式-同步双写

MQ服务注册与发现原理剖析

1. 注册中心—NameServer设计
   • 服务注册：Broker 注册自身信息
   • 服务发现：Procucer/Consumer 寻找 Broker 信息
2. 注册中心—NameServer设计优点
   • 设计目标简单高效
   • 高可用方案：相互独立多个节点
   • 数据存储设计
     • Cluster-<Broker1，Broker2>
     • Broker1 -<MasterIP，SlaveIP>
     • Topic-<Broker1，Broker2>
     • Broker-heartbeat