RocketMQ简单记录

公司现在用的消息队列是RabbitMQ，由于业务需要，计划对消息队列进行更换和升级，备选方案有RocketMQ和Pulsar。

之前自己学过Kafka，对消息队列有一些了解，这几天也学习了一些RocketMQ的基本概念和原理，做一个简单总结。

MQ
　　消息队列，一种先进先出的数据结构
作用
　　异步 提高系统的响应速度和吞吐量
　　解耦 减少服务之间的影响，提高系统整体的稳定性和可扩展性
　　削峰 以稳定的系统资源应对突发的流量冲击
缺点
　　系统可用性降低 一旦MQ宕机，对业务就会产生影响，需考虑高可用
　　系统复杂度提高 数据链路会变得更复杂
消息模式
　　集群模式&广播模式
消息存储
　　采用文件存储机制 即直接用磁盘文件来保存消息
　　存储优化三大利器 顺序写、异步刷盘、零拷贝
刷盘机制
　　同步刷盘 消息到达broker之后，通过缓存写入硬盘之后，再返回确认
　　　　速度较慢，吞吐量较小，保证消息不丢失
　　异步刷盘 消息到达broker之后，先存入缓存并返回确认，由单独的线程把缓存的消息存到硬盘
　　　　速度快，吞吐量大，有可能未写入硬盘而丢失消息
主从复制
　　同步双写 等master和slave都写入消息成功后才反馈给客户端写入成功的状态
　　　　如果master节点故障，slave上有全部的数据备份，容易恢复数据
　　　　但会增大数据写入的延迟，降低系统吞吐量
　　异步复制 只要master写入消息成功，就反馈给客户端写入成功的状态，再异步复制给slave节点
　　　　系统拥有较低的延迟和较高的吞吐量
　　　　但如果master节点故障，而有些数据没有完全复制，就会造成数据丢失
消息幂等
　　最多一次、最少一次、刚好一次
　　RocketMQ只保证最少一次
集群工作流程
　　1.启动NameServer，NameServer起来后监听端口，等待Broker、Producer、Consumer连上来，相当于一个路由控制中心。
　　2.Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer　　　　

　　　　集群中就有Topic跟Broker的映射关系。
　　3.收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic。
　　4.Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择

　　　　一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息。
　　5.Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息。
消息发送过程
　　选择一个queue来发消息，如果之前没有发送过消息，随机选择一个，如果发过消息，选择上一次发送记录的queue的下一个queue。判断所选择的的mq的broker，如果可用isAvailable，则看跟lastBrokerName（消息重发时就会有lastBrokerName的记录）是否一致或者lastBrokerName是否为null,如果满足条件，就选择这个mq，如果这个queue不符合条件，就再判断下下一个queue，直到遍历该topic的所有queue。
如果找不到符合上面要求的broker，那么就那么就放弃broker==lastBrokerName这个条件， 选择一个相对较好的broker来发送。

常见MQ比较

RocketMQ 架构

topic分片