建立网站的主要步骤,如何免费注册自己的网站,网页设计模板免费网站,360企业网站认证深入理解RocketMQ三高架构设计
高性能
顺序写磁盘 mmap 零拷贝异步刷盘 刷盘策略可配置轻量网络协议 长连接复用
高可用
主从复制机制、controller、dledger集群NameServer 多副本无状态客户端自动切换 Broker消息刷盘机制保障可靠性
高可扩展性
Broker 水平扩展Consu…深入理解RocketMQ三高架构设计
高性能
顺序写磁盘 mmap 零拷贝异步刷盘 刷盘策略可配置轻量网络协议 长连接复用
高可用
主从复制机制、controller、dledger集群NameServer 多副本无状态客户端自动切换 Broker消息刷盘机制保障可靠性
高可扩展性
Broker 水平扩展Consumer 分组机制Topic/Queue 灵活路由插件式架构设计
快速梳理RocketMQ客户端消息模型
三大核心角色
角色说明Producer生产者发送消息到 Broker。支持同步、异步、单向三种发送方式。Consumer消费者从 Broker 拉取消息进行消费。支持推模式Push和拉模式Pull。NameServer提供路由发现服务。Producer/Consumer 都通过它查找 Broker 地址。
五大关键过程 Producer 启动流程 初始化 MQClientInstance向 NameServer 拉取路由信息建立与 Broker 的连接Netty 长连接注册自身到 Topic 路由表。 消息发送流程 生产者发送消息时 从缓存中查找 Topic 对应的路由信息按策略选择一个队列MessageQueue通过 Netty 将消息发送到对应的 Broker根据配置选择 同步发送等待返回确认异步发送注册回调函数单向发送不关心发送结果适用于日志类数据。 Consumer 启动流程 消费者启动时 初始化 MQClientInstance向 NameServer 拉取 Topic 路由与 Broker 建立连接根据消费模式Push/Pull拉取消息。 消息消费流程 支持两种消费模式 模式说明Push 模式默认实际是 Broker 定期向 Consumer 主动推送拉取请求。Pull 模式Consumer 主动向 Broker 拉取消息。消费进度offset根据消费模式不同也有两种 - 集群模式Clustering 队列在多个消费者之间分摊 - 广播模式Broadcasting 每个消费者都消费所有消息。 消费确认与重试机制 消费成功Consumer 会定期上报消费进度消费失败 可自动重试重投到 RETRY_TOPIC或转移到死信队列DLQ。
结合源码理解RocketMQ高性能实现细节
方面实现机制消息写入顺序写磁盘 MappedByteBuffer 异步刷盘消息读取消费队列ConsumeQueue 索引文件IndexFile通信框架高性能 Netty 自定义轻量协议路由发现NameServer 提前缓存路由无需频繁请求网络效率长连接复用 请求压缩 线程池模型
全面思考RocketMQ的集群架构
RocketMQ 集群核心角色
角色描述NameServer类似于注册中心管理路由信息支持无状态集群部署Broker真正存储消息的服务。可部署为主从结构Producer消息生产者连接 NameServer 获取路由再将消息发送至 BrokerConsumer消息消费者从 Broker 拉取并消费消息
架构特性与设计思想
NameServer服务发现
无状态部署支持多个节点Producer/Consumer 启动时从多个 NameServer 拉取 Broker 路由信息路由信息是 Broker 主动注册 到 NameServer 的支持故障容忍某个 NameServer 掉线不影响整体。
Broker核心 每个 Broker 有唯一标识brokerName brokerId
brokerId 0MasterbrokerId 0Slave 每个 Topic 可以配置多个队列分布在不同的 Broker 上。 主从同步方式
同步模式描述ASYNC_MASTER异步同步默认写成功不等待 Slave同步失败不影响写入SYNC_MASTER同步刷盘写消息时等待 Slave 确认提高可靠性SLAVE只做备份不接收写请求不参与消费
Producer 工作机制
从 NameServer 获取最新 Topic 路由通过负载均衡策略选择队列MessageQueue支持三种发送方式同步/异步/单向自动感知路由变化动态调整发送目标。
Consumer 工作机制 支持两种消费模式 集群模式Clustering多个消费者共享消息广播模式Broadcasting每个消费者都消费所有消息 支持 Push 和 Pull 模式 消费进度保存在 Broker默认或本地广播模式 支持负载均衡重新分配队列Rebalance。
集群高可用与容错机制
机制实现主从容灾Master 挂了Slave 不自动转正需人工或运维系统切换NameServer 容灾Producer/Consumer 配置多个 NameServer自动重试消息重试机制消费失败支持自动重试、死信队列刷盘策略保障数据同步刷盘 SYNC_MASTER 可实现消息 0 丢失牺牲部分性能
生产环境RocketMQ常见问题处理思路
MQ消息零丢失方案总结
各种防止MQ消息丢失的方案本质上都是以牺牲系统性能和吞吐量为代价的。这种资源消耗必然会导致集群整体效率的下降。在实际业务场景中我们需要根据具体需求对这些安全方案进行权衡取舍。
生产者发送消息如何保证不丢失 同步发送多次尝试降低吞吐异步发送增加生产者客户端负担事务消息机制多次网络请求 Broker写入数据如何保证不丢失 同步刷盘I/O负担Dledger集群网络负担 消费者消费消息如何不丢失 同步处理消息再提交offset无法通过异步提高吞吐 如果MQ服务全部挂了如何保证不丢失 增加临时的降级存储
MQ如何保证消息的顺序性
强调局部有序而不是全局有序。
Producer将一组有序的消息写入到同一个MessageQueue中。Consumer每次只有单个线程能从一个同一个TopicMessageQueue中拿取消息。
MQ如何保证消息幂等性 生产者发送消息到服务端如何保持幂等 Producer发送消息时如果采用发送者确认的机制Producer发送消息会等待Broker的响应。若未收到响应Producer将自动重试发送。然而这种情况也可能发生在消息已被处理成功处理但确认响应丢失的场景中从而导致消息重复发送的问题。 RocketMQ的处理方式是会在发送消息时给每条消息分配一个唯一的ID。 消费者消费消息如何保持幂等、 RocketMQ官网明确做了回答RocketMQ确保所有消息至少传递一次。在大多数情况下消息不会重复。 防止重复消费的关键在于确定一个可靠的唯一性标识。RocketMQ为每条消息自动分配了唯一的messageId消费者可以通过获取这个messageId来实现去重。将已处理的messageId记录下来就能有效判断消息是否重复消费。 数据库的兜底方案则是在某些适用的场景下设置唯一键插入重复的唯一键自然会报错回滚。
MQ如何快速处理积压的消息 消息积压会有哪些问题 RocketMQ和Kafka都具备出色的消息积压处理能力短期的消息堆积通常不会造成问题。然而需要警惕的是若积压问题长期得不到解决当日志文件过期时系统会自动删除这些过期文件导致其中未被消费的消息永久丢失。 怎么处理大量积压的消息 RabbitMQ 如果是Classic Queue经典对列那么针对同一个Queue的多个消费者是按照Work Queue的模式在多个Consuemr之间依次分配消息的。所以这时如果Consumer消费能力不够那么直接加更多的Consumer实例就可以了。这里需要注意下的是如果各个Consumer实例他们的运行环境或者是处理消息的速度有差别。那么可以优化一下每个Consumer的比重(Qos属性)从而尽量大的发挥Consumer实例的性能。 RocketMQ和Kafka 因为同一个消费者组下的多个Cosumer需要和对应Topic下的MessageQueue建立对应关系而一个MessageQueue最多只能被一个Consumer消费因此增加的Consumer实例最多也只能和Topic下的MessageQueue个数相同。如果此时再继续增加Consumer的实例那么就会有些Consumer实例是没有MessageQueue去消费的因此也就没有用了。 如果Topic下的MessageQueue配置本来就不够多的话那就无法一直增加Consumer节点个数了。 如果要快速处理积压的消息可以创建一个新的Topic配置足够多的MessageQueue。然后把Consumer实例的Topic转向新的Topic并紧急上线一组新的消费者只负责消费旧Topic中的消息并转存到新的Topic中。这个速度明显会比普通Consumer处理业务逻辑要快很多。然后在新的Topic上就可以通过添加消费者个数来提高消费速度了。之后再根据情况考虑是否要恢复成正常情况。 类似固定级别的延迟消息机制把消息临时转到一个系统内部的Topic下处理过后再转回来。
