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

avatar
作者
筋斗云
阅读量:0
@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模块

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

客户端模块

消费者管理模块

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

信道管理客户端

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

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

连接管理模块

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

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

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

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

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

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

    广告一刻

    为您即时展示最新活动产品广告消息,让您随时掌握产品活动新动态!