本文介绍LinkedIn开源的Kafka，久仰大名了，按照其官方文档做些翻译和二次创作。对应可以查看整份官方文档。

基本术语

topics，维护的消息源种类（更像是业务上的数据种类/分类）

producer，给kafka的某个topic发布消息的进程

consumer，订阅和处理topic的消息的进程

broker，组成kafka集群的server

Topic和日志

kafka为每个topic维护了如下一份被分区了的log

每份log有序，不可变，不断被append。分区中的消息会被分配一个有序的id，称为offset。

kafka内保留的消息是有时间限制的，超出设定的时间段的话，消息就不保留了。kafka的性能与数据容量是成正比的。

offset能方便consumer来取数据，自由度比较大（或者说这种缓存性质的消息队列，方便消费者读取一定窗口内的消息，也算一种回放功能吧）。

分区一方面是为了增大消息的容量（可以分布在多个分区上存，而不会限制在单台机器存储大小里），二方面可以类似看成一种并行度。

分布

partitition分布在不同机器上，且可以设置备份数以达到容错。

每份partition都有一个扮演leader角色的server和几个扮演follower角色的server。leader来负责对这份分区的读写请求。

follower被动复制leader动作。leader挂了的话会有follower自动成为新的leader。

各个server都会各自扮演某份分区的leader和其他几份分区的followe，如此的话整个集群上的机器相对负载比较好些。

生产者

生产者选择发布数据给topic，负责选择topic的哪个partition，把消息写进去。

选择方法和策略有多种。

消费者

传统的消息模型有两种模型，队列模型和发布-订阅模式。

1. 队列形式中，一群消费者可能从server那边读消息，而每条消息会流向他们中的一个。

2. 发布-订阅模式中，消息会广播到所有它的消费者们那。

Kafka是使用consumer group这个概念（下面把它翻译为"消费组"），把两者结合了。。

消费者给自己标志了一个消费组名，每条新发布到topic的消息会被传递给订阅它的消费组里的消费者实例，这些消费者实例可以是不同的进程，存在在不同的机器上。

如果所有的消费者在同一个消费组里，那么这相当于是一个队列模型的场景。

如果所有的消费者都属于不同的消费组，那么这相当于是一个发布-订阅模式的场景，所有消息会广播到所有消费者们。

下图展示的是两台server组成的Kafka集群，共4个分区，两个消费组，A、B消费组各有2个、4个消费者，他们对应订阅了不同的分区。

此外，Kafka比传统的消息系统具备更强的有序性保证。下面会展开说明。

传统的队列形式的消息系统，在server端是有序保存着消息的。但当有多个消费者来并发取queue里的消息的时候，由于每个queue里的消息是异步输送给消费者，虽然输出是有序的（队列里排好队输出的），当消息到达消费者那头的时候，就不保证顺序了。如果单个消费者来取，可以保证有序，某些中庸的解决办法还是会丧失一定并行度。

Kafka是怎么做到更好的并行且有序的呢？Kafkad的"分区"其实是一种并行度的概念，即在topic内，kafka的消费者进程池能得到有序性保证和负载均衡。这是因为在topic内设置了多个分区，使得topic对应的消费组里的消费者们各自可以独享一个分区。如此的话，每个消费者是其消费的分区的唯一reader，在单个reader下当然保证了有序这件事。而且多个分区也使得负载可以比较平衡。需要注意的是，消费者不能比分区数多。

保证

kafka能保证的几件事情，

1. 生产者向topic分区发来的消息能按序添加进来。即先送来的消息在log里面有更小的offset。

2. 消费者实例能在log里（第一张图里）看到有序的消息。

3. 一个拥有N个分区的topic，系统能容忍N-1台server失败，而不丢失写到了log里的消息数据。

更多设计上的内容不在这里阐述。

适合场景

消息队列

kafka作为消息队列，优势在更好的吞吐，内置分区，副本数，容错这几个特性，所以适合大规模消息处理应用。

MQ有很多，就不具体比较了。

网页行为追踪

kafka原本的一个应用场景，就是跟踪用户浏览页面、搜索及其他行为，以发布-订阅的模式实时记录到对应的topic里。

那么这些结果被订阅者拿到后，就可以做进一步的实时处理，或实时监控，或放到hadoop/离线数据仓库里处理。

行为追踪经常会有很大的吞吐量。

元信息监控

作为操作记录的监控模块来使用，即汇集记录一些操作信息，可以理解为运维性质的数据监控吧。

日志收集

日志收集方面，其实开源产品有很多，包括Scribe、Apache Flume。如果谈Kafka的优势的话，其实还是离不开他的容错、高吞吐性能方面的设计层面的特点吧。具体就不分析了。

参考我之前写的分布式日志收集系统Apache Flume的设计介绍

流处理

这个场景可能比较多，也很好理解。保存收集流数据，以提供之后对接的Storm或其他流式计算框架进行处理。

Commit Log

为分布式系统的一些commit log（操作日志）做容错意义的备份，我是这么理解的，类似于HDFSnamenode的log。对比BookKeeper，其实就是做这件事的。BookKeeper在Hadoop HDFS Namenode HA方案里，用于记录namenode的操作日志(一时想不起叫什么log了，反正不记录namenode的image数据)。

全文完 :)