目录
一 为什么要用Kafka？
1.1 写在前面–什么是中间件？
中间件概念很广泛，这里只介绍一般性概念，即：
- 中间件位于操作系统与应用软件之间，用于连接系统软件（例如：操作系统）和应用软件（例如：app），便于软件之间通讯；中间件是为应用软件服务的。
- 常用的中间件如：Tomcat（服务器中间件）、RabbitMQ（消息中间件）、Redis（缓存中间件）等
而Kafka则属于消息中间件一类。
1.2 Kafka的发展历史简介
最早由LinkedIn孕育开发。由于需要收集大量的集合日志、跟踪站点事件、某些业务需要队列的功能等，LinkedIn主导开发出了分布式发布-订阅平台Kafka。
Kafka设计原则是：为生产者和消费者提供简单的API、高吞吐量、支持横向扩展。
1.3 什么时候应该用Kafka？
- 实时数据传输
在如今推荐系统盛行的情况下，如何做到实时为用户推送感兴趣的内容？这里面涉及到大数据分析，推荐算法等，但是大数据分析的前提是如何获取和传输大量数据，并且是实时传输？
早在2010年前后，LinkedIn公司也致力于解决类似问题，于是有了Kafka。 - 网站行为追踪
将用户行为数据，网页浏览数据发送到Kafka，下游系统从Kafka获取数据并进行实时分析。 - 日志收集
Kafka用于从多个服务收集日志。 - 流式处理
Spark Streaming这样的大数据框架从Kafka获取数据进行实时处理并把处理结果发送到Kafka中，以供用户或应用程序使用。
1.4 Kafka的优缺点
1.4.1 优点
- 高吞吐量：支持每秒数千条消息的处理
- 低延迟：能够在毫秒内处理消息
- 容错
- 持久化：支持消息持久化，可以设置消息的保存时间
- 分布式
- 消费者友好型：可以集成各种类型的消费者，包括不同语言编写的消费者客户端
- 实时处理：Kafka的流处理API支持实时处理数据
1.4.2 缺点
- 没有完整的管理监控工具
- 不支持通配符的topic选择
- 消息大小增加，性能降低：消息增大时，Kafka会压缩和解压消息，降低吞吐量
- 当集群中队列数量增加时，它变得比较慢
- 消息传递模式比较单一：没有点对点、请求/应答等模式
1.5 Kafka vs. 传统消息队列
- 设计理念
Kafka：已客户端为中心，客户端接管了Broker的很多事，换来的好处是一个轻量级、易于扩展的Broker。
消息队列：以Broker为中心，负责消息的分发等，而客户端只需要担心消息的发送与接收。 - 扩展性
Kafka：增加更多分区可以实现横向扩展
消息队列：不能横向扩展 - 性能
Kafka：不会随着消费者的增加而性能下降
消息队列：性能随着消费者的增加而下降 - 消息发布方式
Kafka：订阅/发布和点对点消息发布模式都用topic来解决
消息队列：同时支持订阅/发布和点对点消息发布模式 - 日志
Kafka：每个topic对应一个日志
消息队列：所有消息存放在一个日志里 - 消息投递失败
Kafka：客户端负责重新获取消息，因为消息保存在broker不会被删除
消息队列：broker负责重新分发消息 - 消息的完整性
Kafka：支持完整性校验
消息队列：不支持完整性校验 - 消息的重新获取
Kafka：支持消息的重新获取，因为消息在Kafka中是持久化的
消息队列：不支持消息重新获取，因为消息被成功消费后会从队列中删除，不会保留下来
二 Kafka的架构设计
2.1 核心架构设计
简要解释：zookeeper负责kafka broker leader的选举和kafka集群的服务发现。
2.2 topic分区、消费者组、生产者等详细设计
一个topic对应多个分区，消息的Key值不同会被放到不同的分区，有一个映射算法进行映射操作。图片最右边是消费者组，一个消费者组由多个消费者组成，每个消费者消费一个分区的消息，如果消费者数量小于分区数量，则某些消费者消费不止一个分区的消息；如果消费者数量大于分区数量，则某些消费者会闲置起来。
不同的消费者组会记录自己停止消费的offset以便下次从该offset继续读取消息，生产者将消息追加到分区末尾。