Kafka原理解析

朱雀 2022-03-08 17:19 469阅读 0赞

> 本文转发自[**技术世界**][Link 1]，[原文链接][Link 2]　[http://www.jasongj.com/2015/01/02/Kafka深度解析][Link 2]

# 背景介绍 #

## Kafka简介 ##

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

*  以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能
 *  高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输
 *  支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输
 *  同时支持离线数据处理和实时数据处理

## 为什么要用消息系统 ##

*  **解耦**  
    在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束
 *  **冗余**  
    有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。在被许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理过程明确的指出该消息已经被处理完毕，确保你的数据被安全的保存直到你使用完毕。
 *  **扩展性**  
    因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的；只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
 *  **灵活性 & 峰值处理能力**  
    在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
 *  **可恢复性**  
    当体系的一部分组件失效，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。而这种允许重试或者延后处理请求的能力通常是造就一个略感不便的用户和一个沮丧透顶的用户之间的区别。
 *  **送达保证**  
    消息队列提供的冗余机制保证了消息能被实际的处理，只要一个进程读取了该队列即可。在此基础上，部分消息系统提供了一个”只送达一次”保证。无论有多少进程在从队列中领取数据，每一个消息只能被处理一次。这之所以成为可能，是因为获取一个消息只是”预定”了这个消息，暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息，否则这个消息会被放回队列中去，在一段可配置的时间之后可再次被处理。

*  **顺序保证**  
    在大多使用场景下，数据处理的顺序都很重要。消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。部分消息系统保证消息通过FIFO（先进先出）的顺序来处理，因此消息在队列中的位置就是从队列中检索他们的位置。
 *  **缓冲**  
    在任何重要的系统中，都会有需要不同的处理时间的元素。例如,加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行–写入队列的处理会尽可能的快速，而不受从队列读的预备处理的约束。该缓冲有助于控制和优化数据流经过系统的速度。
 *  **理解数据流**  
    在一个分布式系统里，要得到一个关于用户操作会用多长时间及其原因的总体印象，是个巨大的挑战。消息队列通过消息被处理的频率，来方便的辅助确定那些表现不佳的处理过程或领域，这些地方的数据流都不够优化。
 *  **异步通信**  
    很多时候，你不想也不需要立即处理消息。消息队列提供了异步处理机制，允许你把一个消息放入队列，但并不立即处理它。你想向队列中放入多少消息就放多少，然后在你乐意的时候再去处理它们。

# Kafka解析 #

## Terminology ##

*  **Broker**  
    Kafka集群包含一个或多个服务器，这种服务器被称为broker
 *  **Topic**  
    每条发布到Kafka集群的消息都有一个类别，这个类别被称为topic。（物理上不同topic的消息分开存储，逻辑上一个topic的消息虽然保存于一个或多个broker上但用户只需指定消息的topic即可生产或消费数据而不必关心数据存于何处）
 *  **Partition**  
    parition是物理上的概念，每个topic包含一个或多个partition，创建topic时可指定parition数量。每个partition对应于一个文件夹，该文件夹下存储该partition的数据和索引文件
 *  **Producer**  
    负责发布消息到Kafka broker
 *  **Consumer**  
    消费消息。每个consumer属于一个特定的consumer group（可为每个consumer指定group name，若不指定group name则属于默认的group）。使用consumer high level API时，同一topic的一条消息只能被同一个consumer group内的一个consumer消费，但多个consumer group可同时消费这一消息。

## Kafka架构 ##

[![kafka architecture 架构][kafka architecture]][kafka architecture]  
　　如上图所示，一个典型的kafka集群中包含若干producer（可以是web前端产生的page view，或者是服务器日志，系统CPU、memory等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干consumer group，以及一个[Zookeeper][]集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在consumer group发生变化时进行rebalance。producer使用push模式将消息发布到broker，consumer使用pull模式从broker订阅并消费消息。

### Push vs. Pull ###

作为一个messaging system，Kafka遵循了传统的方式，选择由producer向broker push消息并由consumer从broker pull消息。一些logging-centric system，比如Facebook的[Scribe][]和Cloudera的[Flume][],采用非常不同的push模式。事实上，push模式和pull模式各有优劣。  
　　push模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。

### Topic & Partition ###

Topic在逻辑上可以被认为是一个queue。每条消费都必须指定它的topic，可以简单理解为必须指明把这条消息放进哪个queue里。为了使得Kafka的吞吐率可以水平扩展，物理上把topic分成一个或多个partition，每个partition在物理上对应一个文件夹，该文件夹下存储这个partition的所有消息和索引文件。  
　　[![kafka topic partition][]][kafka topic partition]  
　　每条消息都被append到该partition中，是顺序写磁盘，因此效率非常高（经验证，顺序写磁盘效率比随机写内存还要高，这是Kafka高吞吐率的一个很重要的保证）。  
　　[![kafka partition][]][kafka partition]  
　　每一条消息被发送到broker时，会根据paritition规则选择被存储到哪一个partition。如果partition规则设置的合理，所有消息可以均匀分布到不同的partition里，这样就实现了水平扩展。（如果一个topic对应一个文件，那这个文件所在的机器I/O将会成为这个topic的性能瓶颈，而partition解决了这个问题）。在创建topic时可以在`$KAFKA_HOME/config/server.properties`中指定这个partition的数量(如下所示)，当然也可以在topic创建之后去修改parition数量。

# The default number of log partitions per topic. More partitions allow greater
    
    # parallelism for consumption, but this will also result in more files across
    
    # the brokers.
    
    num.partitions=3

在发送一条消息时，可以指定这条消息的key，producer根据这个key和partition机制来判断将这条消息发送到哪个parition。paritition机制可以通过指定producer的paritition. class这一参数来指定，该class必须实现`kafka.producer.Partitioner`接口。本例中如果key可以被解析为整数则将对应的整数与partition总数取余，该消息会被发送到该数对应的partition。（每个parition都会有个序号）

import kafka.producer.Partitioner;
    
    import kafka.utils.VerifiableProperties;
    
    public class JasonPartitioner<T> implements Partitioner {
    
        public JasonPartitioner(VerifiableProperties verifiableProperties) {}
    
            @Override
    
            public int partition(Object key, int numPartitions) {
    
                try {
    
                    int partitionNum = Integer.parseInt((String) key);
    
                    return Math.abs(Integer.parseInt((String) key) % numPartitions);
    
                } catch (Exception e) {
    
                return Math.abs(key.hashCode() % numPartitions);
    
            }
    
        }
    
    }

如果将上例中的class作为partitioner.class，并通过如下代码发送20条消息（key分别为0，1，2，3）至topic2（包含4个partition）。

public void sendMessage() throws InterruptedException{
    
    　　for(int i = 1; i <= 5; i++){
    
    　　 List messageList = new ArrayList<KeyedMessage<String, String>>();
    
    　　 for(int j = 0; j < 4; j++）{
    
    　　 messageList.add(new KeyedMessage<String, String>("topic2", j+"", "The " + i + " message for key " + j));
    
    　　 }
    
    　　 producer.send(messageList);
    
    }
    
    　　producer.close();
    
    }

则key相同的消息会被发送并存储到同一个partition里，而且key的序号正好和partition序号相同。（partition序号从0开始，本例中的key也正好从0开始）。如下图所示。  
　　[![kafka partition key][]][kafka partition key]  
　　对于传统的message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否。当然，因为磁盘限制，不可能永久保留所有数据（实际上也没必要），因此Kafka提供两种策略去删除旧数据。一是基于时间，二是基于partition文件大小。例如可以通过配置`$KAFKA_HOME/config/server.properties`，让Kafka删除一周前的数据，也可通过配置让Kafka在partition文件超过1GB时删除旧数据，如下所示。

############################# Log Retention Policy #############################
    
    # The following configurations control the disposal of log segments. The policy can
    
    # be set to delete segments after a period of time, or after a given size has accumulated.
    
    # A segment will be deleted whenever *either* of these criteria are met. Deletion always happens
    
    # from the end of the log.
    
    # The minimum age of a log file to be eligible for deletion
    
    log.retention.hours=168
    
    # A size-based retention policy for logs. Segments are pruned from the log as long as the remaining
    
    # segments don't drop below log.retention.bytes.
    
    #log.retention.bytes=1073741824
    
    # The maximum size of a log segment file. When this size is reached a new log segment will be created.
    
    log.segment.bytes=1073741824
    
    # The interval at which log segments are checked to see if they can be deleted according
    
    # to the retention policies
    
    log.retention.check.interval.ms=300000
    
    # By default the log cleaner is disabled and the log retention policy will default to
    
    #just delete segments after their retention expires.
    
    # If log.cleaner.enable=true is set the cleaner will be enabled and individual logs
    
    #can then be marked for log compaction.
    
    log.cleaner.enable=false

**Replication & Leader election**

Kafka从0.8开始提供partition级别的replication，replication的数量可在`$KAFKA_HOME/config/server.properties`中配置。

default.replication.factor = 1

默认情况下，Kafka的replication数量为1。每个partition都有一个唯一的leader，所有的读写操作都在leader上完成，leader批量从broker上pull数据。一般情况下partition的数量大于等于broker的数量，并且所有partition的leader均匀分布在broker上。follwer不断复制leader的内容，使得follower上的日志和其leader上的完全一样。  
         follower异步的从leader复制数据，数据只要被leader写入log就被认为已经commit，这种情况下如果follwer都落后于leader，而leader突然宕机，则会丢失数据。而Kafka的这种使用“in sync” list的方式则很好的均衡了确保数据不丢失以及吞吐率。follower可以批量的从leader复制数据，这样极大的提高复制性能（批量写磁盘），极大减少了follower与leader的差距。  
        当leader宕机了，在follower中选举出新的leader。

### Consumer group ###

（本节所有描述都是基于consumer hight level API而非low level API）。  
　　每一个consumer实例都属于一个consumer group，每一条消息只会被同一个consumer group里的一个consumer实例消费。（不同consumer group可以同时消费同一条消息）  
　　[![kafka consumer group][]][kafka consumer group]  
　　  
　　很多传统的message queue都会在消息被消费完后将消息删除，一方面避免重复消费，另一方面可以保证queue的长度比较少，提高效率。而如上文所将，Kafka并不删除已消费的消息，为了实现传统message queue消息只被消费一次的语义，Kafka保证保证同一个consumer group里只有一个consumer会消费一条消息。与传统message queue不同的是，Kafka还允许不同consumer group同时消费同一条消息，这一特性可以为消息的多元化处理提供了支持。实际上，Kafka的设计理念之一就是同时提供离线处理和实时处理。根据这一特性，可以使用Storm这种实时流处理系统对消息进行实时在线处理，同时使用Hadoop这种批处理系统进行离线处理，还可以同时将数据实时备份到另一个数据中心，只需要保证这三个操作所使用的consumer在不同的consumer group即可。下图展示了Kafka在Linkedin的一种简化部署。  
　　[![kafka deployment in linkedin][]][kafka deployment in linkedin]  
　　为了更清晰展示Kafka consumer group的特性，笔者作了一项测试。创建一个topic (名为topic1)，创建一个属于group1的consumer实例，并创建三个属于group2的consumer实例，然后通过producer向topic1发送key分别为1，2，3r的消息。结果发现属于group1的consumer收到了所有的这三条消息，同时group2中的3个consumer分别收到了key为1，2，3的消息。如下图所示。  
　　[![kafka consumer group][kafka consumer group 1]][kafka consumer group 1]

### Consumer Rebalance ###

（本节所讲述内容均基于Kafka consumer high level API）  
　　Kafka保证同一consumer group中只有一个consumer会消费某条消息，实际上，Kafka保证的是稳定状态下每一个consumer实例只会消费某一个或多个特定partition的数据，而某个partition的数据只会被某一个特定的consumer实例所消费。这样设计的劣势是无法让同一个consumer group里的consumer均匀消费数据，优势是每个consumer不用都跟大量的broker通信，减少通信开销，同时也降低了分配难度，实现也更简单。另外，因为同一个partition里的数据是有序的，这种设计可以保证每个partition里的数据也是有序被消费。  
　　如果某consumer group中consumer数量少于partition数量，则至少有一个consumer会消费多个partition的数据，如果consumer的数量与partition数量相同，则正好一个consumer消费一个partition的数据，而如果consumer的数量多于partition的数量时，会有部分consumer无法消费该topic下任何一条消息。  
　　如下例所示，如果topic1有0，1，2共三个partition，当group1只有一个consumer(名为consumer1)时，该 consumer可消费这3个partition的所有数据。  
　　[![kafka consumer group rebalance][]][kafka consumer group rebalance]  
　　增加一个consumer(consumer2)后，其中一个consumer（consumer1）可消费2个partition的数据，另外一个consumer(consumer2)可消费另外一个partition的数据。  
　　[![kafka consumer group rebalance][kafka consumer group rebalance 1]][kafka consumer group rebalance 1]  
　　再增加一个consumer(consumer3)后，每个consumer可消费一个partition的数据。consumer1消费partition0，consumer2消费partition1，consumer3消费partition2  
　　[![kafka consumer group rebalance][kafka consumer group rebalance 2]][kafka consumer group rebalance 2]  
　　再增加一个consumer（consumer4）后，其中3个consumer可分别消费一个partition的数据，另外一个consumer（consumer4）不能消费topic1任何数据。  
　　[![kafka consumer group rebalance][kafka consumer group rebalance 3]][kafka consumer group rebalance 3]  
　　此时关闭consumer1，剩下的consumer可分别消费一个partition的数据。  
　　[![kafka consumer group][kafka consumer group 2]][kafka consumer group 2]  
　　接着关闭consumer2，剩下的consumer3可消费2个partition，consumer4可消费1个partition。  
　　[![kafka consumer group][kafka consumer group 3]][kafka consumer group 3]  
　　再关闭consumer3，剩下的consumer4可同时消费topic1的3个partition。  
　　[![kafka consumer group][kafka consumer group 4]][kafka consumer group 4]

consumer rebalance算法如下：

*  Sort PT (all partitions in topic T)
 *  Sort CG(all consumers in consumer group G)
 *  Let i be the index position of Ci in CG and let N=size(PT)/size(CG)
 *  Remove current entries owned by Ci from the partition owner registry
 *  Assign partitions from i*N to (i+1)*N-1 to consumer Ci
 *  Add newly assigned partitions to the partition owner registry

[Link 1]: http://www.jasongj.com/
[Link 2]: http://www.jasongj.com/2015/01/02/Kafka%E6%B7%B1%E5%BA%A6%E8%A7%A3%E6%9E%90
[kafka architecture]: /images/20220308/40d2652fb33c48c4ad51cbe0d759151e.png
[Zookeeper]: http://zookeeper.apache.org/
[Scribe]: https://github.com/facebookarchive/scribe
[Flume]: http://flume.apache.org/
[kafka topic partition]: /images/20220308/7460c39d9a324863bb4f3f117fd460de.png
[kafka partition]: /images/20220308/5caf51ea35564b5b9ce3fe01d67e77c4.png
[kafka partition key]: /images/20220308/1d2fb9ee2f5048909162e1e20c184776.png
[kafka consumer group]: /images/20220308/245acc326a0e436085bc4de0651fc0ba.png
[kafka deployment in linkedin]: /images/20220308/c298e58d3823445b9334acb48fc14e82.png
[kafka consumer group 1]: /images/20220308/b346677001c549558ead58cffd1da86a.png
[kafka consumer group rebalance]: /images/20220308/c114fa3204d244d3bf279cfd37939db8.png
[kafka consumer group rebalance 1]: /images/20220308/1dc55bad2080453686aabc06fd77249a.png
[kafka consumer group rebalance 2]: /images/20220308/c82527e3051c4b008f9091f9a090ac05.png
[kafka consumer group rebalance 3]: /images/20220308/30cff4cc61784dd9982c80c47a75e87c.png
[kafka consumer group 2]: /images/20220308/7ce03281d518410d92080ec1ba746866.png
[kafka consumer group 3]: /images/20220308/a4625a7426b34b86abf47c82f2710831.png
[kafka consumer group 4]: /images/20220308/6ffc9f8b2c3246b5834db6ed4f4caf58.png