消息队列之卡夫卡(核心架构)

  

1。卡夫卡的经典架构

  

消息队列之卡夫卡(核心架构)
 卡夫卡是LinkedIn用于日志处理的分布式消息队列,同时支持离线和在线日志处理。
 卡夫卡对消息保存时根据<强>主题强进行归类。
 发送消息者就是<强> 强,生产商消息的发布描述为生产商
 消息接受者就是<强>消费者强,消息的订阅描述为消费者
 每个卡夫卡实例称为<强>代理,将中间的存储阵列称作代理(代理),代理也是卡夫卡集群的节点

  

2。架构的角色介绍

  

 (1)代理

  

  &emsp卡夫卡集群包括一个或者多个服务器,这种服务器被称为brk。
   代理也就是中间的存储队列的节点实例。我们将消息发布者称为:生产,将消息的订阅者称为:消费者,将中间的存储阵列称为代理。

  

 (2)主题

  

   每条发布到卡夫卡集群的消息都有一个类别,这个类别被成为Tpoic。物理上不同的话题的消息分开存储,逻辑上一个话题的消息虽然保存与一个或者多个代理中。但用户只需要指定消费的话题,即生产或者消费数据的客户端不需要关心数据存储与何处。
   卡夫卡中发布订阅的对象就是话题。为每一个数据类型创建一个主题,把向主题发布消息的客户端称为生产商,从主题订阅消息的客户端称为消费者、生产者和消费者可以同时从多读个话题写数据。一个卡夫卡集群由一个或者多个代理服务器组成。他负责持久化和备份具体的卡夫卡消息。
   主题就是数据的主题,是数据记录发布的地方,可以用来区分业务系统.kafka中的总主题是<强>多订阅者模式强,一个主题可以拥有一个或者多个消费者来订阅它的数据。

  

 (3)分区

  

消息队列之卡夫卡(核心架构)
   分区是物理的概念,每一个主题包含一个或者多个分区。
    <强>主题的分区策略(针对写数据的时候进行分区):
     ——<强>轮询:顺序分发,仅针对于消息没有关键的时候。
     ——<强>散列分区:在消息有关键的情况下,(关键。散列%分区个数)。如果在增加分区的时候,分区里面的消息不会重新进行分配,随着数据的继续写入,这个新的分区才会参与负载平衡。

  <人力资源/>   

    <强>主题的分区逻辑存储方式:
消息队列之卡夫卡(核心架构)
     主题会分成一个或多个分区,每个partiton相当于是一个子队列。在物理结构上,每个分区对应一个物理的目录(文件夹),文件夹命名是<强> [topicname] (分区)[序号]强,一个主题可以有无数多的分区,根据业务需求和数据量来设置。在卡夫卡配置文件中可随时更高num.partitions参数来配置更改主题的分区数量,在创建主题时通过参数指定parittion数量.Topic创建之后通过卡夫卡提供的工具也可以修改partiton数量。分区中存放着数据本身和数据的指数下标。在向分区写入数据的时候,是<强>顺序写入强的,每一个数据写入的时候都会有一个类似下标的东西(指数),随着数据的写入而增长.partition也是集群负载均衡的基本单位。

  <人力资源/>   

    <强>总结:
     ——一个主题的分区数量大于等于代理的数量,可以提高吞吐率。
     ——同一个分区的副本尽量分散到不同的机器上,高可用。
     ——卡夫卡的分区数:(1 | 2 | 3 + 0.95)*代理数量

  

 (4)生产商

  

  &emsp  负责主动发布消息到kakfa代理(推)
      <强>卡夫卡消息的保存策略:每个主题被分成多个分区(区)。每条消息在分区中的位置称为抵消(偏移量),类型为长型数字。消息即使被消费了,也不会被立即删除,而是根据经纪人里的设置(<>强基于时间存储或者基于大小),保存一定时间后再清除,比如日志文件设置存储两天,则两天后,不管消息是否被消费,都清除。

  

 (5)消费者

  

  &emsp  消息消费者,向kafkabroker读取消息的客户端。(拉)

消息队列之卡夫卡(核心架构)