metaq的基本概念术语

概念和术语 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-一、0-二、0-三、0-四、1-0、1-一、1-二、1-三、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可让用户本身决定如何在响应性和吞吐量之间作平衡，经过配置来合理设置参数，达到应用方须要的实时性，实际测试，消息消费的延迟能够在几毫秒到几秒之间。