Kafka总结系列（二）

Design

Persistence：

    kafka高度依赖于文件系统来存储和缓存消息。对于磁盘的正确认识：对磁盘的线性读写比随机读写快很多倍，且有研究表明：对磁盘的线性读写在有些情况下可以比内存的随机访问要更快！

Efficiency：

    在消息队列系统中，如果磁盘的因素被排除之后(线性读写磁盘的速度并不那么慢)，还有两个原因会导致inefficiency：太多IO操作（too many small I/O operation）和过多的字节拷贝（excessive byte coping）。

    1、small IO发生在client和server的交互中以及server本身的持久化操作中。为了避免，我们将消息组织成“message set”进行网络传输，所以server每次追加chunks of message至日志文件中（即批量写入），consumer也一次获取large linear chunks。 所有的批处理导致较大的网络数据包，较大的连续的磁盘操作，连续内存块，等等，使kafka由随机消息写入突发流变成线性流。

    批量生产和批量消费可以在producer和consumer的配置文件中指定：

    producer.type：生产模式：同步或者异步，异步意味着消息会在本地buffer缓存，之后批量发送，毫无疑问这可以增加吞吐量，但是当producer所在机器发生故障时，会丢失未发送的数据；

    fetch.message.max.bytes：consumer获取消息的最大字节数，broker不会向consumer输出大于此值的消息chunk，每次消费会得到多条消息，此值为总大小。

    2、byte copying：我们在生产者、消费者以及broker之间采用统一的二进制消息格式，这样传输时不需要格式转换。Linux操作系统中提供了一个sendfile系统调用，将数据从页缓冲区传输至socket套接字： 常见的数据从文件系统传输至socket经过的路径：

• • 操作系统将数据从磁盘读入内核空间的页缓冲区；
  • 应用程序将数据从内核空间读到用户空间缓冲区；
  • 应用程序再将数据写入内核空间的socket buffer，套接字缓冲区；
  • 操作系统从socket buffer拷贝数据至NIC buffer网卡缓冲区，之后发送至网络中：

    上述操作不高效，存在四次数据拷贝，两次系统调用。如果使用sedfile，允许操作系统将数据从内核页缓冲区直接发送到网络上，只需要最后一步的拷贝，即从socket buffer到网卡缓冲区，这就是zero-copy技术。

    一个topic有多个consumer是一种常见的应用场景，利用上述的零拷贝技术，数据只被拷贝至页缓冲区一次就可以在每次消费时重复利用，而不是消息存储在内存中，之后每次消费的时候再从内存拷贝到内核空间。这使得消息消费的速率可以达到网络连接的速度。

    3、页缓冲区和sendfile的组合，意味着看不到kafka集群的消费者在任何磁盘上的活动，因为他们将完全从缓存中提取数据。

End-to-end Batch Compression：

    某些场景下，瓶颈并不是CPU或磁盘，而是网络带宽。当然，用户可以不需要kafka的支持压缩每一条消息之后再发送，但这将导致非常低的压缩率。高效的压缩应该是把多条消息压缩成为一条。kafka支持端到端的压缩，一批消息可以被压缩然后发送给broker，在服务端同样保持压缩状态，最终被消费者解压缩。kafka支持GZIP和Snappy两种压缩协议。

The producer：

• Load balancing：    

    生产者直接将消息发送给topic某一个分区的leader broker（直接和leader通信，可以自己指定分区策略（可以指定一个字段作为key，使用它进行hash分区），也可以使用默认的轮询机制）。消费者会给配置文件中指定的broker发送请求，获知哪些服务器可用，该topic的分区对应的leader broker分别是谁等信息，而kafka的brokers应该能够回答这样的请求。

• Asynchronous send：

    Producer可以异步发送，批量生产。可以通过配置文件配置batch：指定消息条数，或者指定累积的字节数或者是时间间隔。也就是先将消息缓存在内存中，一定规模后一次性发送，这会带来更低的IO开销，增加吞吐量，但会增加延迟，所以需要tradeoff。