metaq的基本概念术语

为什么80%的码农都做不了架构师？>>>   

概念和术语 Meta的概念和术语介绍

消息生产者 也称为Message Producer，一般简称为producer，负责产生消息并发送消息到meta服务器。

消息消费者 也称为Message Consumer，一般简称为consumer，负责消息的消费，meta采用pull模型，由消费者主动从meta服务器拉取数据并解析成消息并消费。

Topic 消息的主题，由用户定义并在服务端配置。producer发送消息到某个topic下，consumer从某个topic下消费消息。

分区(partition) 同一个topic下面还分为多个分区，如meta-test这个topic我们可以分为10个分区，分别有两台服务器提供，那么可能每台服务器提供5个分区，假设服务器id分别为0和1，则所有分区为0-0、0-1、0-2、0-3、0-4、1-0、1-1、1-2、1-3、1-4。

分区跟消费者的负载均衡机制有很大关系，具体见集群和负载均衡。

Message 消息，负载用户数据并在生产者、服务端和消费者之间传输。

Broker 就是meta的服务端或者说服务器，在消息中间件中也通常称为broker。

消费者分组(Group) 消费者可以是多个消费者共同消费一个topic下的消息，每个消费者消费部分消息。这些消费者就组成一个分组，拥有同一个分组名称,通常也称为消费者集群

Offset 消息在broker上的每个分区都是组织成一个文件列表，消费者拉取数据需要知道数据在文件中的偏移量，这个偏移量就是所谓offset。Offset是绝对偏移量，服务器会将offset转化为具体文件的相对偏移量。详细内容参见#消息的存储结构

同组和不同组：是指10个consumer是否同一个分组，如果是同一个分组则共同分担消费同一个topic;否则，每个consumer完整消费该topic。通俗地说，同组就是一条消息只会被分组内一个consumer消费，不同组，则一条消息会被每个consumer消费。

数据可靠性参数 Meta保证消息可靠性是建立在磁盘可靠性的基础上，发送的每一条消息都保证是在“写入磁盘”的情况下才返回给客户端应答。这里有两个关键参数可以控制：

数据删除策略配置 默认情况下，meta是会保存不断添加的消息，然后定期对“过期”的数据进行删除或者归档处理，这都是通过下列参数控制的： deleteWhen: 何时执行删除策略的cron表达式，默认是0 0 6,18 * * ?，也就是每天的早晚6点执行处理策略。 deletePolicy: 数据删除策略，默认超过7天即删除,这里的168是小时，10s表示10秒，10m表示10分钟，10h表示10小时，不明确指定单位默认为小时。delete是指删除，超过指定时间的数据文件将被彻底从磁盘删除。也可以选择archive策略，即不对过期的数据文件做删除而是归档，当使用archive策略的时候可以选择是否压缩数据文件，如167,archive,true即选择将更改时间超过7天的数据文件归档并压缩为zip文件，如果不选择压缩，则重命名为扩展名为arc的文件。 上述两个参数都可以被topic单独配置所覆盖，也就是每个topic可以指定自己独特的删除策略。通常来说，对于不重要的topic可以将更早地将他们删除来节省磁盘空间。

zookeeper配置 meta服务端会将自身id,topic信息和socket地址发送到zookeeper上，让客户端可以发现并连接服务器。Zookeeper相关的配置放在[zookeeper]模块下面: zk.zkEnable: 是否启用zookeeper，也就是是否将信息注册到zookeeper上。默认为true。对于同步复制的slave来说，本参数会被强制设置为false。 zk.zkConnect: zookeeper服务器列表，例如localhost:1281这样的字符串。默认也是localhost:2181。请设置你的zk集群地址列表。 zk.zkSessionTimeoutMs: zookeeper的session timeout，默认为30秒。单位毫秒。 zk.zkConnectionTimeoutMs： zookeeper的连接超时时间，默认同样为30秒，单位毫秒。 zk.zkSyncTimeMs: 预期的zk集群间数据同步延迟，默认为5秒，这个参数对服务器无意义。

新增Topic热部署 在新增或者删除topic并保存server.ini之后，可以通过下列命令热加载新的配置文件并生效： bin/metaServer.sh reload

Meta相比于kafka的一个重要特性就是消息高可用方案的实现，我们称之为HA方案。消息在发送到broker之后立即写入磁盘才返回客户端告诉消息生产者消息发送成功，通过unflushThreshold和unflushInterval两个参数的控制，可以保证单机消息数据的安全性，只要机器的磁盘没有永久损坏，消息总可以在重启后恢复并正常投递给消费者们。但是，如果遇到了磁盘永久损坏或者数据文件永久损坏的情况，那么该broker上的消息数据将可能永久丢失。为了防止这种情况的发生，一个可行的方案就是将消息数据复制到多台机器，类似mysql的主从复制功能。

采用pull模型，消息的实时性有保证吗？ Metamorphosis在消费端采用pull的模型，consumer主动去broker拉取数据，而不是类似大多数MQ那样由broker主动push数据给消费者。可能很多人担心采用pull模型后，会不会消息的实时性降低了，从发送到消费的整个时间周期拉长了。 实际上，meta中消息的实时性受很多因素影响，不能简单地说实时性一定会降低，主要影响因素如下 broker上配置的批量force消息的阈值，默认是1000条force一次。这个值越大，则实时性越低。 消费者每次抓取的数据大小，这个值越大，则实时性越低，但是吞吐量越高。 Topic的分区数目对实时性也有较大影响，分区数目越多，则磁盘压力越大，导致消息投递的实时性降低。 消费者重试抓取的时间间隔，越长则延迟越严重。 消费者抓取数据的线程数 可见，消息实时性在meta里受到很多因素的影响，meta可以让用户自己决定如何在响应性和吞吐量之间做平衡，通过配置来合理设置参数，达到应用方需要的实时性，实际测试，消息消费的延迟可以在几毫秒到几秒之间。

转载于:https://my.oschina.net/chaun/blog/674492