设计目标

• 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。
• 支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输
• 同时支持离线数据处理和实时数据处理
• Scale out：支持在线水平扩展
• 以时间复杂度为O(1)的方式提供消息持久化能力

性能比较

• 对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

特性

• 快速持久化，可以在O(1)的系统开销下进行消息持久化
• 高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率
• 完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡
• 支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案
• Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统

架构

• Broker： Kafka集群包含一个或多个服务器，这种服务器被称为broker
• Topic： 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）
• Parition：  Parition是物理上的概念，每个Topic包含一个或多个Partition
• Producer： 负责发布消息到Kafka broker
• Consumer： 消息消费者，向Kafka broker读取消息的客户端。
• Consumer Group： 每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。
• 拓扑结构：

如上图所示，一个典型的Kafka集群中包含若干Producer（可以是web前端产生的Page View，或者是服务器日志，系统CPU、Memory等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干Consumer Group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。