一. Kafka 基础概念
Kafka
Kafka 已被多家不同类型的公司作为多种类型的数据管道和消息系统使用。行为流数据是几乎所有站点在对其网站使用情况做报表时都要用到的数据中最常规的部分。
- 包括页面访问量 PV、页面曝光 Expose、页面点击 Click 等行为事件；
- 实时计算中的 Kafka Source，Dataflow Pipeline；
- 业务的消息系统，通过发布订阅消息解耦多组微服务，消除峰值；
Kafka 是由 LinkedIn 开发并开源的分布式消息系统，因其分布式及高吞吐率而被广泛使用，现已与Cloudera Hadoop，Apache Storm，Apache Spark集成。
Kafka 简介
Kafka 是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下：
- 以时间复杂度为 O(1) 的方式提供消息持久化能力，即使对 TB 级以上数据也能保证常数时间复杂度的访问性能；
- 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒 100K 条以上消息的传输；
- 支持 Kafka Server 间的消息分区，及分布式消费，同时保证每个 Partition 内的消息顺序传输；
- 同时支持离线数据处理和实时数据处理；
- Scale out：支持在线水平扩展；
为何使用消息系统
- 解耦 消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 而基于消息发布订阅的机制，可以联动多个业务下游子系统，能够不侵入的情况下分步编排和开发，来保证数据一致性。
- 冗余 有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
- 扩展性 因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
- 灵活性 & 峰值处理能力 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
- 可恢复性 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
- 顺序保证 在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka 保证一个 Partition 内的消息的有序性。
- 缓冲 在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行———写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。
- 异步通讯 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
二. Topic & Partition
Topic 在逻辑上可以被认为是一个 queue，每条消费都必须指定它的 Topic，可以简单理解为必须指明把这条消息放进哪个queue 里。我们把一类消息按照主题来分类，有点类似于数据库中的表。
为了使得 Kafka 的吞吐率可以线性提高，物理上把 Topic 分成一个或多个 Partition。对应到系统上就是一个或若干个目录。
Broken
Broker：Kafka 集群包含一个或多个服务器，每个服务器节点称为一个 Broker。
Broker 存储 Topic 的数据。如果某 Topic 有 N 个 Partition，集群有 N 个 Broker，那么每个 Broker 存储该 Topic 的一个 Partition。
从 scale out 的性能角度思考，通过 Broker Kafka server 的更多节点，带更多的存储，建立更多的 Partition 把 IO 负载到更多的物理节点，提高总吞吐 IOPS。
从 scale up 的角度思考，一个 Node 拥有越多的 Physical Disk，也可以负载更多的 Partition，提升总吞吐 IOPS。
如果某 Topic 有 N 个 Partition，集群有（N+M）个 Broker，那么其中有 N 个 Broker 存储该 Topic 的一个 Partition，剩下的 M 个 Broker 不存储该 Topic 的 Partition 数据。
如果某 Topic 有 N 个 Partition，集群中 Broker 数目少于 N 个，那么一个 Broker 存储该 Topic 的一个或多个 Partition。
Topic 只是一个逻辑概念，真正在 Broker间分布式的 Partition。
每一条消息被发送到 Broker 中，会根据 Partition 规则选择被存储到哪一个 Partition。如果 Partition 规则设置的合理，所有消息可以均匀分布到不同的 Partition中。
Broker & Partition
实验条件：3个 Broker，1个 Topic，无Replication，异步模式，3个 Producer，消息 Payload 为100字节： 当 Partition 数量小于 Broker个数时，Partition 数量越大，吞吐率越高，且呈线性提升。
Kafka 会将所有 Partition 均匀分布到所有Broker 上，所以当只有2个 Partition 时，会有2个 Broker 为该 Topic 服务。3个 Partition 时同理会有3个 Broker 为该 Topic 服务。
当 Partition 数量多于 Broker 个数时，总吞吐量并未有所提升，甚至还有所下降。可能的原因是，当 Partition 数量为4和5时，不同 Broker 上的 Partition 数量不同，而 Producer 会将数据均匀发送到各 Partition 上，这就造成各Broker 的负载不同，不能最大化集群吞吐量。
存储原理
Kafka 的消息是存在于文件系统之上的。Kafka 高度依赖文件系统来存储和缓存消息，一般的人认为 “磁盘是缓慢的”。
操作系统还会将主内存剩余的所有空闲内存空间都用作磁盘缓存，所有的磁盘读写操作都会经过统一的磁盘缓存（除了直接 I/O 会绕过磁盘缓存）。
Kafka 正是利用顺序 IO，以及 Page Cache 达成的超高吞吐。
任何发布到 Partition 的消息都会被追加到 Partition 数据文件的尾部，这样的顺序写磁盘操作让 Kafka 的效率非常高。
Kafka 集群保留所有发布的 message，不管这个 message 有没有被消费过，Kafka 提供可配置的保留策略去删除旧数据(还有一种策略根据分区大小删除数据)。
例如，如果将保留策略设置为两天，在 message 写入后两天内，它可用于消费，之后它将被丢弃以腾出空间。Kafka 的性能跟存储的数据量的大小无关， 所以将数据存储很长一段时间是没有问题的。
Offset：偏移量。每条消息都有一个当前 Partition 下唯一的 64 字节的 Offset，它是相当于当前分区第一条消息的偏移量，即第几条消息。
消费者可以指定消费的位置信息，当消费者挂掉再重新恢复的时候，可以从消费位置继续消费。
假设我们现在 Kafka 集群只有一个 Broker，我们创建 2 个 Topic 名称分别为：「Topic1」和「Topic2」，Partition 数量分别为 1、2。 那么我们的根目录下就会创建如下三个文件夹：
在 Kafka 的文件存储中，同一个 Topic 下有多个不同的 Partition，每个 Partition 都为一个目录。 而每一个目录又被平均分配成多个大小相等的 Segment File 中，Segment File 又由 index file 和 data file 组成，他们总是成对出现，后缀 ".index" 和 ".log" 分表表示 Segment 索引文件和数据文件。
其中以索引文件中元数据 <3, 497> 为例，依次在数据文件中表示第 3 个 Message（在全局 Partition 表示第 368769 + 3 = 368772 个 message）以及该消息的物理偏移地址为 497。
注意该 Index 文件并不是从0开始，也不是每次递增 1 的，这是因为 Kafka 采取稀疏索引存储的方式，每隔一定字节的数据建立一条索引。
它减少了索引文件大小，使得能够把 Index 映射到内存，降低了查询时的磁盘 IO 开销，同时也并没有给查询带来太多的时间消耗。
因为其文件名为上一个 Segment 最后一条消息的 Offset ，所以当需要查找一个指定 Offset 的 Message 时，通过在所有 Segment 的文件名中进行二分查找就能找到它归属的 Segment。
再在其 Index 文件中找到其对应到文件上的物理位置，就能拿出该 Message。
Kafka 是如何准确的知道 Message 的偏移的呢？ 这是因为在 Kafka 定义了标准的数据存储结构，在 Partition 中的每一条 Message 都包含了以下三个属性：
Offset：表示 Message 在当前 Partition 中的偏移量，是一个逻辑上的值，唯一确定了 Partition 中的一条 Message，可以简单的认为是一个 ID。
MessageSize：表示 Message 内容 Data 的大小。
Data：Message 的具体内容。
例如读取 offset=368776的 message，需要通过下面2个步骤查找。
第一步查找 segment file 上述图2为例，其中00000000000000000000.index 表示最开始的文件，起始偏移量(offset)为0。第二个文件00000000000000368769.index 的消息量起始偏移量为368770 = 368769 + 1，其他后续文件依次类推，以起始偏移量命名并排序这些文件，只要根据 offset 二分查找文件列表，就可以快速定位到具体文件。 当 offset=368776时定位到00000000000000368769.index | log。
第二步通过 segment file 查找 message 通过第一步定位到 segment file，当 offset=368776时，依次定位到00000000000000368769.index 的元数据物理位置和00000000000000368769.log 的物理偏移地址，然后再通过00000000000000368769.log 顺序查找直到offset=368776 为止。
Kafka 从0.10.0.0版本起，为分片日志文件中新增了一个 .timeindex 的索引文件，可以根据时间戳定位消息。同样我们可以通过脚本 kafka-dump-log.sh 查看时间索引的文件内容。
首先定位分片，将 1570793423501 与每个分片的最大时间戳进行对比（最大时间戳取时间索引文件的最后一条记录时间，如果时间为 0 则取该日志分段的最近修改时间），直到找到大于或等于 1570793423501 的日志分段，因此会定位到时间索引文件00000000000003257573.timeindex，其最大时间戳为 1570793423505。
重复 offset 找到 log 文件的步骤。
三. Producer & Consumer
Producer
Producer 发送消息到 Broker 时，会根据Paritition 机制选择将其存储到哪一个Partition。如果 Partition 机制设置合理，所有消息可以均匀分布到不同的 Partition里，这样就实现了负载均衡。
- 指明 Partition 的情况下，直接将给定的 Value 作为 Partition 的值。
- 没有指明 Partition 但有 Key 的情况下，将 Key 的 Hash 值与分区数取余得到 Partition 值。
- 既没有 Partition 有没有 Key 的情况下，第一次调用时随机生成一个整数（后面每次调用都在这个整数上自增），将这个值与可用的分区数取余，得到 Partition 值，也就是常说的 Round-Robin 轮询算法。
为保证 Producer 发送的数据，能可靠地发送到指定的 Topic，Topic 的每个 Partition 收到 Producer 发送的数据后，都需要向 Producer 发送 ACK。如果 Producer 收到 ACK，就会进行下一轮的发送，否则重新发送数据。
- 选择完分区后，生产者知道了消息所属的主题和分区，它将这条记录添加到相同主题和分区的批量消息中，另一个线程负责发送这些批量消息到对应的 Kafka Broker。
- 当 Broker 接收到消息后，如果成功写入则返回一个包含消息的主题、分区及位移的 RecordMetadata 对象，否则返回异常。
- 生产者接收到结果后，对于异常可能会进行重试。
Producer Exactly Once
0.11 版本的 Kafka，引入了幂等性：Producer 不论向 Server 发送多少重复数据，Server 端都只会持久化一条。
- 要启用幂等性，只需要将 Producer 的参数中 enable.idompotence 设置为 true 即可。
- 开启幂等性的 Producer 在初始化时会被分配一个 PID，发往同一 Partition 的消息会附带 Sequence Number。
- 而 Borker 端会对 <PID,Partition,SeqNumber> 做缓存，当具有相同主键的消息提交时，Broker 只会持久化一条。
- 但是 PID 重启后就会变化，同时不同的 Partition 也具有不同主键，所以幂等性无法保证跨分区会话的 Exactly Once。
