RocketMQ总结
2021-02-02 22:58:55 52 举报AI智能生成
RocketMQ是一款分布式消息中间件，具有高效、可靠、解耦的特点。它采用发布/订阅模式，支持多种消息类型，如文本、二进制等。RocketMQ具有良好的扩展性，可以轻松实现消息的高可用和负载均衡。同时，它还提供了丰富的监控和管理功能，方便用户对系统进行运维。总之，RocketMQ是一个功能强大、性能优越的消息中间件，适用于各种规模的企业级应用。
作者其他创作
大纲/内容
常见问题
消息丢失
生产端
丢失场景
网络抖动导致发送msg失败
处理完业务后，还没来得及发送msg，生产端就down了
解决方案
发送超时可以进行几次重试，重试几次失败后大概率是消息服务不可用，需要将消息持久化，恢复后再顺序写会消息队列
可以使用RocketMQ的事务功能，先发送half到MQ，再处理业务，这时即使处理完业务还没发COMMIT给MQ也没关系，MQ会定时扫描处理half消息，回调生产端（该方案可以起到很好的效果，但是相应的性能会大幅下降，慎用）
队列
丢失场景
MQ只开启异步写入，还没持久化到磁盘down了
MQ主从方案中，主节点写完立即返回，主down发生主从切换导致msg丢失
解决方案
开启同步方案，flush到磁盘后再返回（对性能损失较大，慎用）
使用Dledger同步方案，集群中大部分从写成功后，主节点才返回成功
消费端
丢失场景
还没有真正处理完消息，就先回复SUCCESS，然后消费端down了
解决方案
真正处理完之后再返回SUCCESS
重复消费
产生原因
生产者网络波动导致多次发送消息
消费者消费后还没回复SUCCESS就挂掉了
解决方案
需要保证消费端幂等性
可以对每一个消息携带一个唯一id（可以是业务id，也可以用发号器生成）
可以依靠数据库唯一键解决，最保险方案，但是吞吐量最低
可以将唯一id存到redis中，无法保证原子性
消费失败
消费失败后可以通过返回RECONSUME_LATER进入重试队列
broker会给每个消费者组订阅的每个topic创建一个重试队列
重试超过16次后进入死信队列
重试间隔不同，并可以配置
可以单独订阅死信队列进行特殊处理
消息的顺序性问题
单个messageQueue可以保证顺序性
可以按照业务id散列到不同的messageQueue上，并且相同的id散列到同一个queue中
消费的时候不能使用RECONSUME_LATER重试队列机制，而需要返回SUSPEND_CURRENT_QUEUE_A_MOMENT状态暂停一会再消费
需要使用Orderly监听器防止多线程处理同一个queue中的消息
消息堆积问题
以下基于消费端依赖服务能抗住的情况下
如果MessageQueue足够的情况下，可以直接扩容消费者
如果MessageQueue不够，可以临时修改消费者将堆积的消息直接转发到扩容后的MessageQueue，然后扩张消费者
常用功能
事务
底层实现
发送Half消息的时候，先存入内部队列
发送Rollback就丢弃Half消息
发送commit就将消息发送到真正的队列
MQ会定时检测长时间处于Half的消息，然后回调业务方法询问如何处理
延时队列
设置DelayTimeLevel即可
默认延迟等级1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 30m 1h 2h
权限控制
可以有多个Account，每个Account设置密码和白名单IP，对queue生产消费权限进行控制
消息轨迹
三大作用
削峰
流量洪峰先推入消息队列，后端服务稳步消费
异步
对一些边边角角的功能采用异步，比如发送push等
解耦
消除一些对第三方系统的强依赖
与其他消息中间件对比
kafka
有高吞吐量几十万每秒，大量使用批处理思想，可能造成消息时延，功能相对单一，适合日志处理系统
rabbitmq
功能相对完善，包括延时队列等高级功能，但吞吐量较其他的mq低被人诟病几万到十几万每秒，语言也是erlang实现，不方便学习和修改源码
rocketmq
有高吞吐量几十万每秒，经过了阿里大流量的考验，可以做到不丢消息，高级功能也相对完善，使用Java语言实现，方便修改扩展
总结：kafka大量批处理，消息有时延但是吞吐量高；rocketmq及时发送消息，吞吐量没有kafka高
组件及重要概念
NameServer
可搭建集群，集群采用peer-to-peer，集群之间不相互通信
挂掉之后不影响集群的正常使用，只要有一个NameServer存活即可
Broker会将自己有哪些topic的哪些消息每30s发送心跳到集群中的每一个NameServer
NameServer每10s检查是否有Broker超过120s没有发送心跳了
生产者消费者每隔一段时间同步NameServer中的路由信息，生产者采用负载均衡算法将消息分发到不同的Broker上
Broker
主从结构
4.5前master挂掉后需要人工介入将slave提升为主节点
4.5后采用Dledger技术实现自动主从切换
Raft协议
每个Master必须至少有两个Slave
主从同步延迟问题
生产者生产消息需要在Master节点上
消费者消费消息可能在Master或Slave上
先去Master拉消息，Master根据负载情况和同步延迟状况建议消费者下次从哪个节点拉取数据
Topic
消息集合
一个topic可以分布到多个Broker上，实现高并发和海量数据的分布式存储
底层优化
mmap
减少了从内核到用户空间的拷贝过程
reactor io模型
WAL机制
0 条评论
下一页
