重学kafka之基础知识

Biu_
1,114 阅读11分钟

什么是kafka?

kafka是一款基于发布与订阅的消息引擎系统。它一般被称为“分布式提交日志”或者“分布式流平台”。文件系统或者数据库提交日志用来提供所有事物的持久化记录，通过重建这些日志可以重建系统的状态。同样地，kafka的数据是按照一定顺序持久化保存的，可以按需读取。 kafka在设计之初就旨在提供三个方面的特性：

  1. 提供一套API实现生产者和消费者
  2. 降低网络传输和磁盘存储开销
  3. 实现高伸缩性架构

消息引擎

传输消息的格式

常用的传输消息的格式有CSV、XML 亦或是 JSON，或者是国外大厂开源的一些序列化框架，比如 Google 的 Protocol Buffer 或 Facebook 的 Thrift。

而kafka使用的是纯二进制的字节序列。当然消息还是结构化的，只是在使用之前都要将其转换成二进制的字节序列。

传输消息的协议

  • 点对点模型：也叫消息队列模型。如果拿上面那个“民间版”的定义来说，那么系统 A 发送的消息只能被系统 B 接收，其他任何系统都不能读取 A 发送的消息。日常生活的例子比如电话客服就属于这种模型：同一个客户呼入电话只能被一位客服人员处理，第二个客服人员不能为该客户服务。
  • 发布/订阅模型：与上面不同的是，它有一个主题（Topic）的概念，你可以理解成逻辑语义相近的消息容器。该模型也有发送方和接收方，只不过提法不同。发送方也称为发布者（Publisher），接收方称为订阅者（Subscriber）。和点对点模型不同的是，这个模型可能存在多个发布者向相同的主题发送消息，而订阅者也可能存在多个，它们都能接收到相同主题的消息。生活中的报纸订阅就是一种典型的发布 / 订阅模型。

kafka同时支持这两种消息引擎模型

kafka的作用

消息队列最主要的作用就是:流量削峰和松耦合 流量削峰是指当上游流量瞬间暴涨的时候，势必会出现下游服务无法及时处理上游的消息从而造成消息堆积的情形。特别是当出现类似于秒杀这样的业务时，上游订单流量会瞬时增加，可能出现的结果就是直接压跨下游子系统服务。

当引入了 Kafka 之后。上游消息服务不再直接与下游子服务进行交互。当新消息生成后它仅仅是向 Kafka Broker 发送一条消息即可。类似地，下游的各个子服务订阅 Kafka 中的对应主题，并实时从该主题的各自分区（Partition）中获取到消息进行处理，从而实现了上游消息服务与下游消息处理服务的解耦。

这样当出现如 秒杀业务时，Kafka能够将瞬时增加的订单流量全部以消息形式保存在对应的主题中，既不影响上游服务的 TPS，同时也给下游子服务留出了充足的时间去消费它们。这就是 Kafka 这类消息引擎系统的最大意义所在。

kafka中的术语

Producer

  1. 消息和数据生成者，向Kafka的一个topic发布消息的过程叫做producers
  2. Producer将消息发布到指定的Topic中，同时Producer也能决定将此消息归属于哪个partition；比如基于round-robin方式或者通过其他的一些算法等；
  3. 异步发送批量发送可以很有效的提高发送效率。kafka producer的异步发送模式允许进行批量发送，先将消息缓存到内存中，然后一次请求批量发送出去。

Producer消息分发

  • kafka集群中的任何一个broker都可以向producer提供metadata信息,这些metadata中包含"集群中存活的servers列表"/"partitions leader列表"等信息；
  • 当producer获取到metadata信息之后, producer将会和Topic下所有partition leader保持socket连接；
  • 消息由producer直接通过socket发送到broker，中间不会经过任何"路由层"，事实上，消息被路由到哪个partition上由producer客户端决定；
    • 比如可以采用"random"，"key-hash"，"轮询"等方式，==如果一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的。==
  • 在producer端的配置文件中,开发者可以指定partition路由的方式。

Producer消息发送的应答机制 设置发送数据是否需要服务端的反馈,有三个值0,1,-1

0: producer不会等待broker发送ack

1: 当leader接收到消息之后发送ack

-1: 当所有的follower都同步消息成功后发送ack

request.required.acks=0

默认partitioner使用defaultPartitioner，使用hashcode

Broker

Kafka 的服务器端由被称为 Broker 的服务进程构成，即一个 Kafka 集群由多个 Broker 组成，Broker 负责接收和处理客户端发送过来的请求，以及对消息进行持久化。虽然多个 Broker 进程能够运行在同一台机器上，但更常见的做法是将不同的 Broker 分散运行在不同的机器上，这样如果集群中某一台机器宕机，即使在它上面运行的所有 Broker 进程都挂掉了，其他机器上的 Broker 也依然能够对外提供服务。这其实就是 Kafka 提供高可用的手段之一。

实现高可用的另一个手段就是备份机制（Replication）。备份的思想很简单，就是把相同的数据拷贝到多台机器上，而这些相同的数据拷贝在 Kafka 中被称为副本（Replica）。副本的数量是可以配置的，这些副本保存着相同的数据，但却有不同的角色和作用。Kafka 定义了两类副本：领导者副本（Leader Replica）和追随者副本（Follower Replica）。

副本的工作机制也很简单：生产者总是向领导者副本写消息；而消费者总是从领导者副本读消息。至于追随者副本，它只做一件事：向领导者副本发送请求，请求领导者把最新生产的消息发给它，这样它能保持与领导者的同步。

虽然有了副本机制可以保证数据的持久化或消息不丢失，但没有解决伸缩性的问题。

什么是伸缩性呢？

拿副本来说，虽然现在有了领导者副本和追随者副本，但倘若领导者副本积累了太多的数据以至于单台 Broker 机器都无法容纳了，此时应该怎么办？Kafka的做法是把数据分割成多份保存在不同的 Broker 上，这种机制就是所谓的分区（Partitioning）。

Kafka 中的分区机制指的是将每个主题划分成多个分区（Partition），每个分区是一组有序的消息日志。生产者生产的每条消息只会被发送到一个分区中，也就是说如果向一个双分区的主题发送一条消息，这条消息要么在分区 0 中，要么在分区 1 中。Kafka 的分区编号是从 0 开始的，如果 Topic 有 100 个分区，那么它们的分区号就是从 0 到 99。

副本和分区的联系

副本是在分区这个层级定义的。每个分区下可以配置若干个副本，其中只能有 1 个领导者副本和 N-1 个追随者副本。生产者向分区写入消息，每条消息在分区中的位置信息由一个叫位移（Offset）的数据来表征。分区位移总是从 0 开始，假设一个生产者向一个空分区写入了 10 条消息，那么这 10 条消息的位移依次是 0、1、2、…、9。

Kafka的三层消息架构

  • 第一层是主题层，每个主题可以配置 M 个分区，而每个分区又可以配置 N 个副本。
  • 第二层是分区层，每个分区的N个副本中只能有一个充当领导者角色，对外提供服务；其他 N-1 个副本是追随者副本，只是提供数据冗余之用。
  • 第三层是消息层，分区中包含若干条消息，每条消息的位移从 0 开始，依次递增。
  • 客户端程序只能与分区的领导者副本进行交互。

Kafka Broker 持久化数据

Kafka 使用消息日志（Log）来保存数据，一个日志就是磁盘上一个只能追加写（Append-only）消息的物理文件。 为了避免缓慢的随机 I/O 操作，kafka采用的是顺序 I/O 写操作，这也是实现 Kafka 高吞吐量特性的一个重要手段。

如果不停地向一个日志写入消息，最终也会耗尽所有的磁盘空间。

因此 Kafka 必然要定期地删除消息以回收磁盘。怎么删除呢？

简单来说就是通过日志段（LogSegment）机制。在Kafka底层，一个日志又进一步细分成多个日志段，消息被追加写到当前最新的日志段中，当写满了一个日志段后，Kafka会自动切分出一个新的日志段，并将老的日志段封存起来。Kafka在后台还有定时任务会定期地检查老的日志段是否能够被删除，从而实现回收磁盘空间的目的。

Consumer

  1. 消息和数据消费者，订阅topic并处理其发布的消息的过程叫做consumers.
  2. 一个partition中的消息只会被group中的一个consumer消费(同一时刻)；
  3. 在kafka中，可以认为一个group是一个“订阅者”，一个topic中的每个partions只会被一个“订阅者”中的一个consumer消费，不过一个consumer可以消费多个partitions中的消息

注:

Kafka的设计原理决定，对于一个topic，同一个group不能多于partition个数的consumer同时消费，否则将意味着某些consumer无法得到消息。

kafka只能保证一个partition中的消息被某个consumer消费时是顺序的；事实上，从Topic角度来说,当有多个partitions时,消息仍不是全局有序的。

Consumer的负载均衡

当一个group中,有consumer加入或者离开时,会触发partitions均衡.均衡的最终目的,是提升topic的并发消费能力，步骤如下：

  1. 假如topic1,具有如下partitions: P0,P1,P2,P3
  2. 加入group中,有如下consumer: C1,C2
  3. 首先根据partition索引号对partitions排序: P0,P1,P2,P3
  4. 根据consumer.id排序: C0,C1
  5. 计算倍数: M = [P0,P1,P2,P3].size / [C0,C1].size,本例值M=2(向上取整)
  6. 然后依次分配partitions: C0 = [P0,P1],C1=[P2,P3],即Ci = [P(i * M),P((i + 1) * M -1)] image

思考

为什么 Kafka 不像 MySQL 那样允许追随者副本对外提供读服务？

  1. kafka的分区已经让读操作是从多个broker中去读取，从而达到负载均衡，不像MySQL的主从，压力都在主上;
  2. kafka保存的数据和数据库的性质有实质的区别就是数据具有消费的概念，是流数据，kafka是消息队列，所以消费需要位移，而数据库是实体数据不存在这个概念，如果从kafka的follower读，消费端offset控制更复杂;
  3. 生产者来说，kafka可以通过配置来控制是否等待follower对消息确认的，如果从上面读，也需要所有的follower都确认了才可以回复生产者，造成性能下降，如果follower出问题了也不好处理
  4. 对于那种读操作很多而写操作相对不频繁的负载类型而言，采用读写分离是很好的方案。但是Kafka，它的主要场景还是在消息引擎而不是以数据存储的方式对外提供读服务，通常涉及频繁地生产消息和消费消息，这不属于典型的读多写少场景，因此读写分离方案在这个场景下并不太适合。
avatar
文章
阅读
粉丝