消息队列专栏(2):带你认识 KAFKA

1、KAFAK 概述

Apache Kafka最早是由LinkedIn开源出来的分布式消息系统，现在是Apache旗下的一个子项目，并且已经成为开源领域应用最广泛的消息系统之一。引用官方网站对kafka 的定义：
"Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications"

2、KAFAK 架构

2.1 KAFKA 设计动机

Kafka 的设计初衷是能够作为一个统一平台来处理大型公司可能存在的所有实时数据发送场景。为此， KAFKA 必须考虑一系列相当广泛的用例。
系统必须具有高吞吐量才能支持大容量事件流，例如实时日志聚合。
系统需要优雅地处理大量数据积压，以便能够支持来自离线系统的定期数据加载。
这也意味着系统必须处理低延迟交付以处理更传统的消息传递用例。
系统必须具备容错机制，保证数据的可靠性。

2.2 KAFKA 架构图

2.3 名词解释

类型	解释
Broker	KAFKA 的消费处理节点，每一个 kafka 节点就是一个broker, 一个完整的 KAFKA 有1个或者 N 个 broker 组成
Controller	controller 节点也是一个 KAFKA broker 节点，一个集群中只会存在一个 controller 节点，用于管理集群整体的元数据信息
Topic	Kafka 对消息进行归类，发送到集群的每一条消息都要指定一个 topic
Partition	逻辑上每个 topic 包含一个或 多个 partition，物理上一个 partition 对应 Broker 本地磁盘的一个文件夹，这个文件夹下存储 partition 的数据和索引文件信息，每个partition内部是有序的
Zookeeper	Kafka 集群的元数据持久化存储，负责controler 选举、partition 分配consumer 等工作，在最新版本的 Kafka 里面 再逐渐的使用了raft 来替代 zookeeper
Producer	消息的生产者, 主动发生消息到 KAFKA 集群
Consumer	消息的消费者，从Broker 拉取消息到 客户端进行消费
Consumer Group	每个consumer 都属于一个特定的 Consumer Group，每个Consumer属于一个特定的Consumer Group，一条消息可以发送到多个不同的Consumer Group，但是一个Consumer Group中只能有一个Consumer能够消费该消息

2.4 重要特性介绍

（1） 日志存储

kafka一个topic下面的所有消息都是以partition的方式分布式的存储在多个节点上。同时在kafka的机器上，每个Partition其实都会对应一个日志目录，在目录下面会对应多个日志分段(LogSegment)。LogSegment文件由两部分组成，分别为“.index”文件和“.log”文件，分别表示为segment索引文件和数据文件。这两个文件的命令规则为：partition全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值，数值大小为64位，20位数字字符长度，没有数字用0填充，如下，假设有1000条消息，每个LogSegment大小为100，下面展现了900-1000的索引和Log：

（2）消息可靠性保证机制

如何保证 KAFKA 消息的高可靠性，不会轻易的出现消息的丢失以及错乱等等？
服务侧
KAFKA 服务侧保证消息高可靠的机制是副本同步机制，核心思想是数据的冗余备份
每个partition 会存在多个副本（1个Leader 副本，多个Follower 副本）, Leader 实际对接业务的读写请求，Follower 则实时的从Leader 节点上拉取对应 Partition 的数据到本地进行存储，一旦 partiton Leader 所对应的节点发生故障，出现宕机等case, 读写请求会被转移到其他正常节点上。由于Follower 也存在数据，保证了数据的不丢和服务的可用性。
问题来了，请求应该转移到哪一个Follower 节点上，一旦Follower 节点数据来不及同步，是不是数据就丢失了？
第一点、kafka 不是所有的Follower 都能成为备选节点，KAFKA 里面维护了 ISR 集合，只有在ISR 列表里面的Follower 才有资格成为备选节点。 ，在这个集合中的需要满足两个条件:
节点必须和ZK保持连接
在同步的过程中这个副本不能落后主副本太多。
当然，这种机制无法做到数据的百分百不丢失，一旦所有的Follower 节点都没有跟上 Leader，那么一旦发送切换，数据就实际丢失了。如何避免这种case, KAFKA 在生产侧也做了一些机制来保证

生产侧
ack 机制
producer 在将数据写入到 KAFKA 的时候会携带ACK 信息,ack 具体含义如下

ack	含义
0	数据发送出去即结束，不关心写入成功或者失败
1	数据必须成功写入 Partition Leader 节点才算写入成功
-1/all	数据必须写入 Partiton的 所有副本节点才算是写入成功（这里还需要搭配下服务侧的min,isr 配置，可以保证数据的完全不丢失，但是性能上会有些损失）

retry 机制
在生产消息发送失败的时候可以重新发送，retry 决定了最大的重试次数，一旦重发多少次都失败才算真正的写入失败
性能和数据的高可用的平衡是一个很难兼容的问题

3、参数文献

1、你必须要知道的 kafka.
2、kafka 官网
3、kafka 核心技术.