metaq的基本概念术语
博客专区 > chaun 的博客 > 博客详情
metaq的基本概念术语
chaun 发表于2年前
metaq的基本概念术语
  • 发表于 2年前
  • 阅读 29
  • 收藏 0
  • 点赞 2
  • 评论 0

标题:腾讯云 新注册用户域名抢购1元起>>>   

摘要: 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-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可以让用户自己决定如何在响应性和吞吐量之间做平衡,通过配置来合理设置参数,达到应用方需要的实时性,实际测试,消息消费的延迟可以在几毫秒到几秒之间。

共有 人打赏支持
粉丝 80
博文 261
码字总数 96133
×
chaun
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: