官方描述(0.8)：Kafka® is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system, but with a unique design.
即Kafka是一个分布式的，基于分区的，多副本的消息系统，它以独特的设计理念，提供了消息传递的功能。
传统的消息系统通常有两种模型，一个是“排队（queuing
）”，一个是“发布-订阅（publish-subscribe）。
对于排队模型（消息队列），允许有多个消费者（consumer）实例，且多个消费者实例可以分别处理队列中不相同的数据，所以方便消费端能力扩展。但队列中一条消息只能被一个消费者消费，一旦消息被某个消费者读到，消息就会消失，其他消费者将不能读取到该消息。对于发布-订阅模型，其也可以有多个消费者，不同的是它是以广播方式，一条消息可以被多个消费者消费，由于是消息广播方式，所以不便于消费端能力扩展。而Kafka的消息既可以被多次消费，消费者能力也可以很容易扩展，具体原理后续再做解释。
“发布-订阅”模型，还有个特点：数据（消息）的发送者（发布者）不会把数据直接发给接收者。
对于简单的或者某些系统的前期需求，普通系统架构即可满足，但随着时间推移，或者需求的更复杂化，架构就需要做些优化调整。比如前端应用服务（FrontendServer）的“指标度量消息”系统，前期我们可以直接在应用服务和仪表盘服务（MetricsServer）间建立连接，然后通过这个连接发送度量指标，如图一：
但随着需求增多，“直连架构”会变得一团糟。比如当需要分析更长时间段的度量指标时，此时仪表盘服务不能满足需求，于是我们引入一个新的服务--指标分析服务（MetricAnalysis）来处理长时间段的度量指标，此时我们的应用服务需要在其与指标分析服务间再建立一条链路。当类似需求越来越多，链路也会越来越多，最终系统将会比较复杂、混乱，如图二：
此时，我们最好对系统架构做些调整，让其“看起来更舒服些”。比如我们可以建立一个独立的服务来接收其他应用系统的度量指标，并为其他系统提供查询的服务，如此“指标度量”系统架构复杂度就会降低很多，如图三：
此时的“指标度量”系统，就可归属于“发布-订阅消息”系统。除了“指标度量”系统外，也许我们还会需要“日志记录”、“用户行为追踪”等系统，我们都可以采用这种方式来解耦信息的发布和订阅者，如图四：
如此方式比使用“直连”要好很多，但也有一些不好地方，比如多个发布-订阅系统间有很多地方功能重复，公司也需要维护多个数据队列系统，此时更好的方式是，我们做一个统一的、集中式的系统，他可以用来发布通用类型的数据，并且其规模可以随着公司业务的增长而增长。而Kafka就是可以用于解决这个问题的一个基于“发布-订阅”的消息系统。
参考:
《Kafka The Definitive Guide》
http://kafka.apache.org/documentation/#introduction
