kafka是一个分布式流系统
我们认为流系统有三个关键因素：
可以像消息队列或者企业消息系统一样发布订阅数据流；
以容错的方式存储数据流；
数据流产生的同时就可以处理。
kafka主要有两大应用场景：
用于系统或应用之间可靠地传递数据的实时数据流管道;
构建传递数据流的实时流应用。
为了理解kafka是怎么处理这些事情的，让我们自底向上地来探索kafka的功能吧.
几个基本概念：
kafka以集群模式运行在一个或多个服务器上;
kafka集群以topics存储数据流;
每一个数据由key，value和timestamp组成。
kafka 4个核心API：
Producer API 允许一个应用发布数据流到一个或多个topics;
Consumer API 允许一个应用订阅一个或多个topics并且处理数据流；
Streams API允许一个应用充当流设备，从一个或多个topics上消费输入流，产生一个到一个或多个topics的输出流，有效地转换输入流到输出流；
Connector API 允许构建并且运行多个可复用的、连接kafka topics到现存的应用或数据库系统。比如，连接到关系型数据库的connector可能捕获一个表的每一次变化。
在kafka中，客户端和服务端通信是通过一个简单的、高性能的、语言无关的TCP协议。此协议是
版本化的并且兼容老版本。我们提供了一个Java客户端，但是客户端可以用多种语言实现。
Topics and Logs
我们首先投入kafka为处理数据流而提供的核心抽象——topic。
topic是发布的数据流的一个分类。Topics通常有多个订阅者；一个topic可以有0,1或者多个消费者订阅。
对于每个topic，kafka集群维护一个分区化的log：
每个分区都是一个有序的、不断追加记录的不变序列——一个结构化的提交日志。
分区中的每个记录都被分配一个叫offset的连续id号，这个offset在分区内是唯一的。
kafka集群用一个可配置的保存期保存所有的已发布数据，不管数据是否被消费。比如，如果保存
期设为2天，那么该数据被发布后2天时间内都是可消费的，2天后为了释放空间而被丢弃。即使考
虑数据大小，kafka的性能也是恒定不变的，所以保存数据很长时间根本不是个问题。
事实上，存放在每个消费者那儿的唯一元数据就是offset或者是消费者在log中的position。
offset是由消费者控制的：通常消费者顺序访问数据，offset线性增长。但是消费者也可以按任意
顺序访问。比如，一个消费者可以reset到一个老数据上重新处理或者跳到最新的数据上或者从当
前位置。
这种组合的特性意味着kafka消费者是微不足道的。消费者是否消费对整个集群或者其他的消费者
没有太大的影响。比如，你可以用命令行工具将任意topic的内容的position指定到尾部，但是不
会改变其他存在的消费者的消费内容。
日志中的分区有多个目的。首先，它们允许超过大小限制的日志发送到一个单独的服务器上。每
个单独的分区必须受限制于它所在的服务器的容量大小，但是topic有多个分区，因此可以处理任
意数量的数据。其次，它们可以作为并行单元。
Distribution
日志中的分区分布在kafka集群中多个服务器上，每个服务器处理数据和请求。每个分区为了容
错，以一个可配置的服务器数量复制。
每个分区有一个leader服务器，0或者多个follower服务器。leader处理分区所有的读写请求，但
是follower只能被动地同步leader。如果leader挂了，followers会选举出一个自动成为新的
leader。每一个服务器既可以作为一个分区的leader也可以作为另一个分区的follower，因此集
群负载均衡。
Producers
生产者给选择的topics发布数据。它负责将哪个记录分配到topic的哪个分区中。它以一种循环的
方式简单地平衡负载或者按照一些语义分区函数来进行。
Consumers
消费者用消费组来分类，发布到topic中的每条记录被传递到订阅此记录的消费组中的一个消费实
例。消费者实例可以是一个单独的进程或者单独的机器。
如果所有的消费者实例是同一个消费组，那么所有的消费记录实际上被所有的消费者实例均衡负载。
如果所有的消费者实例都在不同的消费组中，那么每条记录都会broadcast到所有的消费进程中。
其实，意思就是说消费者是生产-消费模式，消费组是发布——订阅模式。
一个2台机器的kafka集群有4个分区（P0-P3）和2个消费组。消费组A有2个消费实例，消费组B
有4个。
我们发现topics有少量的消费组，每一个都是一个“逻辑订阅者”。每个组为了扩展和容错，有
多个消费实例组成。这还是一个发布——订阅模式，只不过订阅者是一个由多个消费者组成的集
群，而不是一个单独的进程。
这种消费方式在kafka中是这样被实现的，每个消费组获取到所有的分区后，根据消费实例数分割
分区，以致于在任何时候每个实例都是独有的分区消费者。在消费组中，这个关系的处理是由
kafka协议动态实现的。如果新实例加入，它们会从其他实例中拿取一些分区；如果实例挂了，它
的分区会被分配到其他存活的实例中。
kafka仅仅提供一个分区内的排序，而不是topic不同分区间的排序。每个分区的排序结合按key分
割数据的技巧在大多数应用中是充分的。可是，如果你需要一个总排序，那么可以通过一个topic
一个分区实现，这也就意味着每个消费组只有一个消费进程。
Guarantees
kafka有如下保障机制：
由生产者发送到特定topic分区的消息会按发送的顺序追加。也就是说，如果记录M1和M2由同一个生产者发送，M1先发送，那么M1会有一个低的offset并且在日志中比M2出现早;
一个消费实例以记录在日志的顺序有序查看记录；
对于一个复制因子为N的topic，可以容忍N-1个服务器故障，而不丢失任意记录提交日志。