• rocketMQ简单理解


    今天跟同事讨论了一下rocketMqd的相关实现和一些问题,觉得很有帮助 这里记录一下 先上一张画的图
    在这里插入图片描述

    名词解释

    1. broker1:其实就是部署rocketMq的节点,也就是部署rocketMq的服务器
    2. topic1:这个不用过多解释相信大家都知道
    3. writeQueueNum:创建tpoic的时候写队列的数量,举个例子,我们往topic发送了10条消息如果写队列定义了2那么就会创建q1和q2去均分这次的10条消息.
    4. readQueueNum:这个就是读队列 主要还是作为写队列和消费者实例的桥梁和负载作用
    5. q1,q2:这里的q1和q2就是我们在创建topic的时候定义的写队列数量
    6. group:消费者组一个消费者组里面应该都是创建处理同一个业务的实例
    7. cousumer:这个就是我们在代码里面创建订阅topic的实例

    消费流程

    :当provider往定义的topic里面写了10条数据后,topic在创建的时候会根据定义的writeQueuNum数量创建出上图的q1,q2…我们这里假设创建的是2 那么q1和q2里面各有5条数据,之后broker会将topic里面的数据广播到每一个group里面,group会根据根据创建topic时候定义的readQueueNum对写队列里面的数据进行划分之后发送给定义的消费者实例

    可能问题

    1. 消息丢失:之前生产环境我们遇到过消息丢失的情况,大概是因为定义的writeQueueNum大于一个group里面的readQueueNum,这时候多出来的写队列数据就没办法被读取,一直堆积
      在这里插入图片描述
    1. 订阅关系不一致: 现在有consumer1订阅topic1:tag1和consumer2订阅topic2:tag2 他们会依次注册到break,break里面有一个consumerTable用来记录不同消费组里面的消费信息其实就是一个map,这时候假设consumer1先注册
      map.put(“groupTest”,[“topic1”:{“tag”:“tag1”}]),consumer2再注册
      map.put(“groupTest”,[“topic1”:{“tag”:“tag2”}]),这时候break里面的groupTest的consumerInfo信息会被覆盖会导致先注册的consumer1里面的tag1消息丢失不会有任何消费,consumer2的消息只有分发到consumer2里面的才会被正常消费
      在这里插入图片描述

    深入了解

    • 我们在创建topic的时候会指定写队列和读队列,其实这里的读队列指的是consumer里面的队列数,写队列是commit log里面会对消息打标记和后面构建break的读队列使用完成流程见下图
      1、提供方发送消息
      2、消息到broker写入commit log里面
      3、通过commit log构建broker的读队列数量和是创建topic设置的写队列数量一样记录在commit log的起offset和消息长度
      4、group下面创建读队列数量是创建topic时候设置的读队列数量之后给到每一个consumer
      在这里插入图片描述

    注意事项

    • 如果想要全局顺序消费topic里面的数据的话那么我们就一定只能有一个consumer和一个queue否则没办法做到顺序消费,最多做到局部顺序消费 也就是每一个queue里面的消息顺序消费
  • 相关阅读:
    Spring Boot中Node.js的下载与Vue CLI在IDEA中的部署及使用(图文解释 简单易懂)
    swift 页面跳转
    React 高频面试题1(答案和题目都是根据讯飞星火写的)
    主打国产算力 广州市通用人工智能公共算力中心项目签约
    WebRTC 的多媒体音视频帧传输协议
    如何安装西门子PLC设备
    近三年各领域数字孪生相关政策汇编(可下载)
    git基本概念和原理:工作区--暂存库--本地仓库--远端git仓库之间的交互
    在vscode 中使用npm的问题
    『德不孤』Pytest框架 — 8、Pytest断言
  • 原文地址:https://blog.csdn.net/weixin_47733858/article/details/127098585