点击链接阅读原文，获取更多技术内容：

【资料图】

本篇文章首先介绍MetaQ消息队列，然后介绍了作者对MetaQ和Kafka这两个消息队列的理解。

作者 | 林建忠(恶来)

来源 | 阿里开发者公众号

消息队列

消息队列是一个用于接收消息、存储消息并且转发消息的中间件，主要是用于解决如下的场景：

异步：A服务做了一些事情，异步发送消息给服务B； 削峰/限流：类似一个蓄水池，比如说有些服务（例如电商服务的秒杀），请求量很高，服务端处理不过来，那么请求先放到消息队列里面，然后服务端按照自己的能力来消费处理； 解耦：应用之间减少代码的耦合，使得应用的部署更加灵活；

消息队列有几个重要的概念模型：消息、队列、生产者、消费者，下面将介绍这几个基本概念：

消息：消息是消息队列中的最基本概念，其本质上是一段数据，能够被多个应用程序所理解，是应用程序之间传递信息的载体，消息一般是由消息描述符和消息体组成； 队列：队列是一种先进先出的数据结构，队列是由队列头部和队列尾部组成，一般需要在队列尾部进行插入，在队列头部进行删除； 生产者：生产者主要是用来产生消息，并将消息放入队列的尾部； 消费者：消费者主要是用来消费队列头部的消息；

MetaQ介绍

目前常用的消息中间件有kafka、RocketMQ和ActiveMQ等；今天我们将介绍MetaQ，MetaQ也是消息队列中间件，属于阿里内部的RocketMQ，下面将介绍MetaQ的相关概念：

NameServer

命名服务，内部维护了topic和broker之间的对应关系，并且和所有broker保持心跳连接，在producer和consumer需要发布或者消费消息的时候，向nameserver发出请求来获取连接的broker的信息；NameServer可以部署多个，每个之间互相独立，其他角色同时向多个NameServer机器上报状态信息，从而达到热备份的目的；

NameServer类似kafka中zookeeper的角色，那为什么不直接采用ZooKeeper角色呢，那是因为ZooKeeper有自动选举Master的功能，MetaQ的架构设计上决定了它不需要进行Master选举，而只需要使用一个轻量级的元数据服务器就可以了。

Broker

MetaQ的服务器，负责消息的中转、存储和转发，Broker可以分为Master和Slave，一个Master可以对接多个Slave，但是一个Slave只能对接一个Master，Master与Slave之间可以通过指定相同的BrokerName，不同的BrokerId来定义，BrokerId为0表示Master，不为0的表示Slave。

Master可以部署多个，每个Broker和NameServer集群中的所有节点建立长连接，定期的注册Topic信息到所有的NameServer上。消息会发送到Master上，一旦Master上面记录成功，就直接返回成功，不用等待slave上面是否记录成功，slave会定时的去获取消息记录，所以slave和master上面会有一些时间差异；slave可以作为consumer的服务提供者，意思就是如果写入必须通过master，消费的时候则可以直接从slave上面获取。Master和slave都需要注册到nameserver上面，一旦master无法使用，客户端可以使用与之对应的slave。每个Broker与Name Server集群中的所有节点建立长连接，定时(每隔30s)注册Topic信息到所有Name Server。Name Server定时(每隔10s)扫描所有存活broker的连接，如果Name Server超过2分钟没有收到心跳，则Name Server断开与Broker的连接。

Topic

Topic，即为发布或者订阅的主题，topic一般由多个队列组成，队列会平均的散列到多个Broker上面。Producer的发送机制会保证消息尽量平均的散列到所有队列上面去，最终的效果是所有的消息会平均的落在每个Broker上面。Tag属于子Topic，主要的作用是给业务提供更大的灵活性，用以分流信息。

Producer

Producer，即消息的生产者，负责生产消息，producer的和Name server集群中随机的一个节点建立长连接，定期从nameServer中获取Topic路由信息，并向提供topic服务的master broker建立长连接，并定时向master发送心跳。producer会发布消息到master上面，然后由master同步给所有的slave。Producer每隔30s从Name server获取所有topic队列的最新情况，这意味着如果Broker不可用，Producer最多30s能够感知，在此期间内发往Broker的所有消息都会失败。Producer每隔30s向所有关联的broker发送心跳，Broker每隔10s中扫描所有存活的连接，如果Broker在2分钟内没有收到心跳数据，则关闭与Producer的连接。

Consumer

Consumer，即消息的消费者，负责消费消息，consumer与nameserver集群中的随机一个节点建立长连接，定期的从nameServer中获取topic路由信息，并向提供Topic服务的Master、Slave建立长连接，并且定时向Master、Slave发送心跳。Consumer既可以从Master上面订阅消息，也可以从Slave上面订阅消息，订阅规则由Broker配置决定。Consumer每隔30s从Name server获取topic的最新队列情况，这意味着Broker不可用时，Consumer最多最需要30s才能感知。Consumer每隔30s（由ClientConfig中heartbeatBrokerInterval决定）向所有关联的broker发送心跳，Broker每隔10s扫描所有存活的连接，若某个连接2分钟内没有发送心跳数据，则关闭连接；并向该Consumer Group的所有Consumer发出通知，Group内的Consumer重新分配队列，然后继续消费。

ConsumerGroup

ConsumerGroup，即消费者集群，多个消费者可以组成一个分组，拥有一个共同的分组名称，来共同消费一个topic下的消息，每个消费者消费部分消息。

Message

Message，即生产或者消费的消息，负载用户的数据并且在producer、broker和consumer之间传输。

Offset

消息在Broker上的每个分区都是组织成一个文件列表，消费者拉取数据的时候需要知道数据在文件中的偏移量，这个偏移量就是offset。Offset是一个绝对的偏移量，服务器会将offset转化为具体文件的相对偏移量。

Kafka和MetaQ之对比

Kafka存储机制

Kafka和MetaQ一样，都是采用topic作为发布和订阅的主题，topic是个逻辑概念，而partition是物理上面的概念，每个partition对应一个log文件，该log文件中存储的就是producer生产的数据。producer生产的数据会被不断追加到log文件的末端，且每条数据都有自己的offset。

每个Partition都会有自己的副本，Kafka会尽量的使所有的分区均匀的分布到集群中的所有节点而不是集中在某些节点上，另外主从关系也尽量均衡这样每个几点都会担任一定比例的分区的leader。

阿里云开发者社区，千万开发者的选择。百万精品技术内容、千节免费系统课程、丰富的体验场景、活跃的社群活动、行业专家分享交流，尽在：

标签：