【Kafka】kafka的基本介绍
目录
第1章 Kafka应用场景
1.1 用户的活动追踪
用户在网站的不同活动消息发布到不同的主题中心，然后可以对这些消息进行实时监测实时处理。当然，也可加载到 Hadoop 或离线处理数据仓库，对用户进行画像。像淘宝、京 东这些大型的电商平台，用户的所有活动都是要进行追踪的。
1.2 日志聚合
kafka的特性决定它非常适合作为"日志收集中心"；application可以将操作日志"批量""异步"的发送到kafka集群中，而不是保存在本地或者DB中;kafka可以批量提交消息/压缩消息等，这对producer端而言，几乎感觉不到性能的开支。此时consumer端可以使hadoop等其他系统化的存储和分析系统。
1.3 限流消峰
第2章 Kafka高吞吐的实现
Kafka 与其它 MQ 相比，其最大的特点就是高吞吐率。为了增加存储能力，Kafka 将所有 的消息都写入到了低速大容的硬盘。按理说，这将导致性能损失，但实际上，kafka 仍可保 持超高的吞吐率，性能并未受到影响。其主要采用了如下的方式实现了高吞吐率。
- 顺序读写：Kafka将消息写入到分区partition中，而分区中消息是顺序读写的，要远快于随机读写。
- 零拷贝：生产者、消费者对于kafka中消息的操作是采用零拷贝实现的。
- 批量发送：Kafka允许使用批量消息发送模式。
- 消息压缩：Kafka支持对消息集合进行压缩。
第3章 Kafka的基本术语
3.1 简介
先来看一张图：
如上图所示，kafka基本可以分为三层。
- 主题层（topic）：每个主题可以配置N个分区(partition)，而每个分区又可以配置M分副本（replica）。
- 分区层：每个分区的N个副本中只能有个以充当领导者角色（leader），对外提供服务；其他N-1个副本是追随者（follower），只是提供数据冗余使用。（生产者/消费者总是向leader副本写/读消息。至于追随者副本，只做一件事：想leader副本发送请求，请求leader把最新生产的消息发给他， 以至于和leader保持同步。）
- 消息层：分区中包含若干条消息，每条消息的位移从0开始，依次递增。
3.2 基本术语
3.2.1 topic
主题。在 Kafka 中，使用一个类别属性来划分消息的所属类，划分消息的这个类称为 topic。 topic 相当于消息的分类标签，是一个逻辑概念。
3.2.2 partition
分区。topic中的消息被分割为1个或多个partition，是一个物理概念，对应到系统上就是一个或若干个目录。分区本身就是一个FIFO的队列，所以分区中的消息是有序的。但分区的消息丢失了其顺序性。
一般情况下一个topic的分区数量是broker数量的整数倍。
3.2.3 segment
段。将 partition 进一步细分为了若干的 segment，每个 segment 文件的最大大小相等。
3.2.4 broker
Kafka 集群包含一个或多个服务器，每个服务器节点称为一个 broker。
假设某 topic 中具有 N 个分区，集群*有 M 个 broker。则分区与 broker 间的关系是：
若 N>M 且 N%M=0，则每个 broker 会平均存储这些分区。
若 N>M 且 N%M!=0，则每个 broker 中的分区是不平均的。
若 N<M，则会有 N 台 broker 中具有一个分区，另外 M-N 台 broker 中是没有分区的
3.2.5 producer
生产者。即消息的发布者，其会将某 topic 的消息发布到相应的 partition 中。 生产者所生产的消息默认会平均分配到各个分区，但也可以直接指定要写入的分区，也可根据消息的 key 来计算路由。
3.2.6 consumer
消费者。可以从 broker 中读取消息。
一个消费者可以消费多个 topic 中的消息。
一个消费者可以消费同一个 topic 中的多个 partition 中的消息。
一个分区中的消息允许多个无关的消费者同时消费。
3.2.7 consumer group
consumer group 是 kafka 提供的可扩展且具有容错性的消费者机制。组内可以有多个消 费者，它们共享一个公共的 ID，即 group ID。组内的所有消费者会协调在一起平均消费（对 分区的消费是平均的，但对于消息的消费不一定是平均的）订阅主题的所有分区。
Kafka 可以保证在稳定状态下，一条消息只能被同一个 consumer group 中的一个 consumer 消费，当然，一个消息可以同时被多个 consumer group 消费。另外，Kafka 还可以 保证，在稳定状态下每一个组内 consumer 只会消费某一个或几个特定的 partition。
3.2.8 raplicas of partition
分区副本。副本是一个分区的备份，是为了防止消息丢失而创建的分区的备份。
3.2.9 partiion leader
每个 partition 有多个副本，其中有且仅有一个作为 Leader，Leader 是当前负责消息读写 的 partition。即所有读写操作只能发生于 Leader 分区上。 Leader 与 Follower 是主备关系，不是主从关系。 Leader 宕机后，Broker Controller 会从 Follower 中选举出一个新的 Leader。 注意，这个选举不是由 zk 完成的。
3.2.10 partition follower
所有 Follower 都需要从 Leader 同步消息，Follower 与 Leader 始终保持消息同步。
3.2.11 ISR
ISR，In-Sync Replicas，是指副本同步列表。
ISR 列表是由 Leader 负责维护。
Assigned Replicas，AR
AR = ISR OSR，Outof-Sync Replicas， AR = ISR + OSR
3.2.12 offset
偏移量。每条消息都有一个当前 Partition 下唯一的 64 字节的 offset，它是相对于当前 分区第一条消息的偏移量。
3.2.13 broker controller
Kafka 集群的多个 broker 中，有一个会被选举为 controller，负责管理整个集群中 partition 和 replicas 的状态。
3.2.14 HW和LEO
HW，HighWatermark，高水位，表示 Consumer 可以消费到的最高 partition 偏移量。HW 保证了 Kafka 集群中消息的一致性。确切地说，是保证了 partition 的 Follower 与 Leader 间数 据的一致性。
LEO，Log End Offset，日志最后消息的偏移量。消息是被写入到 Kafka 的日志文件中的， 这是当前最后一个写入的消息在 Partition 中的偏移量。
对于 leader 新写入的消息，consumer 是不能立刻消费的。leader 会等待该消息被所有 ISR 中的 partition follower 同步后才会更新 HW，此时消息才能被 consumer 消费
3.2.15 zookeeper
Zookeeper 负责维护和协调 broker，负责 Broker Controller 的选举。
3.2.16 coordinator
Coordinator 一般指的是运行在每个 broker 上的 group Coordinator 进程，用于管理 Consumer Group 中的各个成员，主要用于 offset 位移管理和 Rebalance。一个 Coordinator 可 以同时管理多个消费者组。
3.2.17 rebalance
当消费者组中消费者数量发生变化，或Topic 中的 partition数量发生了变化时， partition 的所有权会在消费者间转移，即 partition 会重新分配，这个过程称为再均衡 Rebalance。
再均衡能够给消费者组及 broker 集群带来性高可用性和伸缩，但在再均衡期间消费者 是无法读取消息的，即整个 broker 集群有一小段时间是不可用的。因此要避免不必要的再 均衡。
3.2.18 offset commit
Consumer 从 partition 中取出一批消息写入到 buffer 对其进行消费，在规定时间内消费 完消息后，会自动将其消费消息的 offset 提交给 broker，以让 broker 记录下哪些消息是消费 过的。当然，若在时限内没有消费完毕，其是不会提交 offset 的。