Apache Kafka设计理念探究

动机

创造一个分布式的实时流处理平台，也正是因为这个原因，Kafka选择了将日志分区和消费者群组模型。

持久化

日志的持久化依赖于文件系统，而文件系统的处理速度，在往常的观念里，应该是相当慢的。但是依赖于pagecache-centric design，文件系统的持久化获得了极大的提升。并且Kafka的日志是顺序读写，对于磁盘的定位速度也远远大于随机读写的速度，同样也因为如此，对于传统的AMQP消息系统使用B树实现queue的持久化，也是因为忽略了磁盘的随机读写会很慢，通过日志的方式则不会block写和读，也可以做到O(1)的读写效率（从日志最后读）。

效率

影响消息系统处理效率的主要有两个因素：

太多小的IO操作

过多的字节级复制

对于太多小的IO操作，Kafka会把一定时间内的消息先聚合内存中（“message set”），再一起写入，而不是来一条消息写一次日志。

对于过多的字节级复制，Kafka选择消费者，生产者和broker共享同一套二进制消息格式，使得操作系统可以直接将文件丢入network而不需要buffer。（zero-copy optimization，在具体的实现则是Linux中的sendfile system call方法）

此外，Kafka也提供了GZIP, Snappy and LZ4等协议压缩数据。

生产者

Kafka的生产者模型选择了生产者将数据直接发送给Topic的Master，而不是像Rabbit MQ一样需要路由（为了实现这，Kafka借助了Zookeeper，并且将元数据存储在Zookeeper之上）。除了此，Kafka将负载均衡的任务交给了客户端，客户端可以选择将消息发送到Topic中具体的哪个partition上。对于一些轻一致性，追求效率的场景，Kafka提供了异步发送的机制。

基于pull的拉取数据

Kafka没有选择和AMQP消息系统一样，由消息系统将队列里的消息推送给消费者，而是让消费者自己将Kafka的数据根据offset拉下来。相对于push的方式，Kafka认为pull会给与消费者更大的自由权，这样消费者也可以从任意的offset开始消费（自然也方便失败重试），也无需担心数据会遗漏丢失（只要消息不过期）。Kafka会使用长连接池阻塞的方式，来解决消息未到时消费者连接问题。Kafka也会保存每个消费的消费过的offset元数据，以此来提高消费者的效率。

消息唯一性保证

Kafka提供了三种消息确认机制：

At most once—Messages may be lost but are never redelivered.

At least once—Messages are never lost but may be redelivered.

Exactly once—this is what people actually want, each message is delivered once and only once.

Kafka在0.11.0.0开始通过给生产者的每条消息赋予全局ID，来保证消息不会被重复发送。