Kafka简介

参考文档：http://kafka.apache.org/intro

简介

官方说Kafka是一个分布式的流平台（distributed streaming platform，并没有说自己时一个消息中间件），主要由以下关键能力

• 发布和订阅记录流，类似于消息队列或企业消息系统
• 容错且持久的存储记录流
• 记录流出现时快速处理

Kafka适用于两类应用

• 构建实时流数据管道，已在系统应用间可靠的获取数据
• 构建对流数据进行转换或响应的实时流应用

概念和特性

• Kafka可以作为集群运行在跨越多个数据中心的多台服务器上
• 主题(Topic):Kafka集群将记录流分类储存在Topic中
• 记录：每个记录包含一个键，一个值和一个时间戳

Kafka有四类核心API

• Producer API:允许应用发布记录流到一个或多个主题
• Consumer API:允许应用订阅一个或多个主题并处理生产到这些主题的记录流
• Stream API:允许应用作为一个流处理器，作为消费者从一个或多个主题消费数据，并作为生产者将消费结果输出到一个或者多个主题。从而有效的转换输入流到输出流
• Connector API:将一个已存在的应用或者数据系统作为可重用的生产者或者消费者连接到Kafka的主题上。例如：连接到数据库将捕获表的每一个改变。

主题和日志

主题是记录被发布到的一个分类或者feed流名称。主题可以有0、1或多个消费者订阅。

对于每个主题，Kafka集群维护了一个分区日志，如下图：

每个分区都是有序且顺序不可变的记录集合，新纪录将持续新增到日志的尾部。每个分区的记录都被分配一个序列ID叫做offset,offset在一个分区是记录的唯一标识符。

Kafka不断持久化所有发布的记录(无论记录是否被消费)，并可配置保留周期。例如，如果保留策略设置为2天，记录发布两天内可以被消费，超过两天记录将被抛弃以释放空间。Kafka的性能是与数据大小无关的恒定值，因此长时间存储数据并不会产生性能问题。

问题

1. 大量的消费者是否会产生性能问题？
2. 不同消费者使用数据的offset跨度太大是否会产生性能问题。
3. 记录的长度难以确定，offset更可能只是一个序列号而不是物理位置偏移量，如果高性能找到下一条记录

实际上，每个消费者基本的元数据只包含offset或者消费日志的位置。offset是有消费者控制的，通常消费者在读取记录时会线性推进offset，当然也可以按照任意设置offset获取记录。例如：一个消费者可以重设offset到一个老的点以重新处理数据，或者跳过最近的记录至今处理当前点以后的记录。

以上设计意味着消费者是很轻量级的，他们对集群或其他消费者没有太大影响。

分区日志的设计有以下目的

• 一个主题的数据量可能超过单台服务器的容量，一个主题的多个分区可以位于不同服务器上，可以通过增加分区，增大主题的数据容量。
• 分区日志增加了系统的并行性

分发

日志分区被分配到集群的多台主机上，每个主机都可以处理数据和请求。每个分区都可以配置复制服务器数量，以实现容错。

多个复制的分区中，有一台主机作为leader，0或多个主机作为followers。leader处理分区所有读写请求，followers只是被动地从leader复制数据，如果leader宕机，一个follower会自动提升为主。每个主机都会成为一个分区的主并作为其他分区的从，因此负载能够很好的在集群内均衡。

地理复制

Kafka MirrorMaker 提供了集群地理复制功能。通过MirrorMaker，消费可以跨多个数据中心或云区域复制。可以用于主备备份和恢复，也可以用于多主场景让数据更接近你的用户，或者支持数据本地化需求。

也可以用于多主场景让数据更接近你的用户,对于这句话，个人感觉只能更接近消费者，因为只是单向复制，对消费者无影响，生产者不适用于单向复制

生产者

生产者负责将数据发布到他们选择的topics中，生产者还可以选择将哪个消费发布到topic的哪个分区中。

• 可以使用轮询模式以简单的均衡负载
• 也可以使用分区函数

消费者

消费者组：消费者实例被标识在一个消费者组中。Topic中的每个记录只能被多个订阅的消费者组消费，但每个消费者组中只能由一个消费者实例消费。

• 如果所有的消费者实例都在一个消费者组中，则记录将在所有消费实例间负载均衡
• 如果所有消费者实例都在不同的消费者组中，则记录将被广播到所有消费者进程。
  

分配的实现方式

为组内的每个消费者实例分配日志分区，以便每个消费者实例在任意时间点都是分区公平份额（相对）的排他使用者。

Kafka协议动态维护组内实例和日志分区的关系

• 如果有新的消费者实例加入组，新实例将从组内其他成员接管一部分分区
• 如果消费者退出组，他说管理的分区将被分配到组内其他消费者实例

注意：一个消费者组中消费者的数量不能大于分区的数量，否则将有消费者一直闲置

记录顺序性

Kafka只在分区内提供记录的顺序性，在一个topic的不同分区见不存在记录顺序性。每个分区内的记录顺序对于大多数应用是足够的。如果需要记录的完全顺序性，只能在topic内只使用一个分区，但这也意味每个消费者组内只能由一个消费者（分区的实现方式决定了这一点）

多租户

可以将Kafka部署为多租户解决方案。通过配置哪些主题可以产生或使用数据来启用多租户。配额也有运营支持。管理员可以在请求上定义和实施配额，以控制客户端使用的代理资源。

保证

Kafka给予以下保证

• 由同一个生产者发送的记录在一个主题内一个分区中的顺序与他们的发送顺序是相同的。如果记录M1和M2由同一个生产者发送，M1先发送，M1和M2并发送到同一个分区，则M1的offset低于M2
• 消费者实例看见记录的顺序和日志存储的顺序相同
• 如果一个主题复制了N份，当N-1个服务宕机时不会丢失任何被提交到日志的记录

作为消息系统使用

传统消息系统的问题

queue

可以将数据负载均衡到对个消费者实例，扩展了处理能力，但一旦消息被处理，就无法被再次处理

发布定义

允许广播数据到多个处理器，但由于每个消息都被发给所有订阅者，无法扩展负载

Kafka改进

• Kafka具备queue和发布定义的能力
• Kafka的发布订阅，不是发布到所有消费者实例，而是发布到所有消费者组，每个消费者组可以有多个消费者实例来负载均衡。
• 保障消息顺序性同时增强了并行能力。传统消息系统保障消息顺序性要求只能由一个消费者，Kafka多个分区可以有对多个并行的消费者。

作为存储系统使用

• Kafka将数据写入磁盘并复制实现容错功能
• Kafka允许生产者等待确认，在所有分区上复制完成并写入成功后才会发送成功确认
• 得益于Kafka的磁盘架构，无论是50KB还是50TB持久数据，Kafka都可以获得同样的处理性能。
• Kafka允许用户控制读取位置，因此可以将其视为高性能、低延迟提交、支持复制和传播的分布式文件系统

作为流处理使用

仅读取，写入和存储数据流是不够的，目的是实现对流的实时处理。

在Kafka中，流处理器是指从输入主题中获取连续数据流，对该输入进行一些处理并生成连续数据流以输出主题的任何东西。

例如，零售应用可以接受销售和运输的输入流，并输出根据此数据计算出的重新订购和价格调整流。

可以直接使用生产者和消费者API进行简单处理。但对于更复杂的转换，Kafka提供了完全集成的Streams API。这允许构建执行非重要处理的应用程序，这些应用程序计算流的聚合或将流连接在一起。

该功能有助于解决此类应用程序所面临的难题：处理无序数据，在代码更改时重新处理输入，执行状态计算等。

流API建立在Kafka提供的核心原语之上：它使用生产者和使用者API进行输入，使用Kafka进行状态存储，并使用相同的组机制来实现流处理器实例之间的容错。