面试官：为什么 Kafka 如此之快？.docxVIP

面试官：为什么 Kafka 如此之快？ Kafka利用分段式追加日志，将大部分读写都限制为挨次I / O，这种方式在各种存储介质上的读写速度都格外快。人们普遍认为磁盘的读写速度很慢，但实际上存储介质（尤其是旋转介质）的功能很大程度上取决于访问模式。常见的7,200 RPM SATA磁盘上的随机I / O的功能要比挨次I / O慢3～4个数量级。此外，现代操作系统供应了预读和延迟写入技术，可以事后取出大块的数据，并将较小的规律写入组合成较大的物理写入。因而，即便在闪存和其他方式的固态非易失性介质中，随机I/O和挨次I/O的差异仍旧很明显，虽然与旋转介质相比，这种差异性已经很小了。 记录批处理 在大多数媒体类型上，挨次I / O的速度格外快，可与网络I / O的峰值功能相媲美。在实践中，这意味着细心设计的日志结构长久层能够跟上网络流量的速度。实际上，Kafka的瓶颈通常不在于磁盘，而是网络。因而，除了操作系统供应的低级批处理外，Kafka客户和代理还会将读写的多个记录打包成批次，然后再通过网络发送。记录的批处理通过使用更大的数据包，以及提高带宽效率来分摊网络来回的开销。 批量压缩 启用压缩后，批处理的影响将更为明显，由于随着数据量的添加，压缩会愈加有效。尤其是当使用基于文本的格式（如JSON）时，压缩的效果会格外明显，压缩率通常会到5～7倍之间。此外，记录的批处理大部分是在客户端完成的，它将负载转移到客户端上，不只可以减轻网络带宽的压力，而且对代理的磁盘I / O利用率也有乐观的影响。 廉价的消费者 传统的MQ风格的代理程序会在消费消息的时候删除消息（会导致随机I / O的功能下降），Kafka与之不同，它不会在使用过后删除消息，它会依据每个消费者组单独跟踪偏移量。偏移量的进度本身发布在Kafka的内部主题__consumer_offsets上。同样，由于这是一个仅追加的操作，所以速度格外快。在后台，这个主题的内容将进一步削减（使用Kafka的压缩功能），仅保留消费者组的最新已知偏移量。 我们来比较一下该模型与更传统的消息代理（这些代理通常都会供应多种不同的消息分发拓扑）。一方面是消息队列（一种长久的传输，用于点对点消息传递，没有点对多点的功能。）另一方面，pub-sub主题允许点对多点消息传递，但牺牲了长久性。在传统的MQ中实现长久的点对多点消息传递模型需要为每个无形态的消费者维护一个公用的消息队列。这会放大读写量。一方面，发布者不得不写入多个队列。或者，扇出中继可能会从一个队列中消费记录，并写入几个其他队列，但这只是把读写放大的点推迟了而已。另一方面，多个消费者会在代理上产生负载，这些负载既包含挨次I / O的读写，也包含随机I / O的读写。 只需Kafka中的消费者不更改日志文件（仅允许生产者或内部Kafka进程更改日志文件），它们就很“廉价”。这意味着大量的消费者可以同时读取同一主题，而不会占用过多的集群。虽然添加消费者还是需要付出一些代价，但是大多都是挨次读取，加上极少量的挨次写入。因而，多个消费者生态系统共享一个主题是很正常的。 未刷新的缓冲写入 Kafka高功能的另一个根本缘由（也是值得进一步探讨的缘由）在于，在确认写入之前，Kafka在写入磁盘时实际上并不会调用fsync。ACK独一的要求就是记录已被写入I / O缓冲区。这一点不为人知，但至关重要，正是由于这一点，Kafka的操作就像是一个内存队列一样，由于Kafka的目标就是由磁盘支持的内存队列（规模由缓冲区/页面缓存的大小打算）。 另一方面，这种写入的方式是担忧全的，由于即便看似记录已被确认，副本出问题也可能导致数据丢失。换句话说，与关系数据库不同，仅承认写入并不意味着长久性。保证Kafka长久的缘由在于它运转了多个同步副本。即便其中一个消灭问题，其他副本也将连续运转，当然前提是其他副本没有受影响（有时，某个常见的上游毛病可能会导致多个副本同时出问题）。因而，无fsync的I / O非堵塞方法与冗余的同步副本的结合保证了Kafka的高吞吐量、长久性和可用性。 客户端优化 大多数数据库、队列以及其他方式的长久性两头件的设计理念中，都有一个全能的服务器（或服务器集群），加上多个瘦客户端，两者之间通过常见的通信协议通信。通常我们认为，客户端的实现难度远低于服务器端。因而，服务器担当了大部分负载，而客户端仅充当应用程序代码和服务器之间的接口。 Kafka的客户端设计接受了不同的方法。在记录到达服务器之前，客户端需要执行大量操作，包括将记录暂存到收集器中，对记录的键进行哈希处理以获得正确的分区索引，对记录进行校验以及对批次进行压缩。客户端把握了集群的元数据，并会定期刷新这些元数据，以了解代理拓扑的变化。因而，客户端可以打算底层的转发，生产者客户端不会将记录盲目地发给集