Kafka principle

• Message Queuing internal implementation principle
  • Two message transmission
  • Kafka
  • kafka Profile
  • kafka cluster role
• Kafka workflow analysis
  • Kafka production process analysis
    • Write mode
    • Partition (partition)
    • Copy (replication)
    • data input
  • Save Message Broker
    • Storage
    • Storage Policy
    • ZooKeeper storage structure
  • Kafka consumption process analysis
    • Advanced API
    • Low-level API
    • Consumer group
    • Consumption patterns

Message Queuing internal implementation principle

Client A sends a message to the message queue, the client consumes messages from the message queue B

Two message transmission

• peer to peer

  Ad hoc mode (one consumer active pull data, the message received message clear ), messages sent to the queue can be a consumer consumption, even if there are a plurality of consumers.

  • Advantages: speed pull message client controlled.
  • Disadvantages: real-time monitoring thread message queue, any news on the pull

• Published subscription model

  Many, after the data are generated, pushed to all subscribers. Publish and subscribe model can have a variety of different subscribers, subscribers only temporary when active listener topic to receive messages, durable subscribers theme is listening to all messages, even if the current subscriber is not available offline.

  • Advantages: not need to monitor the message queue, the message queue will be active push message.
  • Cons: The client gets the message queue is determined by the speed of the message, may result in waste of resources.

Message Queuing advantages:

1. Message sending end and receiving end need not be directly connected, may be connected through an intermediate piece, can be decoupled
2. Message queue data may be backed up
3. Scalability - clusters
4. Flexibility & peak processing capability
5. Recoverability
6. Order assurance (queue characteristic)
7. buffer
8. Asynchronous Communication: A B sends a message hang also all right

Kafka

kafka Profile

kafka is a distributed message queue . When messages are stored according to kafka Topic classified, send messages called Producer, called Consumer message recipients, in addition kafka kafka cluster of a plurality of instances, each instance (server) called Broker .

Whether kafka cluster or consumer depend on the zookeeper cluster preserve some meta information, to ensure system availability.

kafka architecture

• Producer: news producer, it is the customer kafka broker (kafka server) end of message
• Consumer: news consumers get news to kafka broker clients
• Consumer Group: This is a Topic kafka used for broadcast messages (sent to all consumer) and unicast (issued any consumer) means. topic message is sent to all the Consumer Group. But each partition can only send messages to a consumer in the Consumer Group . To implement the broadcast, as long as each has an independent consumer Consumer Group, a consumer that is a group. All this under the partition will be the topic of messages pushed to all the consumer. To achieve all of unicast as long as the same consumer in a Consumer Group. Group consumer group may also be freely used without the need for multiple Consumer send messages to a different topic.
• Broker: a kafka server is a broker. A cluster composed of a plurality of broker. A broker can receive a plurality of topic.
• Topic: it can be understood as a queue
  • Logical concept: Topic same message may be distributed on one or more nodes (Broker).
  • A Topic Partition contains one or more
  • Each message belongs to one and only one Topic
  • When Producer publish data, you must specify which news release to Topic
  • When Consumer subscription message, the message must also specify which Topic subscription.
• Partition: Each partition is an orderly queue. partition each message is assigned a sequential id (offset). kafka order to ensure that only one partition in a message to the consumer, does not guarantee a whole topic (s partition between) sequence.
  • A Patition only distributed on a Broker (without regard to backup).
  • Partition corresponding to a physical folder
  • Partition comprises a plurality of Segment (Segment transparent to the user).
  • A Segment corresponds to a file
  • Segment recording of one immutable composition
  • Record will only be append to Segmentt, the individual will not be deleted or modified.
  • When clearing outdated logs, delete one or more Segment.

• Offset: Offset. To the position of the current consumption of the message.

如图可以看出：kafka 集群 > broker > topic > partition。即一个 kafka 集群中有多台 kafka 服务器，每台服务器可以有多个 topic 存放不同主题的消息，当一个 topic 太大了，可以将其划分成多个 partition。上图中 消息生产者 A 发送 主题 A 的消息到服务器上，topic A 的消息被分在了两个 partition 上：partition 0 与 partition 1。partition 0 和 partition 1 分别在 broker 1 和 broker 2 上有着 leader 和 follower。其中 leader 可以处理读写请求，当生产者发送消息到 topic 上时是发送到对应的 partition 的 leader 上去，leader 再将消息同步到 follower 上。follower 消息只能处理消费者的读请求。然后 每个Consumer Group 可以有一个或者多个 consumer。同一个 consumer group 上的 consumer 不能消费同一个topic 下的同一个 partition，但是可以消费不同的 partition。也就是说 上图的 consumer A 和 consumer B 不能同时消费 Topic A 下的 partition 0 但是可以分别消费 partition 0 和 partition 1。不同的 consumer group 上的 consumer 之间的消费没有冲突，可以随便消费。这样可以非常方便的实现一个 Topic 的广播和单播。

注意：上图中 同一个 partition 出现在了不同 broker 中是因为实现了 Replication（备份）

kafka 集群角色

• Leader

  所有的通信都是跟 Leader 进行，当 Leader 写完数据后，Follower 会自动向 Leader 获取数据同步

• Follwer

  当实现副本（Replication 后）会创建 Follwer 用来备份。当 Leader 获取数据后，会自动向 Leader 同步数据。如果没有实现副本。那么每个分区都只会有 Leader，不会有 Follwer。

Kafka 工作流程分析

Kafka 生产过程分析

写入方式

Producer 采用推 （push）模式将消息发布到 broker，每条消息都被 append 到分区中（其实是 append 到 partition 文件夹内的 Segment 文件中），属于顺序写磁盘（顺序写磁盘效率比随机写内存高，保障 kafka 吞吐率）。

分区

消息发送时都被发送到一个 topic，其本质就是一个目录，而 topic 是由一些 Partition Logs（分区日志）组成，其组织结构如下图所示。

我们可用看到，每个 Partition 中的消息都是有序的，生产的消息不断追加到 Partition log 上，其中的每个消息都被赋予了一个唯一的 offset 值。

1. 分区的原因
   • 方便在集群中扩展，每个 Partition 可以通过调整以适应它所在的机器。而一个 topic 又可以由多个 partition 组成，因此整个集群就可以适应任意大小的数据了
   • 可以提高并发量，因为可以以 partition 为单位读写了。
2. 分区的原则
   • 指定 Partition，直接使用
   • 未指定 partition 但指定 key，可以通过 key 进行 hash 出一个 partition
   • 采用轮询方法选出一个 partition

副本

同一个 partition 可能有 多个 replication。没有 replication 的情况下，一旦 broker 宕机，其上所有 partition 的数据都不可被消费，同时 producer 也不能再将消息存于其他 partition。引入 replication 之后，同一个 partition 可能会有多个 replication，而这时需要这些 replication 之间选择出一个 leader，producer 和 consumer 只与这个 leader 交互，其他 replication 作为 follower 从 leader 中复制数据。

写入数据

1. Producer 先从 zookeeper 的 “brokers/.../state” 节点找到该 partition 的 leader
2. producer 将消息发送给该 leader
3. leader 将消息写入本地 log
4. followers 从 leader pull 消息，写入本地 log 后向 leader 发送 ACK
5. leader 收到所有 follower 的 ACK 后，向 prodicer 发送 ACK

Broker 保存消息

存储方式

物理上把 topic 分成一个或者多个 partition，每个 partition 物理上对应一个文件夹（该文件夹存储该 partition 的所有消息和索引文件）

存储策略

无论消息是否被消费， kafka 都会保留所有消息。有两种策略可以删除旧数据。

• 基于事件
• 基于大小

需要注意的是，因为 Kafka 读取特定消息的时间复杂度为 O（1），即与文件大小无关，所以这里删除过期文件与提高 Kafka 性能无关。

ZooKeeper 存储结构

其中由于新版本 kafka 消费者的 offset 存在本地，因此在 zookeeper 中看不到。brokers 节点下的 ids 存放着 brokerid，存放所有 broker 的信息。topics 节点内可以看到每个 topic 的 各个 partition 的具体信息。

注意：producer 不在 zk 中注册，消费者在 zk 中注册。

Kafka 消费过程分析

kafka 提供了两套 consimer API，高级和低级的。

高级 API

• 优点
  • 写起来检点
  • 不需要自行去管理 offset，系统通过 zookeeper 自行管理。
  • 不需要管理分区，副本等情况，系统自动管理。
  • 消费者断线后会自动根据上一次记录在 zookeeper 中的 offset 去接着获取数据（默认设置 1 分钟更新一下 zookeeper 中存的 offset）
  • 可以使用 group 来区分对同一个 topic 的不同程序访问分离开来（不同的 group 记录不同的 offset，这样不同程序读取同一个 topic 才不会因为 offset 互相影响）
• 缺点
  • 不能自行控制 offset
  • 不能细化控制如分区、副本、zk 等

低级 API

• 优点
  • 能够让开发者自己控制 offset，想从那里读取就从哪里读取
  • 自行控制连接分区，对分区自定义进行负载均衡
  • 对 zk 的依赖性降低（offset 不一定非要存在 zk，自行存储 offset 即可，比如存在文件或者内存中）
• 缺点
  • 太过复杂，需要自行控制 offset，连接哪个分区，找到分区 leader 等

消费者组

消费者是以 consumer group 消费者组的方式工作，由一个或者多个消费者组成一个组，共同消费一个 topic。每个分区在同一时间只能由 group 内的一个消费者读取，但是多个 group 可以同时消费这个 partition。在上图，有一个由三个消费者组成的 group，有一个消费者读取 topic 中的两个分区，另外两个分别读取一个分区。某个消费者读取某个分区，也可以叫做某个消费者是某个分区的拥有者。

在这种情况下，消费者可以通过水平扩展方式同时读取大量的消息。

消费方式

consumer 采用 pull（拉）模式从 broker 中读取数据。

push 模式很难适应消费速率不同的消费者，因为消息发送速率是由 broker 决定的。它的目标是尽可能以最快速度的传递消息，但是这样很容易造成 consumer 来不及处理消息，容易引起拒绝服务以及网络拥塞。而 pull 模式则是可以根据 consumer 的消费能力以适当的速率消费消息。

对于 kafka 而言，pull 模式更合适，它可以简化 broker 的设计，consumer 可自主控制消费消息的速率，同时 consumer 可以自己控制消费方式 ------ 批量消费或者逐条消费。

pull 模式不足之处是，如果 kafka 没有数据，消费者可能会陷入循环中，一直等待数据到达。为了避免这种情况，我们在我们的拉请求中有参数，允许消费者请求在等待数据到达的长轮询中进行阻塞（并且可选地等待到达给定的字节数，以确保大的传输大小）。