Kafka介绍

Kafka概况

Kafka经常被认为是一个流式系统, 具备流式系统的基本特征; 那么流式系统应该具备哪些特征呢, 流式系统的基本特征可以大致概括成以下几点:

• 可以发布和订阅消息记录, 有点类似传统的消息系统
• 可以容错式地保存消息记录
• 在消息记录出现的时候可以处理消费这些记录

Kafka当前被大规模地使用在以下两种类型的系统上:

• 构建实时流式数据管道, 用于在系统和应用程序间可靠的传递数据
• 构建实时流式数据处理程序, 用于实时地处理流数据

Kafka一般运行在由多台机器构成的集群上, 通过”主题”(Topic)将消息记录按不同的类型进行分别存储, Kafka的消息记录由”键”、”值”和“时间戳”三元组构成。

Kafka的核心API由四部分组成：

• Producer API: 用于发布消息记录到指定的主题
• Consumer API: 用于订阅主题，消费订阅主题对应的消息记录
• Streaming API: 使用Streaming API时应用程序变成流处理器，消费指定主题上的消息，将处理后消息记录发布到新的输出流上
• Connector API: 将指定主题绑定到已有的系统或者程序上，例如关系型数据库的Connector将会捕获表数据的任何变化

Kafka客户端和服务端间通过一个基于TCP的简单、高效的协议通讯，该协议保证了向后兼容。

---

主题和日志

Kafka通过Topic(主题)实现对消息记录的分类，一个Topic(主题)可以被多个Subscriber（订阅者）订阅。通常一个Topic(主题)可以没有订阅者，一个至多个订阅者订阅消息。

Kafka中的每一个Topic(主题)都由集群中的多个分区维护，每个分区是一组有序的、不可变的消息记录构成。新记录都是按顺序添加到分区中，分区中的每一个消息记录都由offset(偏移量)这个唯一的标识符标识记录在分区中的位置。Kafka集群根据配置持久化保存已经发布的消息记录（即使消息已经被消费过）。

每一个Kafka客户端通过维持一个标识消费记录的指针(offset)记录当前已经消费的消息位置。由于offset是由客户端维持，所以客户端可以根据需要线性地消费消息记录也可以重新消费已经消费过的消息记录。分区机制的设计使得Kafka集群可以在单台机器达到容量时通过添加机器快速的扩充Topic对应的容量。

分区分布

Kafka分区分布在构成集群的所有机器上，每台机器负责管理若干个分区的数据和请求。Kafka通过在集群多个机器备份各个分区的数据实现容错功能，每个分区都会在集群中选择一个机器作为“leader”负责该分区的所有读和写请求，同时选择若干个机器作为“follower”备份“leader”的数据。在“leader”机器发生故障或则出现问题时，Kafka会从作为备份的“follower”的机器中选择一个作为新的“leader”。Kafka集群中的每台机器在成为若干个分区“leader”的同时也会成为若干其他分区的“follower”，通过这种方式的安排实现了Kafka集群的负载均衡。

Producer

Producer主要负责将消息记录发布到指定的Topic上。Producer可以通过Round-Robin的方式均匀地将消息发布到Topic上的各个分区上，也可以通过其他更复杂的方式将消息发布到指定分区上。

Consumer

Kafka中注册消息消费的实体是Consumer Group，一个Consumer Group一般由若干个Consumer实例组成。Consumer Group中的Consumer实例可以是一个进程也可以是独立的机器。当所有的Consumer实例都在同一个Consumer Group中时，集群的所有消息将均匀的分配到Consumer Group中的各个Consumer实例进行消费。当每个Consumer实例都单独组成一个Consumer Group时，那么每个Consumer实例都可以消费集群中发布的所有消息。

Kafka默认通过使用“Topic的分区数量除以Consumer Group中Consumer实例数量”这个规则，将Topic中已经发布的消息路由到指定的Consumer实例进行消费。所以Consumer Group中的各个Consumer实例只能消费指定若干个分区的消息。当新的Consumer实例加入到Consumer Group中，新的Consumer实例将接管部分分区消息的消费。在部分Consumer实例退出Consumer Group或者出现故障时，Consumer Group中的其他Consumer实例将接管这几个分区消息的消费。

Kafka只保证单个分区内消息的顺序，不保证Topic内所有分区消息的整体顺序。该特性能够满足大部分应用程序的需求，在应用程序需要保证消息的全局有序的情况下，可以将Topic设置成只有一个分区，那么应用程序可以有序的消费Producer生产的所有消息。

Kafka特性

Kafka提供了以下几点保证：

• Producer发布到Topic指定分区的消息按照它们发布的顺序有序地添加到分区中
• Consumer在Topic指定分区中看到的消息都是按照发布顺序存储
• Topic的备份系数为N时，N - 1台机器出现故障不会导致存储消息的丢失

Kafka的应用

Kafka作为消息传递系统

传统的消息系统有队列和订阅发布两种模式。在队列模式中多个Consumer从队列中读取消息，每个消息只被一个Consumer处理，而在订阅发布模式中消息将广播给多个消费者。这两种方式都有各自的优点和缺点，队列模式允许多个消费者共同消费消息，这种方式便于扩充处理规模，但是该模式不能实现多个订阅者同时消费消息，只要一个Consumer消费了消息，消息就终止了。而订阅发布模式因为将消息广播给多个订阅者，所以不能通过扩充多个消费者共同消费消息。

Kafka的Consumer Group综合了队列模式和订阅发布模式的优点，组成Consumer Group的多个Consumer实例可以共同消费Consumer Group订阅的消息，而多个Consumer Group又可以同时订阅的Topic消息。相对于传统的消息传递系统，Kafka拥有更强的消息顺序保证能力。

传统的消息队列有序的存储消息，消息队列按照消息存储的顺序有序的发送给多个消费者。虽然消息队列服务端按顺序将消息发送给多个消费者，但是由于消息的发送是异步的，所以有可能消费者接收到的消息不是有序的。这也就是并行消费过程中消息发生了乱序，传统的消息队列系统一般是保留一个消费者以保证消息的消费是有序的。

Topic分区的设计保证了消息的有序消费和多个Consumer消费消息的负载均衡。通过将Topic中各个分区分配给Consumer Group中各个对应的Consumer消费，使得Topic中每个分区的消息都由Consumer Group中唯一的一个Consumer消费，从而保证了消息消费的有序性。该机制保证一个分区的消息在Consumer Group中由唯一一个Consumer按分区中消息存储顺序有序消费。但是Consumer Group中消费者的数量不能超过订阅Topic对应的分区数量。

Kafka作为存储系统

Kafka接收的消息都会被存储到磁盘并进行容错处理，Kafka在Producer发布的消息成功持久化并同步到其他“follower”上时才给Producer成功的应答。Kafka采用的持久化结构十分便于扩充，所以无论是存储50KB数据还是50TB数据，Kafka集群都能正常运行。基于Kafka良好的消息存储能力和允许Consumer控制消息的读取位置的特性，Kafka可以作为一款高性能、低时延的消息存储、备份和传递的分布式系统。

Kafka作为流处理系统

除了消息的发布、订阅和存储，Kafka还可以作为流处理系统。Kafka的流处理器持续从输入Topic获取消息，经过加工处理后将输出消息持续发布到输出Topic上。虽然可以直接使用Kafka提供的Producer API和Consumer API实现流处理，但是Kafka本身提供了更为强大的Streaming API。Kafka的Streaming API可以提供包括消息计算聚合操作和流join操作在内的丰富的功能。Kafka的流处理基于Kafka核心的基本功能，包括使用Producer API和Consumer API处理输入输出，使用Kafka的状态存储功能存储数据和容错机制为多个流实现容错功能。