当前位置： 首页 > wzjs >正文

成都网站建设吧黄页网站推广服务

wzjs 2025/8/14 22:09:07
成都网站建设吧,黄页网站推广服务,市住房城乡建设管理委官方网站,php网站开发周期多长深入理解RocketMQ三高架构设计 高性能 顺序写磁盘 mmap 零拷贝异步刷盘 刷盘策略可配置轻量网络协议 长连接复用 高可用 主从复制机制、controller、dledger集群NameServer 多副本无状态客户端自动切换 Broker消息刷盘机制保障可靠性 高可扩展性 Broker 水平扩展Consu…

深入理解RocketMQ三高架构设计

高性能

  1. 顺序写磁盘 + mmap 零拷贝
  2. 异步刷盘 + 刷盘策略可配置
  3. 轻量网络协议 + 长连接复用

高可用

  1. 主从复制机制、controller、dledger集群
  2. NameServer 多副本无状态
  3. 客户端自动切换 Broker
  4. 消息刷盘机制保障可靠性

高可扩展性

  1. Broker 水平扩展
  2. Consumer 分组机制
  3. Topic/Queue 灵活路由
  4. 插件式架构设计

快速梳理RocketMQ客户端消息模型

三大核心角色

角色说明
Producer（生产者）发送消息到 Broker。支持同步、异步、单向三种发送方式。
Consumer（消费者）从 Broker 拉取消息进行消费。支持推模式（Push）和拉模式（Pull）。
NameServer提供路由发现服务。Producer/Consumer 都通过它查找 Broker 地址。

五大关键过程

  1. Producer 启动流程

    • 初始化 MQClientInstance；
    • 向 NameServer 拉取路由信息；
    • 建立与 Broker 的连接（Netty 长连接）；
    • 注册自身到 Topic 路由表。

  2. 消息发送流程
    生产者发送消息时：

    1. 从缓存中查找 Topic 对应的路由信息；
    2. 按策略选择一个队列（MessageQueue）；
    3. 通过 Netty 将消息发送到对应的 Broker；
    4. 根据配置选择：
      • 同步发送：等待返回确认；
      • 异步发送：注册回调函数；
      • 单向发送：不关心发送结果，适用于日志类数据。

  3. Consumer 启动流程
    消费者启动时：

    1. 初始化 MQClientInstance；
    2. 向 NameServer 拉取 Topic 路由；
    3. 与 Broker 建立连接；
    4. 根据消费模式（Push/Pull）拉取消息。

  4. 消息消费流程
    支持两种消费模式：

    模式说明
    Push 模式（默认）实际是 Broker 定期向 Consumer 主动推送拉取请求。
    Pull 模式Consumer 主动向 Broker 拉取消息。

    消费进度（offset）根据消费模式不同，也有两种：
    - 集群模式（Clustering） ：队列在多个消费者之间分摊；
    - 广播模式（Broadcasting） ：每个消费者都消费所有消息。

  5. 消费确认与重试机制

    • 消费成功：Consumer 会定期上报消费进度；
    • 消费失败：
      • 可自动重试（重投到 RETRY_TOPIC）；
      • 或转移到死信队列（DLQ）。

结合源码理解RocketMQ高性能实现细节

方面实现机制
消息写入顺序写磁盘 + MappedByteBuffer + 异步刷盘
消息读取消费队列（ConsumeQueue）+ 索引文件（IndexFile）
通信框架高性能 Netty + 自定义轻量协议
路由发现NameServer 提前缓存路由，无需频繁请求
网络效率长连接复用 + 请求压缩 + 线程池模型

全面思考RocketMQ的集群架构

RocketMQ 集群核心角色

角色描述
NameServer类似于注册中心，管理路由信息，支持无状态集群部署
Broker真正存储消息的服务。可部署为主从结构
Producer消息生产者，连接 NameServer 获取路由，再将消息发送至 Broker
Consumer消息消费者，从 Broker 拉取并消费消息

架构特性与设计思想

  1. NameServer（服务发现）
  • 无状态部署，支持多个节点；
  • Producer/Consumer 启动时从多个 NameServer 拉取 Broker 路由信息；
  • 路由信息是 Broker 主动注册 到 NameServer 的；
  • 支持故障容忍（某个 NameServer 掉线不影响整体）。
  1. Broker（核心）
    每个 Broker 有唯一标识（brokerName + brokerId）：
  • brokerId = 0：Master
  • brokerId > 0：Slave
    每个 Topic 可以配置多个队列分布在不同的 Broker 上。
    主从同步方式：
同步模式描述
ASYNC_MASTER异步同步（默认），写成功不等待 Slave，同步失败不影响写入
SYNC_MASTER同步刷盘，写消息时等待 Slave 确认，提高可靠性
SLAVE只做备份，不接收写请求，不参与消费
  1. Producer 工作机制
  • 从 NameServer 获取最新 Topic 路由；
  • 通过负载均衡策略选择队列（MessageQueue）；
  • 支持三种发送方式（同步/异步/单向）；
  • 自动感知路由变化，动态调整发送目标。
  1. Consumer 工作机制

  • 支持两种消费模式：

    • 集群模式（Clustering）：多个消费者共享消息
    • 广播模式（Broadcasting）：每个消费者都消费所有消息

  • 支持 Push 和 Pull 模式；

  • 消费进度保存在 Broker（默认）或本地（广播模式）；

  • 支持负载均衡重新分配队列（Rebalance）。

集群高可用与容错机制

机制实现
主从容灾Master 挂了，Slave 不自动转正，需人工或运维系统切换
NameServer 容灾Producer/Consumer 配置多个 NameServer，自动重试
消息重试机制消费失败支持自动重试、死信队列
刷盘策略保障数据同步刷盘 + SYNC_MASTER 可实现消息 0 丢失（牺牲部分性能）

生产环境RocketMQ常见问题处理思路

MQ消息零丢失方案总结

各种防止MQ消息丢失的方案，本质上都是以牺牲系统性能和吞吐量为代价的。这种资源消耗必然会导致集群整体效率的下降。在实际业务场景中，我们需要根据具体需求对这些安全方案进行权衡取舍。

  1. 生产者发送消息如何保证不丢失
    • 同步发送+多次尝试（降低吞吐）
    • 异步发送（增加生产者客户端负担）
    • 事务消息机制（多次网络请求）
  2. Broker写入数据如何保证不丢失
    • 同步刷盘（I/O负担）
    • Dledger集群（网络负担）
  3. 消费者消费消息如何不丢失
    • 同步处理消息，再提交offset（无法通过异步提高吞吐）
  4. 如果MQ服务全部挂了，如何保证不丢失
    • 增加临时的降级存储

MQ如何保证消息的顺序性

强调局部有序，而不是全局有序。

  1. Producer将一组有序的消息写入到同一个MessageQueue中。
  2. Consumer每次只有单个线程能从一个同一个TopicMessageQueue中拿取消息。
    在这里插入图片描述

MQ如何保证消息幂等性

  1. 生产者发送消息到服务端如何保持幂等
    Producer发送消息时，如果采用发送者确认的机制，Producer发送消息会等待Broker的响应。若未收到响应，Producer将自动重试发送。然而，这种情况也可能发生在消息已被处理成功处理但确认响应丢失的场景中，从而导致消息重复发送的问题。
    RocketMQ的处理方式，是会在发送消息时，给每条消息分配一个唯一的ID。

  2. 消费者消费消息如何保持幂等、
    RocketMQ官网明确做了回答：RocketMQ确保所有消息至少传递一次。在大多数情况下，消息不会重复。
    防止重复消费的关键在于确定一个可靠的唯一性标识。RocketMQ为每条消息自动分配了唯一的messageId，消费者可以通过获取这个messageId来实现去重。将已处理的messageId记录下来，就能有效判断消息是否重复消费。

    数据库的兜底方案则是在某些适用的场景下设置唯一键，插入重复的唯一键自然会报错回滚。

MQ如何快速处理积压的消息

  1. 消息积压会有哪些问题
    RocketMQ和Kafka都具备出色的消息积压处理能力，短期的消息堆积通常不会造成问题。然而需要警惕的是，若积压问题长期得不到解决，当日志文件过期时，系统会自动删除这些过期文件，导致其中未被消费的消息永久丢失。

  2. 怎么处理大量积压的消息

  • 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下，处理过后，再转回来。

http://www.dtcms.com/wzjs/347345.html

相关文章：

  • 温州企业网站建设要多少钱西安seo优化
  • 免费微信网站制作中国制造网网站类型
  • 下载别人网站的asp介绍网络营销
  • 万网如何做网站关键词指数查询
  • 做哪种网站流量上的快软服业营收破334亿
  • 餐饮网站界面找回原来的百度
  • 响应式网站 做搜索推广缺点关键词免费网站
  • 百度医疗网站建设关键词seo排名优化
  • 国际网站建设招标苏州关键词优化怎样
  • 做网站 数据标准湖南seo推广多少钱
  • 哪些香港网站不能访问公司百度官网优化
  • 游戏推广公司成都seo优化外包公司
  • 安溪县建设局网站营销宝
  • 济南做网站优化价格全国疫情排行榜
  • 网站建设工程师证书营销推广策划及渠道
  • 做网站就用建站之星辽宁seo推广
  • 室内设计师培训零基础百度seo优化系统
  • 网站建设开发公司百度推广售后客服电话
  • 小程序商城首页设计南京搜索引擎推广优化
  • 专门做日本旅行网站谷歌外贸网站推广
  • 台州优化官方网站口碑营销例子
  • wordpress页面后台登录百度搜索推广优化师工作内容
  • 富阳营销型网站建设免费网络营销软件
  • bootstrap框架制作网页网站文章优化技巧
  • 定制型网站建设推广潍坊seo推广
  • 网站建设方案书是啥最新国际新闻头条今日国际大事件
  • 山西网站推广公司seo项目是什么
  • 做网站加推广网站建设公司哪个好呀
  • 顺德网站建设公司查询网站收录
  • wordpress 清空回收站域名注册平台