作者：刘旭晖 Raymond 转载请注明出处
Email： colorant at 163.com
BLOG： http://blog.csdn.net/colorant/
== 是什么 ==
简单的说， Kafka 是由 Linkedin 开发的一个分布式的消息队列系统 (Message Queue)
目标 Scope （解决什么问题）
kafka 开发的主要初衷目标是构建一个用来处理海量日志，用户行为和网站运营统计等的数据处理框架。在结合了数据挖掘，行为分析，运营监控等需求的情况下，需要能够满足各种实时在线和批量离线处理应用场合对低延迟和批量吞吐性能的要求。从需求的根本上来说，高吞吐率是第一要求，其次是实时性和持久性。
既有的消息队列框架或者对消息传送的可靠性提供了较高的保证，由此带来较大的负担，不能满足海量高吞吐率的要求；或者完全面向实时消息处理系统，对于批量离线处理的场合无法提供足够的缓存和持久性要求。
而多数针对大数据开发应用的日志收集处理系统 (e.g. scribe, flume) 则通常更适合批量离线处理场合，对实时在线处理的场合支持不够。
总体而言， kafka 试图提供一个同时满足在线和离线处理海量数据的消息派发系统。
== 如何实现 ==
kafka 的集群有多个 Broker 服务器组成，每个类型的消息被定义为 topic ，同一 topic内部的消息按照一定的 key 和算法被分区 (partition) 存储在不同的 Broker 上，消息生产者 producer 和消费者 consumer 可以在多个 Broker 上生产 / 消费 topic
核心思想
以高效率作为第一设计原则， kafka 的结构设计在很多方面都做了激进的取舍。
= 极简的数据结构和应用模式 =
消息队列是以 log 文件的形式存储，消息生产者只能将消息添加到既有的文件尾部，没有任何 ID 信息用于消息的定位，完全依靠文件内的位移，因此消息的使用者只能依靠文件位移顺序读取消息，这样也就不需要维护复杂的支持随即读取的索引结构。
kafka broker 完全不维护和协调多用户使用消息的行为模式，用户自己维护位移用来索引消息。
最小的并发访问单位就是 partition 分区，同一用户组内的所有用户（可以理解为同一个应用的所有并发进程）只能有一个访问同一分区，同时分区的个数是固定的，不支持动态调整。这样最大简化了多进程 / 分布式 client 之间对消息处理访问的并发控制的复杂度，当然也带来一定的使用模式上的限制（比如最大并发度完全取决于预先规划的partition 的个数）
此外分区也带来一个问题就是消息只是分区内部有序而不是全局有序的。如果需要全局有序，应用需要自己靠别的机制来保证。
使用 Pull 模式派发消息，消息的使用情况，比如是否还有 consumer 没有读取，是否重复读取 ( 改进中 ) 等，在 Broker 端也完全不跟踪维护，消息的过期处理简单的由定时器定时删除（比如保留 7 天），由此简化各种消息跟踪维护的开销。
= 采取各种方式最大化数据传输效率 =
比如生产者和消费者可以批量读写消息减少 RPC 开销
使用 Zero Copy 方式在内核层直接将文件内容传送给网络 Socket ，避免应用层数据拷贝
使用合理的压缩格式等
= 激进的内存管理模式 =
基本的意思就是不管理。。。 kafka 不在 JVM 进程内部维护消息 Cache ，消息直接从文件中读写，完全依赖操作系统在文件系统层面的 cache ，避免在 JVM 中管理 Cache 带来的额外数据结构开销和 GC 带来的性能代价。基于批量处理和顺序读写的应用模式，最大化利用文件系统的 Cache 机制和规避文件读写相对内存读写的性能代价。
= HA =
kafka 在 0.8 之前 message 是没有备份容错机制的， producer 的工作模式是 fire and forget ，如果一个 broker 失效，那么相关 topic 分区的相关消息也就丢失了。这种设计的原因在于最初的应用模式，如日志 / 用户行为等消息的处理，对数据的健壮性方面要求不高，可以容忍部分数据的缺失。采用 fire and forget 模式，不需要等待 Broker ack ，有利于提高 producer 的吞吐率。
不过在 0.8 版本中，添加了数据 replica 的机制，一个消息分区的多个 replica 分布在不同的 Broker 上，由 leader replica 负责日常读写，通过 zookeeper 监督 failover ，不同的分区的 leader replica 均衡负载到不同的 Broker 上。在这种情况下， producer 可以选择不等待 leader replica 的 Ack ，部分 Ack ，或者完全备份完毕后 Ack 等不同的 ack 机制。这三种机制，性能依次递减 (producer 吞吐量降低 1-3 倍 ) ，数据健壮性则依次递增。
== Links ==
Paper 论文 http://research.microsoft.com/en-us/um/people/srikanth/netdb11/netdb11papers/netdb11-final12.pdf