Kafka笔记 - HelloWorld开发者社区

第1章 Kafka简介

1.1 kafka起源

Kafka是由LinkedIn开发并开源的分布式消息系统，2012年捐赠给Apache基金会，采用Scala语言，运行在JVM中，最新版本1.0.0。

1.2 kafka设计目标

Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下：

①以时间复杂度O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。

②高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒10万条以上消息的传输。

③支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输。

④同时支持离线数据处理和实时数据处理。

⑤Scale out：支持在线水平扩展。

1.3 为何使用消息系统

消息系统有如下好处：解耦、冗余、扩展性、灵活性&峰值处理能力、可恢复性、顺序保证、缓冲、异步通信。

1.4 RabbitMQ、ActiveMQ和Kafka的区别

Kafka笔记

第2章 Kafka架构

2.1 kafka术语

①Topic

用于划分Message的逻辑概念，一个Topic可以分布在多个Broker上。

②Partition

是Kafka中横向扩展和一切并行化的基础，是物理上的概念，每个Topic都至少被切分为1个Partition。

③Offset

消息在Partition中的编号，编号顺序不跨Partition。

④Consumer

用于从Broker中取出/消费Message。

⑤Consumer Group

每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。

⑥Producer

用于往Broker中发送/生产Message。

⑦Replication

Kafka支持以Partition为单位对Message进行冗余备份，每个Partition都可以配置至少1个Replication(当仅1个Replication时即仅该Partition本身)。

⑧Leader

每个Replication集合中的Partition都会选出一个唯一的Leader，所有的读写请求都由Leader处理。其他Replicas从Leader处把数据更新同步到本地，过程类似大家熟悉的MySQL中的Binlog同步。

⑨Broker

Kafka集群包含一个或多个服务器，这种服务器被称为broker。Kafka中使用Broker来接受Producer和Consumer的请求，并把Message持久化到本地磁盘。每个Cluster当中会选举出一个Broker来担任Controller，负责处理Partition的Leader选举，协调Partition迁移等工作。

⑩ISR(In-Sync Replica)

是Replicas的一个子集，表示目前Alive且与Leader能够“Catch-up”的Replicas集合。由于读写都是首先落到Leader上，所以一般来说通过同步机制从Leader上拉取数据的Replica都会和Leader有一些延迟(包括了延迟时间和延迟条数两个维度)，任意一个超过阈值都会把该Replica踢出ISR。每个Partition都有它自己独立的ISR。

2.2 kafka拓扑结构

一个典型的Kafka集群中包含多个Producer，多个broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），多个Consumer Group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance（再平衡）。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。

Kafka笔记

2.3 kafka高吞吐量的黑科技

kafka实现高性能吞吐的秘密主要有三点：

①磁盘顺序IO

由于消息系统读写的特殊性，Kafka在磁盘上只做Sequence I/O。关于磁盘I/O的性能，Kafka官方给出的测试数据(Raid-5，7200rpm)为：Sequence I/O: 600MB/s；Random I/O: 100KB/s 。

②PageCache

操作系统提供的PageCache功能。当上层有写操作时，操作系统只是将数据写入PageCache，同时标记Page属性为Dirty。当读操作发生时，先从PageCache中查找，如果发生缺页才进行磁盘调度，最终返回需要的数据。实际上PageCache是把尽可能多的空闲内存都当做了磁盘缓存来使用。同时如果有其他进程申请内存，回收PageCache的代价又很小，所以现代的OS都支持PageCache。

直接使用PageCache功能而不是在JVM内部缓存数据，可带来如下好处：避免频繁GC（当Full GC时会影响可用性）、内存占用空间翻倍（Java堆和PageCache都有同一份数据）、避免Kafka进程重启Java堆里数据失效（PageCache仍然可用）。

③Sendfile技术

数据从磁盘读出并通过网络Socket发送出去这个过程，如果采用Sendfile技术，可以避免数据在内核空间和用户空间的无用拷贝。

如果没有sendfile技术，数据流如下：

OS 从硬盘把数据读到内核区的PageCache。
用户进程把数据从内核区Copy到用户区。
然后用户进程再把数据写入到Socket，数据流入内核区的Socket Buffer上。
OS 再把数据从Buffer中Copy到网卡的Buffer上，这样完成一次发送。

Kafka笔记

经过Sendfile优化后，整个I/O过程如下：

Kafka笔记

④offset无锁消费

Kafka会为每一个Consumer Group保留一些metadata信息——当前消费的消息的position，也即offset。这个offset由Consumer控制。正常情况下Consumer会在消费完一条消息后递增该offset。当然，Consumer也可将offset设成一个较小的值，重新消费一些消息。因为offet由Consumer控制，所以Kafka broker是无状态的，它不需要标记哪些消息被哪些消费过，也不需要通过broker去保证同一个Consumer Group只有一个Consumer能消费某一条消息，因此也就不需要锁机制，这也为Kafka的高吞吐率提供了有力保障。

第3章 Topic & Partition

3.1 Topic和Partition简介

Topic在逻辑上可以被认为是一个queue，每条消息都必须指定它的Topic，可以简单理解为必须指明把这条消息放进哪个queue里。为了使得Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件。

每个日志文件都是一个log entry序列，每个log entry包含一个4字节整型数值（值为N+5），1个字节的”magic value”，4个字节的CRC校验码，其后跟N个字节的消息体。每条消息都有一个当前Partition下唯一的64字节的offset，它指明了这条消息的起始位置。

这个log entry并非由一个文件构成，而是分成多个segment，每个segment以该segment第一条消息的offset命名并以“.kafka”为后缀。另外会有一个索引文件，它标明了每个segment下包含的log entry的offset范围，如下图所示：

Kafka笔记

因为每条消息都被append到该Partition中，属于顺序写磁盘，因此效率非常高。

Kafka笔记

3.2 消息删除

对于传统的message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否。当然，因为磁盘限制，不可能永久保留所有数据（实际上也没必要），因此Kafka提供两种策略删除旧数据。一是基于时间，二是基于Partition文件大小。

因为Kafka读取特定消息的时间复杂度为O(1)，即与文件大小无关，所以这里删除过期文件与提高Kafka性能无关。

3.3 Partition特点

Partition是Kafka可以很好的横向扩展和提供高并发处理以及实现Replication的基础。

①扩展性方面

首先，Kafka允许Partition在集群内的Broker之间任意移动，以此来均衡可能存在的数据倾斜问题。其次，Partition支持自定义的分区算法，例如可以将同一个Key的所有消息都路由到同一个Partition上去。同时Leader也可以在In-Sync的Replica中迁移。由于针对某一个Partition的所有读写请求都是只由Leader来处理，所以Kafka会尽量把Leader均匀的分散到集群的各个节点上，以免造成网络流量过于集中。

② 并发方面

任意Partition在某一个时刻只能被一个Consumer Group内的一个Consumer消费(反过来一个Consumer则可以同时消费多个Partition)，Kafka非常简洁的Offset机制最小化了Broker和Consumer之间的交互，这使Kafka并不会像同类其他消息队列一样，随着下游Consumer数目的增加而成比例的降低性能。此外，如果多个Consumer恰巧都是消费时间序上很相近的数据，可以达到很高的PageCache命中率，因而Kafka可以非常高效的支持高并发读操作，实践中基本可以达到单机网卡上限。

3.4 Partition过多引起的问题

Partition的数量并不是越多越好，Partition的数量越多，平均到每一个Broker上的数量也就越多，会导致如下问题：

①Broker宕机(Network Failure, Full GC)的情况下，需要由Controller来为所有宕机的Broker上的所有Partition重新选举Leader，Partition数量太多会Leader选举耗时过长。

②Controller角色的Broker宕机，首先要进行的是重新任命一个Broker作为Controller。新任命的Controller要从Zookeeper上获取所有Partition的Meta信息，Partition数量太多会导致获取时间过长。另外获取完后还要进行上一步的Leader选举。

③在Broker端，对Producer和Consumer都使用了Buffer机制。其中Buffer的大小是统一配置的，数量则与Partition个数相同。如果Partition个数过多，会导致Producer和Consumer的Buffer内存占用过大。

Partition规划提示：

①Partition的数量尽量提前预分配，虽然可以在后期动态增加Partition，但是会冒着可能破坏Message Key和Partition之间对应关系的风险。

②Replica的数量不要过多，如果条件允许尽量把Replica集合内的Partition分别调整到不同的Rack。

③尽一切努力保证每次停Broker时都可以Clean Shutdown，否则问题就不仅仅是恢复服务所需时间长，还可能出现数据损坏或其他很诡异的问题。

第4章 Producer

4.1 Partition分区优点

消息生产时，采用Partition分区的优点如下：

①实现消息生产时负载均衡

Producer发送消息到broker时，会根据Paritition机制选择将其存储到哪一个Partition。如果Partition机制设置合理，所有消息可以均匀分布到不同的Partition里，这样就实现了负载均衡。

②消息并行写入提高吞吐量

如果一个Topic对应一个文件，那这个文件所在的机器I/O将会成为这个Topic的性能瓶颈，而有了Partition后，不同的消息可以并行写入不同broker的不同Partition里，极大的提高了吞吐量。

4.2 Producer消息路由

在发送一条消息时，可以指定这条消息的key，Producer根据这个key和Partition机制来判断应该将这条消息发送到哪个Parition。Paritition机制可以通过指定Producer的paritition. class这一参数来指定，该class必须实现kafka.producer.Partitioner接口。

4.2 Producer端优化

Producer端的优化思路有两种：批量发布、同步变异步，关闭ACK全速发送。

①批量发布

Kafka系统默认支持MessageSet，把多条Message自动地打成一个Group后发送出去，均摊后拉低了每次通信的RTT(Round-Trip Time 往返时延)。而且在组织MessageSet的同时，还可以把数据重新排序，从爆发流式的随机写入优化成较为平稳的线性写入。

Producer支持End-to-End的压缩。数据在本地压缩后放到网络上传输，在Broker一般不解压(除非指定要Deep-Iteration)，直至消息被Consume之后在客户端解压。

第5章 Consumer

5.1 Consumer Group

使用Consumer high level API时，同一Topic的一条消息只能被同一个Consumer Group内的一个Consumer消费，但多个Consumer Group可同时消费这一消息。

这是Kafka用来实现一个Topic消息的广播（发给所有的Consumer）和单播（发给某一个Consumer）的手段。一个Topic可以对应多个Consumer Group。如果需要实现广播，只要每个Consumer有一个独立的Group就可以了。要实现单播只要所有的Consumer在同一个Group里。用Consumer Group还可以将Consumer进行自由的分组而不需要多次发送消息到不同的Topic。

Kafka的设计理念之一就是同时提供离线处理和实时处理。只需要保证离线和实时操作所使用的Consumer属于不同的Consumer Group即可。

Kafka笔记

5.2 Push vs. Pull

push模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快速度传递消息，但是这样很容易造成Consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据Consumer的消费能力以适当的速率消费消息。

对于Kafka而言，pull模式更合适。pull模式可简化broker的设计，Consumer可自主控制消费消息的速率，同时Consumer可以自己控制消费方式——即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。

5.3 Kafka delivery guarantee

Kafka的delivery guarantee有三种：

①At most once 最多一次。消息可能会丢，但绝不会重复传输

读完消息先commit再处理消息。这种模式下，如果Consumer在commit后还没来得及处理消息就crash了，下次重新开始工作后就无法读到刚刚已提交而未处理的消息，这就对应于At most once。

②At least one 最少一次。消息绝不会丢，但可能会重复传输

读完消息先处理再commit。这种模式下，如果在处理完消息之后commit之前Consumer crash了，下次重新开始工作时还会处理刚刚未commit的消息，实际上该消息已经被处理过了。这就对应于At least once。

③Exactly once 精确一次。每条消息肯定会被传输一次且仅传输一次，很多时候这是用户所想要的。

如果一定要做到Exactly once，就需要协调offset和实际操作的输出。经典的做法是引入两阶段提交。如果能让offset和操作输入存在同一个地方，会更简洁和通用。

Kafka默认保证At least once，并且允许通过设置Producer异步提交来实现At most once。而Exactly once要求与外部存储系统协作，幸运的是Kafka提供的offset可以非常直接非常容易得使用这种方式。

5.4 High level和Low level

Consumer API分为High level和Low level两种。前一种重度依赖Zookeeper，所以性能差一些且不自由，但是超省心。第二种不依赖Zookeeper服务，无论从自由度和性能上都有更好的表现，但是所有的异常(Leader迁移、Offset越界、Broker宕机等)和Offset的维护都需要自行处理。

5.5 如何保证kafka的高容错性？

①producer不使用批量接口，并采用同步模型持久化消息。

②consumer不采用批量化，每消费一次就更新offset。

第6章 Kafka高可用

6.1 为什么需要Replication

在没有Replication的情况下，一旦某机器宕机或者某个Broker停止工作则其上所有的Partition数据都不可被消费，会造成整个系统的可用性降低。

6.2 Replica之间为什么需要Leader Election

引入Replication之后，同一个Partition可能会有多个Replica，而这时需要在这些Replica中选出一个Leader，Producer和Consumer只与这个Leader交互，其它Replica作为Follower从Leader中复制数据。

因为需要保证同一个Partition的多个Replica之间的数据一致性和有序性。

6.3 Replica均匀分配算法

为了更好的做负载均衡，Kafka尽量将所有的Partition均匀分配到整个集群上。一个典型的部署方式是一个Topic的Partition数量大于Broker的数量。同时为了提高Kafka的容错能力，也需要将同一个Partition的Replica尽量分散到不同的机器。

Kafka分配Replica的算法如下：

①将所有Broker（假设共n个Broker）和待分配的Partition排序。

②将第i个Partition分配到第（i mod n）个Broker上。

③将第i个Partition的第j个Replica分配到第（(i + j) mod n）个Broker上。

6.4 Propagate消息

Producer在发布消息到某个Partition时，先通过Zookeeper找到该Partition的Leader，然后无论该Topic的Replication Factor为多少（也即该Partition有多少个Replica），Producer只将该消息发送到该Partition的Leader。Leader会将该消息写入其本地Log。每个Follower都从Leader pull数据。这种方式上，Follower存储的数据顺序与Leader保持一致。Follower在收到该消息并写入其Log后，向Leader发送ACK。一旦Leader收到了ISR中的所有Replica的ACK，该消息就被认为已经commit了，Leader将增加HW（HighWaterMark，Partition的高水位）并且向Producer发送ACK。

为了提高性能，每个Follower在接收到数据后就立马向Leader发送ACK，而非等到数据写入Log中。因此，对于已经commit的消息，Kafka只能保证它被存于多个Replica的内存中，而不能保证它们被持久化到磁盘中，也就不能完全保证异常发生后该条消息一定能被Consumer消费。但考虑到这种场景非常少见，可以认为这种方式在性能和数据持久化上做了一个比较好的平衡。在将来的版本中，Kafka会考虑提供更高的持久性。

Consumer读消息也是从Leader读取，只有被commit过的消息（offset低于HW的消息）才会暴露给Consumer。

6.4 ACK前需要保证有多少个备份

Kafka存活包含两个条件，一是它必须维护与Zookeeper的session(这个通过Zookeeper的Heartbeat机制来实现)。二是Follower必须能够及时将Leader的消息复制过来，不能“落后太多”。

Leader会跟踪与其保持同步的Replica列表，该列表称为ISR（即in-sync Replica）。如果一个Follower宕机，或者落后太多，Leader将把它从ISR中移除。这里所描述的“落后太多”指Follower复制的消息落后于Leader后的条数超过预定值，或者Follower超过一定时间未向Leader发送fetch请求。

Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。事实上，同步复制要求所有能工作的Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率（高吞吐率是Kafka非常重要的一个特性）。而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下如果Follower都复制完都落后于Leader，而如果Leader突然宕机，则会丢失数据。而Kafka的这种使用ISR的方式则很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，这样极大的提高复制性能（批量写磁盘），极大减少了Follower与Leader的差距。

一条消息只有被ISR里的所有Follower都从Leader复制过去才会被认为已提交。这样就避免了部分数据被写进了Leader，还没来得及被任何Follower复制就宕机了，而造成数据丢失（Consumer无法消费这些数据）。而对于Producer而言，它可以选择是否等待消息commit，这可以通过request.required.acks来设置。这种机制确保了只要ISR有一个或以上的Follower，一条被commit的消息就不会丢失。

6.5 Leader Election算法

一种非常常用的Leader Election的方式是“Majority Vote”（“少数服从多数”），但Kafka并未采用这种方式。这种模式下，如果我们有2f+1个Replica（包含Leader和Follower），那在commit之前必须保证有f+1个Replica复制完消息，为了保证正确选出新的Leader，fail的Replica不能超过f个。因为在剩下的任意f+1个Replica里，至少有一个Replica包含有最新的所有消息。

Majority Vote优点：系统的延迟时间只取决于最快的几个Broker，而非最慢那个。

Majority Vote缺点：为了保证较高的容错程度，必须要有大量的Replica，而大量的Replica又会在大数据量下导致性能的急剧下降。

为了保证Leader Election的正常进行，它所能容忍的fail的follower个数比较少。如果要容忍1个follower挂掉，必须要有3个以上的Replica，如果要容忍2个Follower挂掉，必须要有5个以上的Replica。这就是这种算法更多用在Zookeeper这种共享集群配置的系统中，而很少在需要存储大量数据的系统中使用的原因。

Kafka在Zookeeper中动态维护了一个ISR（in-sync replicas），这个ISR里的所有Replica都跟上了leader，只有ISR里的成员才有被选为Leader的可能。在这种模式下，对于f+1个Replica，一个Partition能在保证不丢失已经commit的消息的前提下容忍f个Replica的失败。在大多数使用场景中，这种模式是非常有利的。事实上，为了容忍f个Replica的失败，Majority Vote和ISR在commit前需要等待的Replica数量是一样的，但是ISR需要的总的Replica的个数几乎是Majority Vote的一半。Majority Vote与ISR相比有不需等待最慢的Broker这一优势。

6.6 如何处理所有Replica都不工作

在ISR中至少有一个follower时，Kafka可以确保已经commit的数据不丢失，但如果某个Partition的所有Replica都宕机了，Kafka会选择第一个“活”过来的Replica（不一定是ISR中的）作为Leader。

6.7 如何选举Leader

（1）方案一：所有Follower都在Zookeeper上设置一个Watch，一旦Leader宕机，其对应的ephemeral znode会自动删除，此时所有Follower都尝试创建该节点，而创建成功者（Zookeeper保证只有一个能创建成功）即是新的Leader，其它Replica即为Follower。

此方案有3个缺点如下：

①split-brain 脑裂

这是由Zookeeper的特性引起的，虽然Zookeeper能保证所有Watch按顺序触发，但并不能保证同一时刻所有Replica“看”到的状态是一样的，这就可能造成不同Replica的响应不一致。

②herd effect 羊群效应

如果宕机的那个Broker上的Partition比较多，会造成多个Watch被触发，造成集群内大量的调整。

③Zookeeper负载过重

每个Replica都要为此在Zookeeper上注册一个Watch，当集群规模增加到几千个Partition时Zookeeper负载会过重。

（2）方案二：在所有broker中选出一个controller，所有Partition的Leader选举都由controller决定。controller会将Leader的改变直接通过RPC的方式（比Zookeeper Queue的方式更高效）通知需为此作出响应的Broker。同时controller也负责增删Topic以及Replica的重新分配。

第7章 Kafka数据可靠性与一致性

7.1 Partition Recovery机制

每个Partition会在磁盘记录一个RecoveryPoint，记录已经flush到磁盘的最大offset。当broker fail 重启时，会进行loadLogs。首先会读取该Partition的RecoveryPoint，找到包含RecoveryPoint的segment及以后的segment，这些segment就是可能没有完全flush到磁盘segments。然后调用segment的recover，重新读取各个segment的msg，并重建索引。

优点：

①以segment为单位管理Partition数据，方便数据生命周期的管理，删除过期数据简单。

②在程序崩溃重启时，加快recovery速度，只需恢复未完全flush到磁盘的segment。

③通过index中offset与物理偏移映射，用二分查找能快速定位msg，并且通过分多个Segment，每个index文件很小，查找速度更快。

7.2 Partition Replica同步机制

副本同步机制如下：

①Partition的多个replica中一个为Leader,其余为follower。

②Producer只与Leader交互,把数据写入到Leader中。

③Followers从Leader中拉取数据进行数据同步。

④Consumer只从Leader拉取数据。

ISR:所有不落后的replica集合, 不落后有两层含义:距离上次FetchRequest的时间不大于某一个值或落后的消息数不大于某一个值, Leader失败后会从ISR中选取一个Follower做Leader。

7.3 数据可靠性保证