本文介绍LinkedIn开源的Kafka，久仰大名了，按照其官方文档做些翻译和二次创作。对应可以查看整份官方文档。
topics，维护的消息源种类（更像是业务上的数据种类/分类）
producer，给kafka的某个topic发布消息的进程
consumer，订阅和处理topic的消息的进程
broker，组成kafka集群的server
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（操作日志）做容错意义的备份，我是这么理解的，类似于HDFSnamenode的log。对比BookKeeper，其实就是做这件事的。BookKeeper在Hadoop HDFS Namenode HA方案里，用于记录namenode的操作日志(一时想不起叫什么log了，反正不记录namenode的image数据)。
参考我之前写的BookKeeper设计介绍及其在Hadoop2.0 Namenode HA方案中的使用分析
全文完 :)
原文地址：http://blog.csdn.net/pelick/article/details/26383521
