消息队列有几个重要的概念模型：消息、队列、生产者、消费者，下面将介绍这几个基本概念：
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转化为具体文件的相对偏移量。 部署方式 对于MetaQ的Broker来说，是支持以下四种方式的部署：
缺点是如果某个节点宕机了, 会导致该节点存在未被消费的消息在节点恢复之前不能被消费;
优点是弥补了多Master模式（无slave）下节点宕机后在恢复前不可订阅的问题。在Master宕机后, 消费者还可以从Slave节点进行消费。采用异步模式复制，提升了一定的吞吐量。总结一句就是，采用多Master多Slave模式，异步复制模式进行部署，系统将会有较低的延迟和较高的吞吐量； 缺点就是如果Master宕机, 磁盘损坏的情况下, 如果没有及时将消息复制到Slave, 会导致有少量消息丢失；
优点：数据与服务都无单点，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高 缺点就是会降低消息写入的效率，并影响系统的吞吐量；对于Kafka来说，Broker之间不存在master和slave的区别，每一个Broker之间都是平等的，kafka的partition是有master和slave的区别的，kafka将每个partition数据复制到多个server上,任何一个partition有一个leader和多个follower(可以没有);备份的个数可以通过broker配置文件来设定。leader处理所有的read-write请求,follower需要和leader保持同步。Kafka尽量的使所有分区均匀的分布到集群所有的节点上而不是集中在某些节点上，另外主从关系也尽量均衡这样每个几点都会担任一定比例的分区的leader。 消息可靠性 在介绍MetaQ和kafka的消息可靠性之前，我们先来介绍一下几个概念：同步异步复制、同步异步刷盘。 1）同步异步复制 同步复制和异步复制的区别在于producer发送消息到master节点之后，是否会等待slave节点复制结束之后再进行返回。 a. 同步复制 当生产者将消息发送到broker的master节点时，master会首先将消息复制到所有的slave节点，等待复制动作完成之后，才会给客户端返回“发送成功”的响应，消息可靠性得到保证。  b. 异步复制 当生产者将消息发送到broker的master节点时，并不会等待复制动作的结束，会直接返回一个发送成功的状态响应。当出现网络抖动，会导致消息复制不成功，这个时候消息可靠性不够高，消费者消费消息不及时的情况。  - |
|
|
