kafka 设计

  1. Motivation(动机)

  设计Kafka作为一个统一的平台来处理大公司可能拥有的所有实时数据：

  1. 必须有高吞吐量来支持高容量事件流

  2. 优雅地处理大数据积压，以便能够支持离线系统的周期性数据负载

  3. 系统将不得不处理低延迟交付，以处理更传统的消息用例

  4. 系统必须能够保证在出现机器故障时的容错。

支持这些用途使我们设计了一些独特的元素，更类似于数据库日志，而不是传统的消息传递系统

2 . Persistence(持久)

the filesystem

Kafka严重依赖于文件系统来存储和缓存消息，这些线性读写是所有使用模式中最可预测的，并且由操作系统进行了大量优化。

现代操作系统提供了预先读取和写操作技术，这些技术可以在大的块倍数中预取数据，并将较小的逻辑写入到大型物理写入中。

使用文件系统和依赖pagecache优于维护一个内存中的缓存或其他结构我们至少两倍可用缓存通过自动访问所有可用内存。

在我们耗尽空间的时候，所有数据都被立即写入到文件系统上的持久日志中，而不必刷新到磁盘，这仅仅意味着它被转移到内核的pagecache中。

Constant Time Suffices

消息传递系统中使用的持久数据结构通常是每个用户队列，使用关联的BTree或其他通用随机访问数据结构来维护关于消息的元数据。btree是最通用的数据结构，可以在消息传递系统中支持各种事务和非事务性语义。但是，它们的代价是相当高的:Btree操作是O(log N)，通常O(log N)被认为本质上等同于常量时间，但对于磁盘操作来说，这是不正确的。磁盘寻找10毫秒一个pop，并且每个磁盘只能一次执行一次，所以并行性是有限的。因此，即使是少量磁盘也会导致很高的开销。由于存储系统将非常快的缓存操作与非常慢的物理磁盘操作混合在一起，因此当数据随固定缓存增加时，树结构的性能通常是超线性的。加倍你的数据会使事情变得比两倍的慢。

直观上，一个持久的队列可以建立在简单的读取和附加到文件上，这通常是日志解决方案的情况。这种结构的优点是所有操作都是O(1)，并且读取不会阻塞写入或彼此。这具有明显的性能优势，因为性能完全与数据大小分离，一个服务器现在可以充分利用许多便宜的、低转速的1+TB SATA驱动器。虽然他们的搜索性能很差，但这些驱动器的性能可以接受大型读取和写入，价格为1/3，容量为3倍。

在没有任何性能惩罚的情况下访问几乎无限的磁盘空间意味着我们可以提供一些在消息传递系统中不常见的特性。例如，在Kafka中，我们可以在相对较长的时间内(比如一个星期)保留消息，而不是试图删除消息。这将给消费者带来很大的灵活性，正如我们将描述的那样。

3. Efficiency(效率)

在消除了糟糕的磁盘访问模式，在这种类型的系统中有两个常见的低效原因:太多的小I/O操作和过度的字节复制。小I/O问题发生在客户机和服务器之间，以及服务器自身的持久操作中。为了避免这种情况，我们的协议是围绕一个“消息集”抽象构建的，该抽象可以自然地将消息分组在一起。这允许网络请求将消息分组，并分摊网络往返的开销，而不是一次发送一条消息。服务器依次将大量的消息追加到其日志中，而消费者一次获取大量的线性块。这个简单的优化产生数量级的加速。批处理导致了更大的网络数据包、更大的顺序磁盘操作、连续的内存块等等，所有这些都使得Kafka可以将一个由随机消息写入的卷流变为线性写入到客户端。

另一个低效率是字节复制。在低消息率下，这不是一个问题，但在负载下的影响是显著的。为了避免这种情况，我们采用了一种标准化的二进制消息格式，由生产者、代理和消费者共享(因此数据块可以在不进行修改的情况下传输)。

现代unix操作系统为将数据从pagecache传输到套接字提供了高度优化的代码路径;在Linux中，这是通过sendfile系统调用完成的。

要了解sendfile的影响，理解将数据从文件传输到套接字的公共数据路径非常重要:

1.操作系统从磁盘读取数据到内核空间的pagecache。

2.应用程序将数据从内核空间读取到用户空间缓冲区中。

3.应用程序将数据返回到内核空间，并将其写入套接字缓冲区。

4.操作系统将数据从套接字缓冲区复制到通过网络发送的NIC缓冲区。

使用sendfile，通过允许操作系统直接将数据从pagecache发送到网络，避免了重复复制。因此在这个优化的路径中，只需要最后的副本到NIC缓冲区。

pagecache和sendfile的组合意味着，在一个Kafka集群上，消费者基本上都被捕获了，您将看到磁盘上没有任何读取活动，因为它们将完全从缓存中提供数据。

End-to-end Batch Compression

有效压缩需要将多个消息压缩在一起，而不是单独压缩每个消息。Kafka用高效的批处理格式支持这一点。可以将一批消息聚合到一起，并以这种形式发送到服务器。这批消息将以压缩的形式写入，并且将在日志中保持压缩，并且只会被使用者解压。Kafka supports GZIP, Snappy and LZ4 compression protocols