一口气说出Kafka为啥这么快? 在过去的几年里

在过去的几年里，软件架构领域发生了巨大的变化。人们不再认为所有的系统都应该共享一个数据库。
文章插图
图片来自 Pexels
微服务、事件驱动架构和 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 的压缩特性) ，只保留任何给定消费者组的最后已知偏移量。
将此模型与传统的消息模型进行对比，后者通常提供几种不同的消息分发拓扑。
一种是消息队列——用于点对点消息传递的持久化传输，没有点对多点功能。