仿RabbiteMq实现简易消息队列正式篇(需求分析)

@TOC

      

目录

MQ的实现方法

RabbitMq中的相关概念

消息队列系统模块划分

总体划分

服务端模块

数据管理模块

虚拟机数据管理模块

交换机路由模块

消费者管理模块

信道(通信)管理模块

连接管理模块

服务端BrokerServer模块

客户端模块

消费者管理模块

信道管理客户端

连接管理模块

基于以上的三个模块封装实现:订阅客户端 / 发布客户端


        消息队列中间件是在分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削峰等等问题。实现高性能,高可用,可伸缩和最终一致性架构,是大型分布式系统不可缺少的中间件。目前常用的消息队列是RabbitMq, KafKa,ZeroMq,MetaMq等。

        我们是仿照RabbitMq实现简易的消息队列,就得先了解RabbitMq,RabbitMq是一种开源消息中间件,使用Erlang语言进行开发,实现了高级消息队列协议(AMQP)

MQ的实现方法

        MQ的实现方法有两种:AMQP和JMS

  1.         AMQP代表高级消息队列协议,是一个开放的应用层协议标准,用于设计面向消息的中间件。所以我们使用protobuf制作消息。
  2.         JMS即Java消息服务(JavaMessage Service)应用程序接口,是一个Java平台中关于面向消息中间件的API

        JMS是JavaEE规范中的一种,类比JDBC,很多消息中间件都实现了JMS规范,例如:ActiveMQ。RabbitMQ 官方没有提供JMS的实现包,但是开源社区有

RabbitMq中的相关概念

  •         Broker:接收和分发消息的应用,RabbitMQ Server就是Message Broker
  •         Virtual host: 出于多租户和安全因素设计的,把AMQP的基本组件划分到一个虚拟的分组中,类似网络中的namespace 概念。当多个不同的用户使用同一个RabbitMQ Server提供服务的时,可以划分成多个vhost,每个用户在自己的vhost创建exchange/queue等
  •         Connection:publisher/consumer和broker之间的TCP连接Channel:如果每一次访问RabbitMQ都建立一次Connection,在消息量大的时候建立TCP Connection的开销将是巨大的,效率也较低,Channel 是在connection 内部建立的逻辑连接,如果应用程序支持多线程,通常每个thread创建单独的channel 进行通信,AMQP method 包含了channel id 帮助客户端和 message broker识别channel, 所以channel 之间是完全隔离的,Channel 作为轻量级的Connection 极大减少了操作系统建立Tcp Connection 的开销
  •         Exchange:message 到达broker 的第一站, 根据分发规则,匹配查询表中的rounting_key,分发消息到queue中去,常见的类型是direct(直接匹配), topic(主题匹配), fanout(广播匹配)
  •         Queue:消息最终被送到这里等待consumer取走Binding:exchange 和 queue 之间的虚拟连接,bingding 中可以包含routing key.
  •         Binding信息被保存到exchange中的查询表中,用于message 的分发依据

接下来说一下我们仿RabbitMq需要实现的东西

消息队列系统模块划分

总体划分

  • 服务端
  • 发布客户端
  • 订阅客户端

服务端模块

数据管理模块

  • 交换机数据管理模块
  • 队列数据管理模块
  • 绑定数据管理模块
  • 消息数据管理模块

以上模块分别实现数据的管理以及持久化存储

虚拟机数据管理模块

  • 虚拟机其实就是交换机+队列+绑定+消息的整体逻辑单元
  • 因此虚拟的数据管理其实就是将以上四个模块的合并管理

交换机路由模块

  • 消息的发布,将一条新消息发布到交换机上,由交换机决定放入哪些队列
  • 而决定交给哪个队列,其中交换机类型起了很大作用(直接交换,广播交换,主题交换)
  • 直接交换和广播交换的思想较为简单,而主题交换设计到了一个规则匹配的流程
  • 而交换路由就是专门做匹配过程的

消费者管理模块

  • 消费者指的是订阅了一个队列消息的客户端,一旦这个队列有了消息就会推送给这个客户端
  • 在核心API中有个订阅消息的服务---这里的订阅不是订阅某条消息,而是订阅某个队列的消息
  • 当前主要实现消息推送功能,因此一旦有了消息,就要能找到消费者相关的信息(消费者对应的信道)

信道(通信)管理模块

  • 一个连接可能会对应有多个通信通道
  • 一旦某个客户端要关闭通信,关闭的不是连接,而是自己对应的通信通道,关闭信道我们就需要将客户端的订阅给取消

连接管理模块

  • 就是一个网络通信对应的连接
  • 因为当一个连接要关闭的时候,就应该把连接关联的通道全部关闭,因此也有数据至少要管理关联的信道

服务端BrokerServer模块

  • 这个模块是将以上所有模块的整合,整合成为一个服务端

客户端模块

消费者管理模块

一个订阅客户端,当订阅一个队列消息的时候,其就相当于创建了一个消费者

信道管理客户端

客户端的信道和服务端的信道是一一对应的,服务端信道提供的服务,客户端都有

相当于服务端向客户端提供服务,客户端为用户提供服务

连接管理模块

对于用户来说,所有的服务都是通过信道完成的,信道在用户的角度就是一个通信通道(而不是连接)

因此所有的请求就是通过信道来完成的

连接的管理就包含了客户端资源的整合

基于以上的三个模块封装实现:订阅客户端 / 发布客户端

订阅客户端:订阅一个队列的消息,收到推送过来的消息进行处理

发布客户端:向一个交换机发布消息。

  • 18
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
实现基于消息队列的生产者-消费者问题时,需要进行一定的需求分析,以确保系统能够满足用户的需求和期望。主要的需求分析包括以下几个方面: 1. 功能需求:需要明确系统需要实现的功能,包括生产者进程的数据生成、消费者进程的数据消费,以及消息队列的创建和销毁等。同时,还需要考虑生产者和消费者之间的同步和互斥问题,以及错误处理和异常情况的处理等。 2. 性能需求:需要明确系统的性能需求,包括消息队列的大小、生产者和消费者的并发数量、数据的生产和消费速度等。同时,还需要考虑系统的稳定性和可靠性,例如系统是否能够长时间稳定运行,是否能够在出现错误或异常时及时恢复等。 3. 可用性需求:需要明确系统的可用性需求,包括系统的可扩展性、可维护性、可升级性等。同时,还需要考虑系统的易用性和用户体验,例如系统是否易于配置和使用,是否提供了友好的用户界面等。 4. 安全需求:需要明确系统的安全需求,包括数据的安全性、系统的防护能力等。例如,在传输敏感数据时需要采用加密技术来保护数据的安全性。 5. 其他需求:根据实际情况,还需要考虑其他需求,例如系统的兼容性、可移植性等。 在需求分析的基础上,可以进一步进行系统设计和实现,以满足用户的需求和期望。需要注意的是,需求是不断变化的,因此在开发过程中需要不断地进行需求分析和调整,以确保系统能够适应不断变化的需求和环境。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值