Kafka 口水话｜青训营笔记

Jacob953
127 阅读4分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 22 天

本篇文章归档于 “第五届字节跳动青训营”，主要是为了完成和记录掘金的 “伴学笔记创作活动” 活动，如果你对我的其他文章感兴趣，可以去我的 专栏 中逛逛看有没有你想要的东西。

放在前面的话

消息队列（Message Queue），指保存消息的一个容器，本质上就是队列。但它需要支持三高场景（高并发、高吞吐和高可用），因此，它作为中间件扮演着很重要的角色。

消息队列的应用场景非常广泛，通常是为了解藕、削峰、异步和日志处理，常见的有：Kafka、RocketMQ、Pulsar 和 BMQ。

Kafka 框架

使用 Kafka 得先创建一个集群，在集群里添加一个 Topic，然后再编码生产者和消费者的逻辑。如果你想了解更多，指路 Kafka 官方文档。

image.png

Kafka 相关概念

先来看看 KafKa 的一些概念：

  • Producer：消息的生产端，负责将业务消息发送到 Topic 当中；
  • Cluster：物理集群，每个 Cluster 中可以新建多个不同的 Topic；
  • Topic：逻辑队列，可以理解成每一个不同的业务场景就是一个不同的 Topic，对于这个业务来说，所有的数据都存储在这个 Topic 中；
  • Partition：通常 Topic 会有多个分片，不同分片直接消息是可以并发来处理的，这样提高单个Topic 的吞吐；
  • Consumer：消息的消费端，负责消费已经发送到 Topic 中的消息；
  • Broker：机器节点，当不止一个 Broker 时，所有的 Broker 组成一个 Cluster。

对于 Partition，还有一些和其状态相关的概念：

  • Offset：消息在 Partition 内的相对位置信息，可以理解为唯一 ID，在 Partition 内部严格递增；
  • Replica：Partition 的副本，分布在不同的机器上，可用来容灾，Leader 对外服务，Follower 异步去拉取 Leader 的数据进行同步，如果Leader挂掉了，可以将 Follower 提升成 Leader 再对外进行服务；
  • ISR（In-Sync Replicas）：同步中的副本，对于 Follower 来说，始终和 Leader 是有一定差距的，但当这个差距比较小的时候，我们就可以将这个 Follower 副本加入到 ISR 中，不在 ISR 中的副本是不允许提升成 Leader 的。

在此基础上，还会有一个存储集群元数据的组件，通常会是 Zookeeper，由其中一个 Broker 担任 Controller 向它上报数据，和控制其他逻辑。

Kafka 的性能分析

记录一下课件中提高吞吐和稳定性的功能：

  • Producer
    • 批量发送：减少 IO 次数，增加发送能力；
    • 数据压缩：通过压缩算法（Snappy、Gzip等）减少消息大小；
  • Broker
    • 顺序写：磁盘顺序写入，提高效率；
    • 消息索引：通过时间戳和 Offset 查找消息；
    • 零拷贝；
  • Costumer
    • 重分配：手动分配 ->（需要 Coordinator 协助）自动分配。

Kafka 的缺陷

当然，Kafka 也存在一些缺陷：

  • 数据复制：采用 quorum 方案，相对于 primary-backup 需要更多 broker，运维难度大；
  • 重启：切换 Leader 追赶数据时需要进行数据复制，时间成本大；
  • 替换、扩容、缩容：本质上都是数据复制，但相比重启，这里是从头开始复制；
  • 负载不均衡：分片的大小不一。

除此之外，Kafka 没有自己的缓存，完全依赖PageCache，不怎么灵活；Controller 和 Coordinator 和Broker 在同一进程中，大量I0会造成其性能下降。

放在后面的话

总的来说，Kafka 的运维成本很高，对于负载不均衡的场景，解决方案复杂，当然，这些问题都是可以解决的。希望能让你对 Kakfa 有个大概的印象。

avatar
文章
阅读
粉丝