kafka应用场景_Kafka系列文章之Kafka是什么第1篇

前言

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

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

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

各消息队列对比

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

特性	Kafka	RocketMQ	ActiveMQ	RabbitMQ
吞吐量	高吞吐量，可达 10w 级别	高吞吐量，可达 10w 级别	1w 级别，吞吐量相交比较低	1w 级别，吞吐量相交比较低
时效性	延迟在 ms 级	延迟在 ms 级	延迟在 ms 级	延迟在微妙级，延迟最低
可用性	天然的分布式系统，数据有副本机制，可用性非常高	分布式架构，可用性非常高	主从架构，可用性较高	同 ActiveMQ
维护性	基于 Java 和 Scala 语言 实现，社区活跃度高，维护成本较低	基于 Java 语言实现，社区活跃度高，维护成本较低	基于 Java 语言实现，消息队列场景功能很完备，但社区活跃度较低，维护成本较高	基于 erlang 语言开发，社区活跃度一般，小团队维护成本较高

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 还有副本的概念，后面文章来详细介绍。

总结

本篇文章主要介绍了 Kafka 是什么，Kafka 的整体架构及各组件组成；为了让大家更容易理解和接受，部分概念没有完全展开，在后续的文章中我们会一一来详细介绍，请大家放心；基本概念讲完了，下篇文章我们来实操搭建一个 Kafka 集群玩玩，敬请期待。

点击关注作者，系列文章不迷路。

点击关注作者，系列文章不迷路