Kafka简介

简介

Apache Kafka®是一个分布式流平台。这究竟是什么意思？
流平台有三个关键能力：

• 发布和订阅记录流，类似于消息队列或企业消息系统。
• 以容错稳定的方式存储记录流。
• 在记录流出现的时候就处理它们。

Kafka通常用两种常见的应用场景：

• 创建实时流数据管道，可靠的在系统或是应用之间获取数据。
• 创建实时流应用，传输或响应流数据。

先来些基本概念：

• Kafka可以跨越多个数据中心，在一个或多个服务品上组成集群。
• Kafka按分类存储记录流，这些分类称为topic
• 每条记录都有键、值、时间戳

Kafka有四个核心API：

• 生产者API：允许应用发布记录流到一个或多个topic
• 消费者API：允许应用订阅一个或多个topic，并处理相应的记录流。
• 流API：允许应用作为流处理器，从一个或多个topic中消费输入流，生成一个多或个topic的输出流。高效将输入转为输出。
• 连接器API： 允许创建并运行可重用的生产者和消费者，把topic与已有的应用或数据系统连接起来。。例如，到关系数据库的连接器可以捕获表的变更。

Kafka的CS通信使用的是简单、高效且语言无关的TCP协议。Apache Kafka的官方实现是Java客户端，也有其它语言实现

Topic 与日志

一个topic是所发布记录的类别或是推送名。topic总是有多个订阅者，即是说topic可以有0~N个消费者来订阅写入它的数据。

每一个topic，Kafka集群维护了一个分区的日志：

分区0：|0|1|2|3|4|5|6|7|8|9|10|11|12<-写入
分区1：|0|1|2|3|4|5|6|7|8|9<-写入
分区2：|0|1|2|3|4|5|6|7|8|9|10|11<-写入

每个分区都是有序、不可修改的连续增加的记录序列——结构化提交日志。分区中的记录都被赋予一个称为offset的顺列ID号，在该分区内唯一标识了每条记录。

不论每条记录是否被消费过，Kafka都持久保存了它们——当然可以配置一个保留时间。如保留时间设为2天，则一条记录发布2天后会被删除以腾出空间。Kafka的性能不会随数据大小的增加而变化。
事实上，基于每个消费者所保留的元数据只是该消费者在日志中的偏移或位置。这个偏移是由消费者控制的：通常消费者会线性增加它的偏移，但由于消费者可以控制位置，它是可以随意消费记录的。

分区日志的目的有多种：首先，这会允许日志伸缩超出单个服务器，单独的分区必须在服务器内，但topic可以拥有多个分区从而处理任意多的数据。其次，它们也是并发的一个单位。

分布式

日志的分区在集群的服务器之间布署，每个服务器处理数据和请求分区的一部分。每个分区都有可配置服务器数量 的复本从而保证容错。

每个分区都有一台服务器作为一个"leader",以及0~N台服务器作为"followers"。leader处理该分区的所有读写请求，而followers 被动复制leader。如果leader挂了，followers中的一个会自动成为新的leader。各服务器为位于其上的某些分区扮演leader，而对其它分区扮演follower从而让集群内实现负载均衡。

Geo-Replication

Kafka MirrorMaker 为集群提供了 geo-replication支持。通过MirrorMaker消息可以跨数据中心复制。可以利用它来主动/被动的进行备份和还原、让数据更靠近用户、或是满足数据本地化需求。

生产者

生产者发布数据到它们指定的topic。生产者可以通过轮询来平衡负载或是语义分区功能（比如基于记录中的某些key）来选择哪条记录发给topic中的哪个分区。。

消费者

消费者给自己标上一个消费者组名，每条发布到topic上的记录会分派到每个订阅组的某个消费者实例。消费者实现可以是多个进程，也可以分布在不同主机上

如果所有的消费者都是相同的组，则记录会被有效地负载平衡到每个消费者。
如果所有的消费者都是不同的组，则每条消息会在所有的消费者中广播。

Kafka中实现的消费方式是按消费者实例来分配日志中的分区，这样每个消费者实例在任何时候都是一个“均分”分区的唯一消费者。 这个维护组内成员关系的过程是通过Kafka协议来动态处理的。如果有新的实例加入组，它们会从别的组内成员接管一些分区，如果某个实例挂了，它的分区会分派给剩下的实例。

Kafka只保证一个分区内的记录的顺序，同一个话题不同分区之间是不保证顺序的。对于多数应用来说保证每个分区的顺序再加上用key来分区数据已经足够了。如果你的需求是完全的有序，则可以通过设置topic只有一个分区来达到你的目的，当然这同时意味着每个消费者组只能有一个消费者处理。