1、 简介
Apache kafka 是一个快速、可扩展的、高吞吐的、可容错的分布式“发布-订阅”消息系统，使用Scala与Java语言编写，能够将消息从一个端点传递到另一个端点，较之传统的消息中间件（比如ActiveMQ、RabbitMQ），kafka具有高吞吐量、内置分区、支持消息副本和高容错的特性，非常适合大规模消息处理应用程序。
kafka官网：http://kafka.apache.org/
2、应用场景
2.1、 用户的活动追踪
用户在网站的活动（网页游览，搜索或其他用户的操作信息）发布到不同的话题中心，这些消息可实时处理，实时监测，也可加载到 Hadoop 或离线处理数据仓库。这昌“用户画像”的一种实现方式
2.2、 日志聚合
- 日志采集客户端在采集到日志数据后，定时写入 Kafka 队列。
- Kafka 消息队列，负责日志数据的接收、存储和转发。
- 日志处理应用从 Kafka 订阅相应主题的日志，当 kafka 中具有了该主题的日志消息后会马上发布给日志处理应用，由该应用消费这些日志数据。
2.3、 限流削峰
限流削锋也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛。在秒杀活动中，为防止流量过大而引发的系统宕机，一般需要在应用前端加入消息队列。
3、 特性
3.1、可扩展
在不需要下线的情况下进行扩容，partition存储在多个机器上。
3.2、持久存储
消息直接持久化在磁盘上，并且消息还会备份到其他服务器上，防止丢失。
3.3、kafka 高吞吐率实现
Kafka 与其它 MQ 相比，其最大的特点就是高吞吐量。为了增加存储能力，Kafka 将所有的消息都写入到了低速大容的硬盘。按理说，这将导致性能损失，但实际上，kafka 持超高的吞吐率，性能并未受到影响。其主要采用了如下的方式实现了高吞吐率。
顺序读写
partition 的消息是顺序读写的，这使得读写操作不需要硬盘磁头的寻道时间，只需很少的扇区旋转时间，所以速度远快于随机读写。
零拷贝
生产者、消费者对于 kafka 中消息的操作采用零拷贝实现，无需经过用户缓存，大大提高了 IO 速度。
批量发送
Kafka 允许使用批量消息发送模式。先将消息缓存在内存中，然后再将消息批量发送出去。而发送的策略可以是缓存满，或消息数量到达阈值，或定时发送等。批量发送大大减少了服务端的 I/O 次数。
消息压缩
Kafka 支持对消息集合进行压缩，以减少传输的消息量，减轻网络传输压力。Producer压缩之后，Consumer 进行解压。虽然增加了 CPU 的工作量，但在对大消息处理上，瓶颈在网络上而不是 CPU，所以这个成本是值得的。
4、系统架构图
5、名词解释
- topic（主题）
在kafka中，使用一个类别属性来划分消息的所属类，划分消息的这个类称为topic。它相当于消息的分类标签，是一个逻辑概念。同一个topic的不同partition，可以分布在不同的broker上。
对于传统的消息队列而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，不管消息是否被消费。但是由于受磁盘限制，不可能一直保留，所以Kafka提供了删除旧数据的两种策略：基于时间、基于Partition文件大小。
- partition（分区）
partition是一个物理概念，每个topic中的消息分成一个或多个分区，每个分区是一个FIFO有序的队列，且每个分区在物理上都对应着一个文件夹，该文件夹下存储这个分区所有消息和索引文件。但是不同的分区之间消息是无序的。如果 topic 有多个 partition，消费消息时就不能保证消息的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition 数目设为 1。一般情况下，一个 topic 的 partition 数量是 broker 的整数倍。
- segment（段）
随着消息的快速增加，partition 会变得越来越大。这样对于消息文件的维护以及已经被消费的消息的清理带来严重的影响。为了解决这个问题，将 partition 进一步细分为了若干的 segment，每个 segment 文件的大小相等。这样便于 old segment 的删除，有利于提高磁盘的利用率。每个 partition 只需要支持对 segment 文件的顺序读写就行。segment文件大小及生命周期可在 server.properties 配置文件中配置。
- broker
Kafka集群包含一个或多个服务器，每个服务器节点称为一个broker。broker存储topic的partition消息。broker 与 partition 间的关系如下所述：
（1）如果某 topic 有 N 个 partition，集群有 N 个 broker，那么每个 broker 存储该 topic的一个 partition。
（2）如果某 topic 有 N 个 partition，集群有(N+M)个 broker，那么其中有 N 个 broker存储该topic 的一个 partition，剩下的 M 个 broker 不存储该 topic 的 partition 消息。
（3）如果某 topic 有 N 个 partition，集群中 broker 数目少于 N 个，那么一个 broker 存储该 topic的一个或多个 partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致 Kafka 集群消息不均衡。
- producer（生产者）
即消息的发布者，其会将某 topic 的消息发布到相应的 partition 中。生产者发送的消息，存储到一个 partition 中，生产者也可以指定消息存储的 partition。Kafka 支持消息的负载均衡，例如生产者生成了两条消息，topic 有两个 partition，那么 Kafka 将在两个partition 上分别存储一条消息。
- consumer（消费者）
可以从 broker 中读取消息。一个消费者可以消费多个 topic 的消息。但对于某一个 topic 的消息，消费者只会消费同一个 partition 中的消息。
- Replicas of partition（分区副本）
副本是一个分区的备份。副本不会被消费者消费，副本只用于防止消息丢失，即消费者不从为 follower 的 partition 中消费消息，而是从为 leader 的 partition 中读取消息。
如上图所示：
topic1有4个partiion，且每个partiion有3个备份
topic2有3个partiion，且每个partiion有2个备份
topic3有4个partiion，且每个partiion有4个备份
- Partition Leader
每个 partition 有多个副本，其中有且仅有一个作为 Leader，Leader 是当前负责消息读写的 partition。
- Partition Follower
所有写请求都通过 Leader 路由，消息变更会广播给所有 Follower，Follower 与 Leader保持消息同步。如果 Leader 失效，则从 Follower 中选举出一个新的 Leader。当 Follower 卡住或者同步太慢，Leader 会把这个 Follower 从 ISR 列表（In Sync Replicas）中删除。
注意，Partition Leader 的选举不是由 zookeeper 完成的，而是由 Broker Controller 完成的。Leader 与 Follower 是主备关系，而非主从。
- Partition offset
分区偏移量。每条消息都有一个当前 Partition 下唯一的 64 字节的 offset，它是相对于当前分区第一条消息的偏移量。
当 consumer 从 partition 拉取了若干消息后，consumer 会将这些消息中最大的 offset 提交给 broker，表示当前 partition 已经消费到了该 offset 所标识的消息。
- Broker Controller
Kafka 集群中多个 broker 中，有一个会被选举为 controller，负责管理整个集群中partition和 replicas 的状态。只有 Broker Controller 会向 zookeeper 中注册 Watcher，其他 broker 无需注册。即 zookeeper 仅需监听 Broker Controller 的状态变化即可。
脑裂，由假死引发的。
- ISR
ISR，In-Sync Replicas，是指副本同步列表。为了增强 kafka 的高可用性，我们会为partition创建副本。所有的副本统称为 Assigned Replicas，即 AR。初始时 leader 与所有 follower 都在ISR 列表，即初始时 ISR = AR。ISR 中的 partition 是要从 leader 同步消息的。但同步会有延迟，只要延迟超过了阈值 replica.lag.time.max.ms，就会把 follower剔除出 ISR，移入OSR(Outof-Sync Replicas)列表。即，AR = ISR + OSR。
Kafka在Zookeeper中动态维护了一个ISR（in-sync replicas） set，这个set里的所有replica都跟上了leader，只有ISR里的成员才有被选为leader的可能。
注：ISR中包括：leader和follower。
- HW 与 LEO
HW，HighWatermark，高水位，表示 Consumer 可以消费到的最高 partition 偏移量。HW保证了 Kafka 集群中消息的一致性。
LEO，Log End Offset，日志最后消息的偏移量。消息在 Kafka 中是被写入到日志文件中的，这是当前最后一个消息在 Partition 中的偏移量。
对于 Leader 中新写入的消息，必须等待 ISR 中的所有 Follower 全部同步完毕后，HW的值才会被更新，并写入到 ISR 中，此时该消息才能被消费。
下图是一张关于 HW 上涨原理的示意图。
- consumer group
consumer group 是 kafka 提供的可扩展且具有容错性的消费者机制。组内可以有多个消费者，它们共享一个公共的 ID，即 group ID。组内的所有消费者协调在一起来消费订阅主题的所有分区。
组中 consumer 数量与 partition 数量的对应关系如下。
- zookeeper
用来保障分布式应用一致性的中间件。
Zookeeper 负责维护和协调 broker。当 Kafka 系统中新增了 broker 或者某个 broker 发生故障失效时，由ZooKeeper通知Producer和Consumer。Producer和Consumer会依据Zookeeper的 broker 状态信息与 broker 协调消息的发布和订阅任务。当然，zk 还负责Broker Controller的选举。
需要注意，从 Kafka 0.9 开始 offset 的管理与保存机制发生了很大的变化——zookeeper中不再保存和管理 offset 了。
- Coordinator
Coordinator 一般指的是运行在每个 broker 上的 group Coordinator，用于管理Consumer Group 中的各个成员，主要用于 offset 位移管理和 Rebalance，可以同时管理多个消费者组。
- Rebalance
再均衡。当发生以下情况时，partition 的所有权在消费者间转移，这个过程称为再均衡Rebalance。在 Rebalance 期间 broker 集群中不可用的。所以，Kafka 无法保证 AP。
1）消费者组中新添加消费者
2）消费者关闭、崩溃或取消订阅后离开群组
3） 当向一个 Topic 添加新的 partition
4） 当有 broker 挂了，即有 partition 挂了
- offset commit
Consumer 在消费过消息后需要将其消费的消息的 offset 提交给 broker，以让 broker 记录下哪些消息是消费过的。记录已消费过的 offset 值有什么用呢？除了用于标识哪些消息将来要被删除外，还有一个很重要的作用：在发生再均衡时不会引发消息的重复消费。
其实，若消费者与 broker 集群一直处于正常运行状态，那么每个 partition 中记录的offset没什么用处。但若发生再均衡，则在完成再均衡后，每个消费者可能分配到新的partition，而不是之前处理过的那个 partition。为了继续之前的工作，消费者需要读取每个 partition 最后一次提交的 offset，然后从 offset 指定的地方继续处理。__consumer_offset