Kafka简介（一）
一、入门
1.1 绪论
Kafka是一个分布式流处理平台。为什么？
一个流处理平台有三个关键能力：
- 发布和订阅流式记录，类似于消息队列或企业级消息系统
- 以高容错方式存储流记录
- 当流记录出现时处理它
kafka适用于两种类型的应用：
- 构建实时流数据处理管道，使其能够可靠地从系统或应用中获取数据
- 构建实时流应用能够转换或对流数据进行反应
首先一些概念：
- kafka以集群的方式运行在一至多个服务器上，并能够扩展多个数据中心
- kafka集群以一种叫topics的形式存储流式记录
- 每条记录都拥有一个key，value，一个时间戳
四种API：
- Producer API 允许应用发布一条流数据到一个或多个Kafka topic
- Consumer API 允许应用订阅一个或多个topic并处理为他们生产的流记录
- Streams API 允许应用作为一个流处理器，从一个或多个topic消费一个输入流，有效的将输入流转换成输出流
- Connector API 允许构建或运行科重用的生产者或消费者，连接Kafka到现有的应用或数据系统。例如，一个连接到一个关系型数据库的connector可能捕获一张表的任何变动。
在kafka中，客户端和服务器之间的通信通过一个简单、高性能、语言无关的TCP协议。该协议进行了版本控制，并与旧版本保持向后兼容。我们也为Kafka提供了一个Java Client，但是client也可以用其他很多种语言的形式。
Topics and Logs
一个topic是一个目录或者说一个信息流的名字，用于发布记录。Kafka中的topic总是有多个订阅者；也就是说，一个topic能拥有0个，1个或多个订阅写入该topic的数据的消费者。
对于每个topic，Kafka集群维护一个分片的日志，如下图所示：
每个分片都是一个不断被追加的，有序的、不变的记录序列–一个结构化提交日志。分片中的每条记录都分配了一个被称作偏移量（offset）的序列号，用来独立的标识分片中的每条记录。
Kafka集群持续的持有所有的发布的记录–不管其有没有被消费–一段时间，该时间可配置。比如，如果该时间被设置为2天，那么当该消息发布两天以后，它能够被消费，消费或它将被丢弃以释放空间。Kafka的性能相对于数据大小来说是稳定的，所以长时间存储数据不是问题。
实际上，存储在每个消费者基础上的唯一元数据仅为消费者在日志中的偏移量或者位置。该偏移量由该消费者控制：一般一个消费者将线性地提前它的偏移量随着它的读，但是，事实上，因为这个位置有该消费者控制，所以它可以按照它喜欢的顺序消费记录。例如，一个消费者可以重置到一个先前的位置，来重新处理来自过去的数据，或者跳过最近的数据而是从“当前”数据开始消费。
这种功能特性意味着Kafka的消费者非常的cheap–他们的来和去将不会对集群上的其他消费者造成任何影响。例如你可以中庸命令行工具来“tail”任意topic的内容，而不改变其他消费者消费的东西。
日志中的分片有多重目的。首先，它们允许日志扩展到适合单个服务器的大小。每个独立的分片必须能够适合持有它的服务器的大小，但是一个topic可能会有很多个分片，所以他可以处理任意数量的数据。其次它可以作为并行处理单元–稍后详细介绍。
分布
日志分片分布在kafka集群的各个服务器上，每个服务器共同处理分片的数据和请求。每个分片以配置好的一个数字，复制到不同的服务器上，为了容错。
每个分片拥有一台作为“leader”的服务器，其它的0至多个服务器作为“followers”。leader处理该分片的所有读写请求 ，而followers被动的复制leader。如果leader宕机了，其它的followers中的一个将自动成为新的leader。每个服务器都作为一些分片的leader，一些分片的follower，所以集群的负载得以均衡。
地理副本
Kafka MirrorMaker为你的集群提供地理复制支持。通过MirrorMaker，消息在多个数据中心或云区域之间复制。你可以使用这个用于主动或被动的备份恢复场景；或者在主动/被动场景中,把数据更加靠近你的用户，或提供数据区域性需求。
生产者
生产者根据选择向topic发布他们的数据。生产者负责选择把哪条记录插入到topic的哪个分片中。这个可以通过轮询的方式来简单的达到负载均衡的目的，或者也可以通过某些带有语义的分片函数来达到负载均衡（比如说基于记录的某些key值）。稍后将介绍分区的更多用法!
消费者
消费者自己选择加入一个消费者组，并且发布到一个topic的每条记录都会推送到一个订阅该topic的消费者组的一个消费者示例。消费者示例能够在另一个单独的进程或是一个独立的机器中。
如果所有的消费者都在同一个消费者组之间，那么记录将有效的在消费者示例间负载均衡。
如果所有的消费者示例拥有不同的消费者组，那么每条记录都会广播到所有的消费者进程。
两个服务器Kafka集群承载4个分区(P0-P3)和两个消费者组。消费者组A有两个消费者实例，而B组有四个。
然而，更常见的是，我们发现主题有少量的消费者组，每个“逻辑订阅方”有一个消费者组。每个组由许多为了可伸缩性和容错的使用者实例组成。这只不过是发布-订阅模式语义，其中订阅者是一组消费者，而不是单个进程。
Kafka实现消费的方式是通过把分片上的log向消费者示例分发，使得每个消费实例都能在任意时刻公平的占有分片。维护这个关系的进程由kafka动态处理。如果有新的实例加入，它会从组内的其他成员那里获得一些分片；如果有实例宕机了，那么它的分片会由剩余的实例瓜分。
Kafka只在一个分片内保持顺序，而不是在一个topic的不同分片上。能够通过key值分区数据的分片内有序对于大多数应用来说已经足够用了。然而，如果你要求记录的完全有序，那么可以通过一个topic仅有一个分片来实现，尽管这将意味着每个消费者组只有一个消费进程。
多租户
kafka支持多租户策略，通过配置哪个topic能够产生或消费数据。还有对配额的操作支持。管理员可以对控制客户机使用的代理资源的请求定义和强制配额。有关更多信息，请参阅安全文档。
保证
Kafka在高水平上提供了以下保证:
- 由生产者发送到特定topic分片的消息将按发送顺序追加。也就是说，如果记录M1是由与记录M2相同的生产者发送的，并且M1是首先发送的，那么M1的偏移量将低于M2，并且在日志中出现得更早。
- 使用者实例看到的是记录存储在日志中的顺序。
- 对于一个拥有N个副本的topic，我们将容忍最多N-1服务器故障，而不会丢失提交到日志的任何记录。
关于这些保证的更多细节在文档的设计部分给出。
Kafka作为一个消息系统
Kafka作为一个存储系统
Kafka用于流处理
把碎片拼在一起