在过去的几年里，软件架构领域发生了巨大的变化。人们不再认为所有的系统都应该共享一个数据库。微服务、事件驱动架构和CQRS（命令查询的责任分离 Command Query Responsibility Segregation）是构建当代业务应用程序的主要工具。除此以外，物联网、移动设备和可穿戴设备的普及，进一步对系统的近实时能力提出了挑战。

首先让我们对“快”这个词达成共识，这个词是多方面的、复杂的、高度模糊的。一种解释是把”延迟、吞吐量和抖动“作为对“快”的衡量指标。还有，比如工业应用领域，行业本身设置了对于“快”的规范和期望。所以，“快”在很大程度上取决于你的参照体系是什么。

Apache Kafka以牺牲延迟和抖动为代价优化了吞吐量，但并没有牺牲，比如持久性、严格的记录有序性和至少一次的分发语义。当有人说“Kafka速度很快”，并假设他们至少有一定的能力时，你可以认为他们指的是Kafka在短时间内分发大量记录的能力。

Kafka诞生于LinkedIn，当时LinkedIn需要高效地传递大量信息，相当于每小时传输数TB的数据量。在当时，消息传播的延迟被认为是可以接受的。毕竟，LinkedIn不是一家从事高频交易的金融机构，也不是一个在确定期限内运行的工业控制系统。Kafka可用于近实时系统。

注意：“实时”并不意味着“快”，它的意思是“可预测的”。具体来说，实时意味着完成一个动作具有时间限制，也就是最后期限。如果一个系统不能满足这个要求，它就不能被归类为”实时系统“。能够容忍一定范围内延迟的系统被称为“近实时”系统。从吞吐量的角度来说，实时系统通常比近实时或非实时系统要慢。

Kafka在速度上有两个重要的方面，需要单独讨论。第一个是与客户端与服务端之间的低效率实现有关。第二个源自于流处理的并行性。

服务端优化

日志的存储

Kafka利用分段、追加日志的方式，在很大程度上将读写限制为顺序I/O（sequential I/O），这在大多数的存储介质上都很快。人们普遍错误地认为硬盘很慢。然而，存储介质的性能，很大程度上依赖于数据被访问的模式。同样在一块普通的7200 RPM SATA硬盘上，随机I/O（random I/O）与顺序I/O相比，随机I/O的性能要比顺序I/O慢3到4个数量级。此外，现代的操作系统提供了预先读和延迟写的技术，这些技术可以以块为单位，预先读取大量数据，并将较小的逻辑写操作合并成较大的物理写操作。因此，顺序I/O和随机I/O之间的性能差异在闪存和其他固态非易失性介质中仍然很明显，不过它们在旋转存储，比如固态硬盘中的性能差异就没有那么明显。

记录的批处理

顺序I/O在大多数存储介质上都非常快，可以与网络I/O的最高性能相媲美。在实践中，这意味着一个设计良好的日志持久化层能跟上网络的读写速度。事实上，Kafka的性能瓶颈通常并不在硬盘上，而是网络。因此，除了操作系统提供的批处理外，Kafka的客户端和服务端会在一个批处理中积累多个记录——包括读写记录，然后在通过网络发送出去。记录的批处理可以缓解网络往返的开销，使用更大的数据包，提高带宽的效率。

批量压缩

当启用压缩时，对批处理的影响特别明显，因为随着数据大小的增加，压缩通常会变得更有效。特别是在使用基于文本的格式时，比如JSON，压缩的效果会非常明显，压缩比通常在5x到7x之间。此外，记录的批处理主要作为一个客户端操作，负载在传递的过程中，不仅对网络带宽有积极影响，而且对服务端的磁盘I/O利用率也有积极影响。

便宜的消费者

不同于传统的消息队列模型，当消息被消费时会删除消息（会导致随机I/O），Kafka不会在消息被消费后删除它们——相反，它会独立地跟踪每个消费者组的偏移量。可以参考Kafka的内部主题__consumer_offsets了解更多。同样，由于只是追加操作，所以速度很快。消息的大小在后台被进一步减少（使用Kafka的压缩特性），只保留任何给定消费者组的最后已知偏移量。

将此模型与传统的消息模型进行对比，后者通常提供几种不同的消息分发拓扑。一种是消息队列——用于点对点消息传递的持久化传输，没有点对多点功能。另一种是发布订阅主题允许点对多点消息通信，但这样做的代价是持久性。在传统消息队列模型中实现持久化的点对多点消息通信模型需要为每个有状态的使用者维护专用消息队列。这将放大读写的消耗。消息生产者被迫将消息写入多个消息队列中。另外一种选择是使用扇出中继，扇出中继可以消费来自一个队列中的记录，并将记录写入其他多个队列中，但这只会将延迟放大点。并且，一些消费者正在服务端上生成负载——读和写I/O的混合，既有顺序的，也有随机的。

Kafka中的消费者是“便宜的”，只要他们不改变日志文件（只有生产者或Kafka的内部进程被允许这样做）。这意味着大量消费者可以并发地从同一主题读取数据，而不会使集群崩溃。添加一个消费者仍然有一些成本，但主要是顺序读取夹杂很少的顺序写入。因此，在一个多样化的消费者系统中，看到一个主题被共享是相当正常的。

未刷新的缓冲写操作

Kafka性能的另一个基本原因是，一个值得进一步研究的原因：Kafka在确认写操作之前并没有调用fsync。ACK的唯一要求是记录已经写入I/O缓冲区。这是一个鲜为人知的事实，但却是一个至关重要的事实。实际上，这就是Kafka的执行方式，就好像它是一个内存队列一样——Kafka实际上是一个由磁盘支持的内存队列（受缓冲区/页面缓存大小的限制）。

但是，这种形式的写入是不安全的，因为副本的出错可能导致数据丢失，即使记录似乎已经被ACK。换句话说，与关系型数据库不同，仅写入缓冲区并不意味着持久性。保证Kafka持久性的是运行几个同步的副本。即使其中一个出错了，其他的（假设不止一个）将继续运行——假设出错的原因不会导致其他的副本也出错。因此，无fsync的非阻塞I/O方法和冗余的同步副本组合为Kafka提供了高吞吐、持久性和可用性。

关注微信公众号：朱小厮的博客，在菜单栏“推荐阅读”-“往期精彩”中有更多kafka知识等着你。或者回复：kafka，获取急速学习通道^-^。

客户端优化

大多数数据库、队列和其他形式的持久性中间件都是围绕全能服务器（或服务器集群）和瘦客户端的概念设计的。客户端的实现通常被认为比服务器端简单得多。服务器会处理大部分的负载，而客户端仅充当服务端的门面。

Kafka采用了不同的客户端设计方法。在记录到达服务器之前，会在客户端上执行大量的工作。这包括对累加器（RecordAccumulator）中的记录进行分段、对记录键进行散列以得到正确的分区索引、对记录进行校验以及对记录批处理进行压缩。客户端知道集群元数据，并定期刷新元数据以跟上服务端拓扑的更改。这让客户端更准确的做出转发决策。不同于盲目地将记录发送到集群并依靠后者将其转发到适当的节点，生产者客户端可以直接将写请求转发到分区主机。类似地，消费者客户端能够在获取记录时做出更明智的决定，比如在发出读查询时，可以使用在地理上更接近消费者客户端的副本。（该特性是从Kafka的2.4.0版本开始提供。）

零拷贝

我在很久之前就之前就发过一篇《什么是Zero Copy》,如果对Zero Copy不了解的同学可以翻阅一下。Kafka使用了Zero Copy技术提升了消费的效率。前面所说的Kafka将消息先写入页缓存，如果消费者在读取消息的时候如果在页缓存中可以命中，那么可以直接从页缓存中读取，这样又节省了一次从磁盘到页缓存的copy开销。另外对于读写的概念可以进一步了解一下什么是写放大和读放大。

避免垃圾回收

大量使用通道、缓冲区和页面缓存还有一个额外的好处——减少垃圾收集器的工作负载。例如，在32 GB RAM的机器上运行Kafka将产生28-30 GB的页面缓存可用空间，完全超出了垃圾收集器的范围。吞吐量的差异非常小（大约几个百分点），但是经过正确调优的垃圾收集器的吞吐量可能非常高，特别是在处理短生存期对象时。真正的收益在于减少抖动。通过避免垃圾回收，服务端不太可能遇到因垃圾回收引起的程序暂停，从而影响客户端，加大记录的通信延迟。

与初期的Kafka相比，现在避免垃圾回收已经不是什么问题了。像Shenandoah和ZGC这样的现代垃圾收集器可以扩展到巨大的、多TB级的堆，在最坏的情况下，并且可以自动调整垃圾收集的暂停时间，降到几毫秒。现在，可以看见大量的基于Java虚拟机的应用程序使用堆缓存，而不是堆外缓存。

流处理的并行性

日志的I/O效率是性能的一个重要方面，主要的性能影响在于写。Kafka对主题结构和消费生态系统中的并行性处理是其读性能的基础。这种组合产生了整体非常高的端到端消息吞吐量。将并发性深入到分区方案和使用者组的操作中，这实际上是Kafka中的一种负载均衡机制——将分区平均地分配到各个消费者中。将此与传统的消息队列进行比较：在RabbitMQ的设置中，多个并发的消费者可以以轮询的方式从队列中读取数据，但这样做会丧失消息的有序性。

分区机制有利于Kafka服务端的水平扩展。每个分区都有一个专门的领导者。因此，任何重要的多分区的主题都可以利用整个服务端集群进行写操作。这是Kafka和传统消息队列的另一个区别。当后者利用集群来提高可用性时，Kafka通过负载均衡来提高可用性、持久性和吞吐量。

发布具有多个分区的主题时，生产者指定发布记录时的分区。（可能有一个单分区主题，那就不是问题了。）可以通过指定分区索引直接完成，或通过记录键间接完成，记录键通过计算散列值确定分区索引。具有相同散列值的记录共享相同的分区。假设一个主题有多个分区，那么具有不同键的记录可能会出现在不同的分区中。然而，由于散列冲突，具有不同散列值的记录也可能最终出现在同一个分区中。这就是散列的本质。如果你理解了散列表的工作方式，一切都很自然了。

记录的实际处理由消费者完成，在一个可选的消费者组中完成。Kafka保证一个分区最多只能分配给消费者组中的一个消费者。（为什么用”最多“，当所有消费者都离线时，那就是0个消费者了。）当组中的第一个消费者订阅主题时，它将接收该主题上的所有分区。当第二个消费者订阅主题时，它将接收到大约一半的分区，从而减轻第一个消费者的负载。根据需要添加消费者（理想情况下，使用自动伸缩机制），这使你能够并行地处理事件流，前提是你已经对事件流进行了分区。

以两种方式控制记录的吞吐量：

1. 主题分区方案。应该对主题进行分区，最大化事件流的数量。换句话说，只有在绝对需要时才提供记录的顺序。如果任何两个记录不存在关联，它们就不应该被绑定到同一个分区。这意味着要使用不同的键，因为Kafka使用记录键的散列值作为分区映射的根据。

2. 组中消费者的数量。你可以增加消费者的数量来均衡入站记录的负载，消费者的数量最多可以增加到和分区数量一样多。（你可以增加更多的消费者，但每个分区最多只能有一个的活动消费者，剩下的消费者将处于闲置状态。）请注意，你可以提供一个线程池，根据消费者执行工作负载的不同，消费者可以是一个进程或一个线程。

写在最后

如果你想知道Kafka为什么这么快，它是如何做到的，以及它是否适合你，我想你现在已经有了答案了。

Kafka作为一个完整的生态系统，它在整体上仍然是无与伦比的。它展示了出色的性能，同时提供了一个丰富和成熟的环境，Kafka仍在以令人羡慕的速度增长。

Kafka的设计者和维护者在设计一个以性能为核心的解决方案时做了大量的工作。它的设计元素中很少有让人觉得是事后才想到的，或者是补全的。从将工作负载转移到客户端，到服务端日志的持久性、批处理、压缩、零拷贝I/O和并行流处理——Kafka向任何其他消息中间件厂商发起挑战，无论是商业的还是开源的。最令人印象深刻的是，它做到了这一点，却没有牺牲持久性、记录有序性和至少一次分发的语义。

Kafka不是最简单的消息中间件平台，还有许多需要改进的地方。在设计和构建高性能事件驱动系统之前，必须掌握总体和部分的顺序、主题、分区、消费者和消费者组的概念。虽然知识曲线很陡峭，但值得你花时间去学习。如果你知道这个谚语“red pill”（red pill，指为了达到对某种事物的深度探索或追求，选择去思考，不放弃，继续走下去，哪怕这条路多难走。），请阅读“介绍Kafka和Kafdrop中的事件流Introduction to Event Streaming with Kafka and Kafdrop[1]”。

相关链接：https://medium.com/swlh/introduction-to-event-streaming-with-kafka-and-kafdrop-22afdb4b380a