共计 3076 个字符，预计需要花费 8 分钟才能阅读完成。
作者：王江华 地址：https://mp.weixin.qq.com/s/do…
1、kafka 简介
Kafka 是一个分布式的基于公布 / 订阅模式的音讯队列（Message Queue），次要利用与大数据实时处理畛域。其次要设计指标如下：
- 以工夫复杂度为 O(1)的形式提供音讯长久化能力，即便对 TB 级以上数据也能保障常数工夫的拜访性能
- 高吞吐率。即便在十分便宜的机器上也能做到单机反对每秒 100K 条音讯的传输
- 反对 Kafka Server 间的音讯分区，及分布式生产，同时保障每个 partition 内的音讯程序传输，同时反对离线数据处理和实时数据处理
2、为什么要用音讯零碎
Kafka 实质上是一个 MQ（Message Queue），应用音讯队列的益处？
- 解耦：容许咱们独立批改队列两边的处理过程而互不影响。
- 冗余：有些状况下，咱们在解决数据的过程会失败造成数据失落。音讯队列把数据进行长久化直到它们曾经被齐全解决，通过这一形式躲避了数据失落危险, 确保你的数据被平安的保留直到你应用结束
- 峰值解决能力：不会因为突发的流量申请导致系统解体，音讯队列可能使服务顶住突发的拜访压力, 有助于解决生产音讯和生产音讯的处理速度不统一的状况
- 异步通信：音讯队列容许用户把音讯放入队列但不立刻解决它, 期待后续进行生产解决。
3、kafka 基础知识
上面给出 Kafka 一些重要概念，让大家对 Kafka 有个整体的意识和感知
- Producer：即音讯生产者，向 Kafka Broker 发消息的客户端。
- Consumer：即音讯消费者，从 Kafka Broker 读音讯的客户端。
- Consumer Group：即消费者组，消费者组内每个消费者负责生产不同分区的数据，以进步生产能力。一个分区只能由组内一个消费者生产，不同消费者组之间互不影响。
- Broker：一台 Kafka 机器就是一个 Broker。一个集群是由多个 Broker 组成的且一个 Broker 能够包容多个 Topic。
- Topic：能够简略了解为队列，Topic 将音讯分类，生产者和消费者面向的都是同一个 Topic。
- Partition：为了实现 Topic 扩展性，进步并发能力，一个十分大的 Topic 能够散布到多个 Broker 上，一个 Topic 能够分为多个 Partition 进行存储，每个 Partition 是一个有序的队列。
- Replica：即正本，为实现数据备份的性能，保障集群中的某个节点产生故障时，该节点上的 Partition 数据不失落，且 Kafka 依然可能持续工作，为此 Kafka 提供了正本机制，一个 Topic 的每个 Partition 都有若干个正本，一个 Leader 正本和若干个 Follower 正本。
- Leader：即每个分区多个正本的主正本，生产者发送数据的对象，以及消费者生产数据的对象，都是 Leader。
- Follower：即每个分区多个正本的从正本，会实时从 Leader 正本中同步数据，并放弃和 Leader 数据的同步。Leader 产生故障时，某个 Follower 还会被选举并成为新的 Leader , 且不能跟 Leader 在同一个 broker 上, 避免解体数据可复原。
- Offset：消费者生产的地位信息，监控数据生产到什么地位，当消费者挂掉再从新复原的时候，能够从生产地位持续生产。
- ZooKeeper 服务：Kafka 集群可能失常工作，须要依赖于 ZooKeeper，ZooKeeper 帮忙 Kafka 存储和治理集群元数据信息。在最新版本中, 曾经缓缓要脱离 ZooKeeper。
4、kafka 集群架构
4.1 工作流程
在理解 kafka 集群之前, 咱们先来理解下 kafka 的工作流程, Kafka 集群会将音讯流存储在 Topic 的中，每条记录会由一个 Key、一个 Value 和一个工夫戳组成。
Kafka 中音讯是以 Topic 进行分类的，生产者生产音讯，消费者生产音讯，读取和生产的都是同一个 Topic。然而 Topic 是逻辑上的概念，Partition 是物理上的概念，每个 Partition 对应一个 log 文件，该 log 文件中存储的就是 Producer 生产的数据。Producer 端生产的数据会一直程序追加到该 log 文件开端，并且每条数据都会记录有本人的 Offset。 而消费者组中的每个消费者，也都会实时记录以后本人生产到了哪个 Offset，不便在解体复原时，能够持续从上次的 Offset 地位生产。
4.2 存储机制
此时 Producer 端生产的音讯会一直追加到 log 文件开端，这样文件就会越来越大, 为了避免 log 文件过大导致数据定位效率低下，那么 Kafka 采取了分片和索引机制。它将每个 Partition 分为多个 Segment，每个 Segment 对应 4 个文件：“.index”索引文件,“.log”数据文件,“.snapshot”快照文件,“.timeindex”工夫索引文件。这些文件都位于同一文件夹上面，该文件夹的命名规定为：topic 名称 - 分区号。例如, heartbeat 心跳上报服务 这个 topic 有三个分区，则其对应的文件夹为 heartbeat-0，heartbeat-1，heartbeat- 2 这样。
index, log, snapshot, timeindex 文件以以后 Segment 的第一条音讯的 Offset 命名。其中“.index”文件存储大量的索引信息，“.log”文件存储大量的数据，索引文件中的元数据指向对应数据文件中 Message 的物理偏移量。
下图为 index 文件和 log 文件的构造示意图：
4.3 Replica – 正本
kafka 中的 Partition 为了保障数据安全，每个 Partition 能够设置多个正本。此时咱们对分区 0,1,2 别离设置 3 个正本（注: 设置两个正本是比拟适合的）。而且每个正本都是有 ” 角色 ” 之分的，它们会选取一个正本作为 Leader 正本，而其余的作为 Follower 正本，咱们的 Producer 端在发送数据的时候，只能发送到 Leader Partition 外面，而后 Follower Partition 会去 Leader 那自行同步数据, Consumer 生产数据的时候，也只能从 Leader 正本那去生产数据的。
4.4 Controller
Kafka Controller，其实就是一个 Kafka 集群中一台 Broker，它除了具备一般 Broker 的音讯发送、生产、同步性能之外，还需承担一些额定的工作。Kafka 应用偏心竞选的形式来确定 Controller，最先在 ZooKeeper 胜利创立长期节点 /controller 的 Broker 会成为 Controller，一般而言，Kafka 集群中第一台启动的 Broker 会成为 Controller，并将本身 Broker 编号等信息写入 ZooKeeper 长期节点 /controller。
4.5 Offset 的保护
Consumer 在生产过程中可能会呈现断电宕机等故障，在 Consumer 复原后，须要从故障前的 Offset 地位持续生产。所以 Consumer 须要实时记录本人生产到了哪个 Offset，以便故障复原后持续生产。在 Kafka 0.9 版本之前，Consumer 默认将 Offset 保留在 ZooKeeper 中，然而从 0.9 版本开始，Consumer 默认将 Offset 保留在 Kafka 一个内置的 Topic 中，该 Topic 为 __consumer_offsets, 以反对高并发的读写。
4、总结
下面和大家一起深入探讨了 Kafka 的简介, 基础知识和集群架构，下一篇会从 Kafka 三高 (高性能, 高可用, 高并发) 方面来具体论述其奇妙的设计思维。大家期待 …..