Kafka是什么-第一篇

前言

如果有幸目睹过系统从零到一的演变过程，大家估计都会有一种感叹，就是随着业务复杂度和流量的不断上升，系统变得越来越难以维护，面对高额的维护成本，攻城师们不得不对现有架构进行改造升级，以便使得系统更适合当下业务的发展。

说到架构改造升级，那到底该怎么改造呢？从哪里入手比较合适呢？这是一个比较大的话题，一两句话没办法讲述清楚，但是有一个出发点肯定是没有错的，就是为了更好的适应业务的发展需要进行必要的改造。

假设几个场景，场景一：用户 A 刷了微博，可能对某类博主比较感兴趣，为了让用户 A 看到更多可能感兴趣的人，该怎么做呢？场景二：用户 A 修改了年龄，搜索部门为了给其推荐可能感兴趣的商品，需要实时知道用户修改年龄的动作，采用何种方式来降低用户部门和搜索部门的耦合程度呢？场景三：京东 618 当天，大佬们想要看到实时成交总额，但又不能影响业务正常运行，又该怎么做呢？从以上几个例子可以看出，为了使得消息传递实时（说一下作者对实时的理解：在用户能接受的时间范围内得到想要的结果就是实时），降低业务部门的耦合度，需要有一个“中介”从中传递从而达到目的。

各消息队列对比

主流消息队列特性对比如下

Kafka 是什么？

Kafka 是一个分布式的、高吞吐量的、可持久性的、自动负载均衡的消息队列，同时 Kafka 从一定意义上来说具有横向易扩展性，通过 Kafka 也可以降低系统间的耦合度。

Kafka 消息队列中的消息生产消费模型是什么样的，即消息从何处来，又被送往何处去？

从上图可以看出，消息的产生可以是 APP 应用、DB 等等渠道，从各渠道产生的消息交给 Kafka Cluster，然后在通过计算将结果送到 DB、APP 等应用中。其实说白了就是一个典型的生产者消费者模型的具体应用。

Kafka 整体架构图

整体架构图

相关组件介绍

• ​​Producer​​

消息发布者；即主要作用是生产数据，并将产生的数据推送给 Kafka 集群。

• ​​Consumer​​

消息消费者；即主要作用是 kafka 集群中的消息，并将处理结果推送到下游或者是写入 DB 资源等。

• ​​Zookeeper Cluster​​

存储 Kafka 集群的元数据信息，比如记录注册的 Broker 列表，topic 元数据信息，partition 元数据信息等等。

• ​​Broker​​

Kafka 集群由多台服务器构成，每台服务器称之为一个 Broker 节点。

• ​​Topic​​

主题，表示一类消息，consumer 通过订阅 Topic 来消费消息，一个 Broker 节点可以有多个 Topic，每个 Topic 又包含 N 个 partition(分区或者分片)。

• ​​Partition​​

partition 是一个有序且不可变的消息序列，它是以 append log 文件形式存储的，partition 用于存放 Producer 生产的消息，然后 Consumer 消费 partition 上的消息，每个 partition 只能被一个 Consumer 消费。partition 还有副本的概念，后面文章来详细介绍。