自用华为ICT云赛道Big Data第五章知识点-Kafka分布式消息订阅系统

Kafka简介

• Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于Zookeeper协调的分布式日志系统。
• 主要应用场景是：日志收集系统和消息系统。
• 分布式消息传递基于可靠的消息队列，在客户端应用和消息系统之间异步传递消息。有两种主要的消息传递模式：点对点传递模式、发布-订阅模式。大部分的消息系统选用发布-订阅模式。Kafka就是一种发布-订阅模式。

点对点消息传递模式

• 在点对点消息系统中，消息持久化到一个队列中。此时，将有一个或多个消费者消费队列中的数据。但是一条消息只能被消费一次。当一个消费者消费了队列中的某条数据之后，该条数据则从消息队列中删除。该模式即使有多个消费者同时消费数据，也能保证数据处理的顺序。

发布-订阅消息传递模式

• 在发布-订阅消息系统中，消息被持久化到一个topic中。与点对点消息系统不同的是，消费者可以订阅一个或多个topic，消费者可以消费该topic中所有的数据，同一条数据可以被多个消费者消费，数据被消费后不会立马删除。在发布-订阅消息系统中，消息的生产者称为发布者，消费者称为订阅者。

Kafka特点

• 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。
• 高吞吐率。即使在廉价的商用机器上也能做到单机支持每秒100K条消息的传输。
• 支持消息分区，及分布式消费，同时保证每个分区内消息顺序传输。
• 同时支持离线数据处理和实时数据处理。
• Scaleout：支持在线水平扩展。

Kafka拓扑结构图

Kafka基本概念

Kafka Topics

• 每条发布到Kafka的消息都有一个类别，这个类别被称为Topic，也可以理解为一个存储消息的队列。例如：天气作为一个Topic，每天的温度消息就可以存储在“天气”这个队列里。

Kafka Partition

• 为了提高Kafka的吞吐量，物理上把Topic分成一个或多个Partition，每个Partition都是有序且不可变的消息队列。每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件。

Kafka Partition offset

• 每条消息在文件中的位置称为offset（偏移量），offset是一个long型数字，它唯一标记一条消息。消费者通过（offset、partition、topic）跟踪记录。

offset存储机制

• Consumer在从Broker读取消息后，可以选择commit，该操作会在Kakfa中保存该Consumer在该Partition中读取的消息的offset。该Consumer下一次再读该Partition时会从下一条开始读取。
• 通过这一特性可以保证同一消费者从Kafka中不会重复消费数据。
• 消费者group位移保存在_consumer_offsets的目录上：
  • 计算公式: Math.abs(groupID.hashCode()% 50
  • kafka-logs目录，里面有多个目录，因为kafka默认会生成50个_consumer_offsets-n目录

Consumer group

• 每个Consumer都属于一个Consumergroup，每条消息只能被Consumergroup中的一个Consumer消费，但可以被多个Consumergroup消费。即组间数据是共享的，组内数据是竞争的。

Kafka其他重要概念

• Replica:
  • Partition的副本，保障Partition的高可用。
• Leader:
  • Replica中的一个角色，Producer和Consumer只跟Leader交互。
• Follower:
  • Replica中的一个角色，从Leader中复制数据。
• Controller:
  • Kafka集群中的其中一个服务器，用来进行Leader election以及各种Failover。

Kafka Partition Replica

• 每个Partition又有一至多个Replication，Partition的Replication分布在集群的不同Broker上，以提高可用性。从存储角度分析，Partition的每个Replication在逻辑上抽象为一个日志（Log）对象，即Partition的Replication与日志对象是一一对应的。

Kafka主从消息同步

• Kafka分区副本（Follower）从领导者（Leader）那里拉取高水位以下的已经存储的消息到本地的Log（日志）。

Kafka HA

• 同一个Partition可能会有多个Replica（对应 server.properties配置中的default.replication.factor=N) 。
• 没有Replica的情况下，一旦Broker宕机，其上所有Patition的数据都不可被消费，同时Producer也不能再将数据存于其上的Patition。
• 引入Replication之后，同一个Partition可能会有多个Replica，而这时需要在这些Replica之间选出一个Leader，Producer和Consumer只与这个Leader交互，其它Replica作为Follower从Leader中复制数据。

Leader Failover

• 当Partition对应的Leader宕机时，需要从Follower中选举出新Leader。在选举新Leader时，一个基本原则是，新的Leader必须拥有日Leadercommit过的所有消息。
• 由写入流程可知ISR里面的所有Replica都跟上了Leader，只有ISR里面的成员才能选为Leadero
• 对于f+1个Replica，Partition可以在容忍f个Replica失效的情况下保证消息不丢失。
• 当所有Replica都不工作时，有两种可行的方案：
  • 等待ISR中的任一个Replica活过来，并选它作为Leader。可保障数据不丢失，但时间可能相对较长。
  • 选择第一个活过来的Replica（不一定是ISR成员）作为Leader。无法保障数据不丢失，但相对不可用时间较短。

Kafka数据可靠性

• Kafka所有消息都会被持久化到硬盘中，同时Kafka通过对TopicPartition设置Replication来保障数据可靠。
• 那么，在消息传输过程中有没有可靠性保证呢？

消息传输语义

• 消息传输保障通常有以下三种：
  • 最多一次（At Most Once）
    • 消息可能丢失。
    • 消息不会重复发送和处理。
  • 最少一次（At Lease Once）
    • 消息不会丢失。
    • 消息可能会重复发送和处理。
  • 仅有一次（Exactly Once）
    • 消息不会丢失。
    • 消息仅被处理一次。

可靠性保证-幂等性

• 一个幂等性的操作就是一种被执行多次造成的影响和只执行一次造成的影响一样。
• 原理：
  • 每发送到Kafka的消息都将包含一个序列号，Broker将使用这个序列号来删除重复数据。
  • 这个序列号被持久化到副本日志，所以，即使分区的Leader挂了，其他的Broker接管了Leader，新Leader仍可以判断重新发送的是否重复了。
  • 这种机制的开销非常低：每批消息只有几个额外的字段。

可靠性保证-acks机制

• Producer需要Server接收到数据之后发出的确认接收的信号，此项配置就是指Procuder需要多少个这样的确认信号。此配置实际上代表了数据备份的可用性。以下设置为常用选项：
  • acks=0：设置为0表示Producer不需要等待任何确认收到的信息。副本将立即加到socketbuffer并认为已经发送。没有任何保障可以保证此种情况下Server已经成功接收数据，同时重试配置不会发生作用（因为客户端不知道是否失败）回馈的offset会总是设置为-1。
  • acks=1：这意味着至少要等待Leader已经成功将数据写入本地Log，但是并没有等待所有Follower是否成功写入。这种情况下，如果Follower没有成功备份数据，而此时Leader又挂掉，则消息会丢失。
  • acks=all：这意味着Leader需要等待所有备份都成功写入日志，这种策略会保证只要有一个备份存活就不会丢失数据。这是最强的保证。

旧数据处理方式

• Kafka把Topic中一个Parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。

• 对于传统的messagequeue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否。当然，因为磁盘限制，不可能永久保留所有数据（实际上也没必要），因此Kafka需要处理旧数据。
• 配置位置：$KAFKA_HOME/config/server.properties

Kafka Log Cleanup

• 日志的清理方式有两种：delete和compact。
• 删除的阈值有两种：过期的时间和分区内总日志大小。

Kafka Log Compact

缩略语