（一）Kafka基本概念

为什么有消息系统：

削峰：用于承接超出业务系统处理能力的请求，使业务平稳运行而不至于崩溃。
缓冲：在服务层和落地层之间作为缓冲层存在，有助于控制和优化数据流过系统的速度，可以解决生产消息和消费消息速度不一致的情况。
异步：使用异步的方式，快读响应用户的操作，减少服务请求的响应时间。
解耦：消息队列可以作为一个接口层，解耦重要业务流程。只需要遵守约定，针对数据编程即可获取扩展能力。
冗余：消息数据能够采用一对多的方式，供多个毫无关联的业务使用。
健壮性：消息队列在消费端出现问题的时候，能够堆积消息，待消费端恢复好后，可以继续消费，保证了主要业务的正常运行。
顺序保证：在多数场景下数据处理的顺序很重要。大部分的队列本身具有排序的功能，能保证数据会按照特定的顺序处理。kafka能够保证一个Partion内的消息的有序性。

Kafka简介：

Apach Kafka是一个快速、可扩展、高吞吐、可容错的分布式“发布-订阅”消息系统，使用Scala与Java语言编写，能够将消息从一端传到另一端。相较于传统的消息中间件（例如ActiveMQ、RabbitMQ）, Kafka具有高吞吐量，内置分区，支持消息副本和高容错的特性，主要用于大数据实时处理领域。

Kafka特性：

1 高吞吐、低延迟：接受消息非常快，Kafka每秒可以处理几十万条消息，最低延迟只有几十毫秒

2 高伸缩性：每个主题包含多个分区，主题中的分区可以分布在不同的broker中，可以增加或减少broker节点，或者可以增加或者减少分区数。

3 持久性与可靠性：Kafka允许数据的持久化存储（segment），消息被持久化到磁盘（尽管是到磁盘，但由于是顺序写非常快），并支持数据备份防止数据丢失（follower 副本数据同步实现）。

4 容错性：允许某个节点宕机，集群仍然可以正常工作。

5 高并发：支持数千个客户端同时读写。

Kafka体系架构

Producer（生产者）：发送消息的一方，负责创建消息，然后投递给Kafka

Consumer（消费者）：接收消息的一方。消费者连接到Kafka上并接收消息，然后进行相应的业务逻辑处理。

Broker(服务代理节点)：对于Kafka而言，可以将Broker简单地看作一个独立的Kafka服务节点或者服务实例。大多数情况下可将它看作一台独立的服务器，前提是这台服务器只部署了一个Kafka实例。一个或者多个Broker组成了一个Kafka集群。

Zookeeper:负责管理Kafka集群，选举Leader, 在Consumer Group发生变化时进行reblance动作。

主题（Topic）：Kafka中的消息以主题为单位进行分类，生产者将消息发送到特定的主题。消费者负责订阅主题并进行消费。

分区（Partition）：主题从逻辑上又可以细分为多个分区，分区在存储层面可以看作是一个可追加的日志（Log）文件, 当消息被追加到分区日志文件的时候都会分配一个特定的而偏移量（offset）。offset是消息在分区中的唯一标识，Kafka通过它来保证消息在分区内的顺序性。Kafka中的分区可以分布在不同的服务器（Broker）上，也就是说一个主题可以跨越多个Broker, 由此来实现kafka的高伸缩性、可靠性、容错性及高并发 。

由图中可以看出，多个生产者可以同时将消息投递给Kafka, 在投递的过程中经过算法计算，最后将这条消息写入到某个broker的leader分区，然后follower分区会紧跟着进行同步。

多个Consumer可以同时消费消息，单个消费者消费消息是从leader 分区中拉取消息。这样通过分区，能够实现消息的并发写入与读取。

Kafka多副本

Kafka为分区引入了多副本（Replica）机制，通过增加副本数量可以提升容灾能力。同一个分区的不同副本保存的消息是相同的，副本之间是“一主多从”的关系，leader副本负责读写请求。follower副本只负责与leader副本的消息同步。副本位于不同的broker中，当leader副本出现故障时，会从follower副本中重新选举新的leader副本对外提供服务。这就实现了故障的自动转移，当某个Partion_leader失效时，仍然可以保证该分区的消息被消费，从而实现了数据的备份恢复作用。

Kafka多副本架构.jpg

Kafka高吞吐率实现：

如前所述，Kafka拥有高吞吐低延时的特性，然后对于Kafka这个消息中间件，数据是存储在磁盘中的，那么又是如何实现高吞吐率的呢？下面将从几个方面进行分析：

批量发送：kafka允许批量发送消息。【利用CPU时间换取磁盘空间和网络传输速率】。
消息压缩：kafka支持对消息集合进行压缩。通常来说解压缩发生在消费者程序中，也就是说 Producer 发送压缩消息到 Broker 后，Broker 照单全收并原样保存起来。当 Consumer 程序请求这部分消息时，Broker 依然原样发送出去，当消息到达 Consumer 端后，由 Consumer 自行解压缩还原成之前的消息。Kafka 会将启用了哪种压缩算法封装进消息集合中，这样当 Consumer 读取到消息集合时，它自然就知道了这些消息使用的是哪种压缩算法。消息压缩参考文章：kafka消息压缩与解压。
顺序读写：kafka将某个topic的消息是写入到分区的，而分区中是按顺序不断追加文件末尾的，而读消息也是通过offset顺序读的，因此对于一个分区来说，读写消息都是顺序的。而磁盘的顺序读写能够高于内存的随机读写。
page Cache（页缓存）：kafka利用了操作系统的Page Cache，也就是操作系统的内存而不是JVM的内存空间。这样就避免了垃圾回收带来的问题。此外还避免了Object的消耗，如果使用Java堆，Java对象的内存消耗比较大，通常是所存储数据的两倍甚至更多。
零拷贝：kafka利用操作系统的”零拷贝“（zero-copy）机制，在IO读写过程中，减少了不必要的拷贝次数，优化了消费端的读取速度。
批量拉取: 消费者可以批量拉取一批消息消费，减少了网络传输的消耗。

ZooKeeper介绍：

ZooKeeper是一个开源的分布式协调服务，是Google Chubby的一个开源实现。分布式应用程序可以基于ZooKeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、配置维护等功能。在ZooKeeper中共有3个角色：leader、follower和observer，同一时刻 ZooKeeper集群中只会有一个leader，其他的都是follower和observer。observer不参与投票，默认情况下 ZooKeeper 中只有 leader 和 follower 两个角色。

Kafka通过ZooKeeper来实施对元数据信息的管理，包括集群、broker、主题、分区等内容。kafka master控制节点监听zookeeper上关于broker、主题、分区等相关节点的变化。