工作中多少接触过kafka，尤其是在大数据消息处理的场景，用到kafka的地方很多，它给人最大的印象就是它最初设计的目标“满足高数据量吞吐量”。
Apache Kafka最初由LinkedIn贡献，目前它是Apache下的一个顶级开源项目。Apache Kafka设计的首要目标是解决LinkedIn网站中海量的用户操作行为记录、页面浏览记录，后继的Apache Kafka版本也都是将“满足高数据吞吐量”作为版本优化的首要目标。为了达到这个目标，Apache Kafka甚至在其他功能方面上做了一定的牺牲，例如：消息的事务性。如果您的系统需要进行单位时间内大量的数据采集工作，那么可以考虑在您的系统设计方案中加入Apache Kafka。
一个完整的Apache Kafka解决方案的组成包括四个要素：Producer（消息生产者）、Server Broker（服务代理器）、Zookeeper（协调者）、Consumer（消息消费者）。 Apache Kafka在设计之初就被认为是集群化工作的，所以要说清楚Apache Kafa的设计结构除了要讲述每一个Kafka Broker是如何工作的以外，还要讲述清楚整个Apache Kafka集群是如何工作的。
Kafka之所以“快”，并不只是因为它的I/O操作是顺序读写和多个分区的概念；毕竟类似于AcitveMQ也有多节点集群的概念，并且后者通过使用LevelDB或者KahaDB这样的存储方案也可以实现磁盘的顺序I/O操作。要知道如果消息消费者真正需要到磁盘上寻找数据了，那么整个Kafka集群的性能也不会好到哪儿去：Kafka对Linux操作系统下Page Cache技术的应用，才是其高性能的最大保证。文件内容的组织结构只是其保证消息可靠性的一种方式，真实的业务环境下Kafka一般不需要在磁盘上为消费者寻找消息记录（只要您的内存空间够大）。