MQ
2019-10-23 19:06:02 0 举报AI智能生成
登录查看完整内容
MQ
作者其他创作
大纲/内容
MQ
RocketMQ
特点
订阅与发布
消息顺序
全局顺序消息
含义
某个Topic下的所有消息都要保证顺序
适用场景
性能要求不高，消息严格按照FIFO原则发布和消费的场景
分区顺序消息
保证每一组消息被顺序消费即可
性能要求高
消息过滤
优点
减少了对于Consumer无用消息的网络传输
缺点
增加了Broker的负担、而且实现相对复杂
消息可靠性
影响消息可靠性的几种情况
能保证消息不丢，或者丢失少量数据（依赖刷盘方式是同步还是异步）
可恢复情况
1) Broker非正常关闭
2) Broker异常Crash
3) OS Crash
4) 机器掉电，但是能立即恢复供电情况
单点故障
情况
5) 机器无法开机
6) 磁盘设备损坏
解决方案
通过异步复制，可保证99%的消息不丢，但是仍然会有极少量的消息可能丢失
通过同步双写技术可以完全避免单点
至少一次
回溯消费
Broker在向Consumer投递成功消息后，消息仍然需要保留
RocketMQ支持按照时间回溯消费，时间维度精确到毫秒
场景
Consumer系统故障，恢复后需要重新消费1小时前的数据
事务消息
应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败
通过事务消息能达到分布式事务的最终一致
定时消息（延迟队列）
在第一次写入和调度写入真实topic时都会计数，因此发送数量、tps都会变高
消息重试
Consumer消费消息失败
由于消息本身的原因，例如反序列化失败，消息数据本身无法处理
由于依赖的下游应用服务不可用
RocketMQ会为每个消费组都设置一个重试队列
消息重投
生产者在发送消息时，同步消息失败会重投，异步消息有重试，oneway没有任何保证
问题
消息重复
消息重试策略
流量控制
生产者流控
方式
注意
生产者流控，不会尝试消息重投
消费者流控
消费者本地缓存消息数超过pullThresholdForQueue时
消费者本地缓存消息大小超过pullThresholdSizeForQueue时
消费者本地缓存消息跨度超过consumeConcurrentlyMaxSpan时
消费者流控的结果是降低拉取频率
死信队列
可以通过console对死信队列重发再次消费
核心组件
Name Server（名称服务器）
作用
Broker管理
路由信息管理
工作流程
每个 Broker 在启动的时候会到 NameServer 注册
Producer 在发送消息前会根据 Topic 到 NameServer 获取到 Broker 的路由信息
Consumer 也会定时获取 Topic 的路由信息
几乎无状态，可以横向扩展
节点之间相互之间无通信
Zookeeper
Broker（消息服务器）
负责消息的存储、投递和查询以及服务高可用保证
角色
Master
既可以写又可以读
Slave
不可以写只可以读
核心模块实现
Remoting Module
Client Manager
Store Service
HA Service
Index Service
集群部署
单 Master
一旦Broker重启或者宕机时，会导致整个服务不可用
不建议线上环境使用
多 Master
配置简单
单台机器宕机期间，该机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受影响
多 Master 多 Slave（同步双写）
数据与服务都无单点，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高
性能比异步复制模式略低，大约低 10%左右，发送单个消息的 RT会略高。目前主宕机后，备机不能自动切换为主机
多 Master多 Slave（异步复制）
消息实时性不会受影响
Master 宕机，磁盘损坏情况，会丢失少量消息
主流生产环境部署集群采用方案
Producer
同步
用于重要通知消息，例如重要通知邮件、营销短信
异步
用于可能链路耗时较长而对响应时间敏感的业务场景，例如用户视频上传后通知启动转码服务
单向
单向发送是指只负责发送消息而不等待服务器回应且没有回调函数触发
生产者组
Producer 通常发送一类消息并且发送逻辑一致
Consumer
Pull（拉取型消费者）
Push（推送型消费者）
注册消费监听器
监听器处触发后才开始消费消息
消费者组
设计
消息存储
消息存储整体架构
页缓存与内存映射
数据读写
数据读取：未命中PageCache，读取文件的同时，对相邻块数据文件预读取
数据写入：OS先写入Cache，随后异步刷盘
原理
ConsumeQueue逻辑消费队列存储的数据较少，并且是顺序读取
CommitLog消息存储的日志数据文件，读取消息内容时候会产生较多的随机访问读取，严重影响性能
MappedByteBuffer对文件进行读写操作
NIO中的FileChannel模型
消息刷盘
同步刷盘
适用于金融业务应用该模式较多
异步刷盘
降低了读写延迟，提高了MQ的性能和吞吐量
通信机制
Remoting通信类结构
协议设计与编解码
消息的通信方式和流程
同步(sync)
异步(async)
单向(oneway)
Reactor多线程设计
采用Netty组件作为底层通信库
同样也遵循了Reactor多线程模型
子主题
Consumer端订阅消息时做消息过滤
Tag过滤
SQL92的过滤
负载均衡
分类
发送消息时的负载均衡
订阅消息时的负载均衡
流程概要
整体流程
正常事务消息的发送及提交
(1) 发送消息（half（prepare）消息）
(2) 服务端响应消息写入结果
(3) 根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）
(4) 根据本地事务状态执行Commit或者Rollback（Commit操作生成消息索引，消息对消费者可见）
事务消息的补偿流程
(1) 对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查”
(2) Producer收到回查消息，检查回查消息对应的本地事务的状态
(3) 根据本地事务状态，重新Commit或者Rollback
RocketMQ事务消息设计
事务消息在一阶段对用户不可见
Commit和Rollback操作以及Op消息的引入
Op消息的存储和对应关系
Half消息的索引构建
如何处理二阶段失败的消息？
消息查询
按照MessageId查询消息
按照Message Key查询消息
架构设计
集群工作流程
启动NameServer
启动Broker
创建Topic，收发消息
Producer发送消息
Consumer消费消息
面试
在电商系统中，如何基于RocketMQ最终一致性事务落地
Rocket对分布式事务支持的底层实现原理
基于Rocket实现的最终一致性事务，如何抗住高并发交易场景
RocketMQ分布式事务功能的客户端让你来封装怎么封装？
RabbitMQ
核心概念
基本概念
交换器
路由键
队列
消息被拒绝
消息过期
队列达到最大长度
延迟队列
DLX和TTL模拟出延迟队列
应用场景
用户下单之后30分钟内支付
手机远程遥控家里的智能设备在指定的时间进行工作
生产者发送消息
消费者接收消息
存在的问题
消息丢失
ack+持久化
消息重复消费
1.数据库唯一约束(缺点：性能损失)
2.Redis
3.状态机：各种状态代表各种意思
特性
可靠性
发送方确认
持久化
灵活的路由
多语言客户端
异步处理
系统解耦
流量削峰
消费模式
简单模式
工作模式
消息发布和订阅
路由模式
主题模式
集群高可用
实战
Kafka
设计原理
0 条评论
回复 删除
下一页
