kafaka 简介
Apache Kafka
是一个快速、可扩展的、高吞吐的、可容错的分布式
“
发布
-
订阅
”
消息系统， 使用 Scala
与
Java
语言编写，能够将消息从一个端点传递到另一个端点，较之传统的消息中间件（例如 ActiveMQ
、
RabbitMQ
），
Kafka
具有高吞吐量、内置分区、支持消息副本和高容 错的特性，非常适合大规模消息处理应用程序。
Kafka
官网：
http://kafka.apache.org/
kafaka 系统架构
kafaka 应用场景
用户的活动追踪：
用户在网站的不同活动消息发布到不同的主题中心，然后可以对这些消息进行实时监测实时处理。当然，也可加载到 Hadoop 或离线处理数据仓库，对用户进行画像。像淘宝、京东这些大型的电商平台，用户的所有活动都是要进行追踪的。
日志聚合:
限流削峰:
kafaka特性之高吞吐
Kafka
与其它
MQ
相比，其最大的特点就是高吞吐率。为了增加存储能力，
Kafka
将所有的消息都写入到了低速大容的硬盘。按理说，这将导致性能损失，但实际上，kafka
仍可保 持超高的吞吐率，性能并未受到影响。其主要采用了如下的方式实现了高吞吐率。
顺序读写：
Kafka
将消息写入到了分区
partition
中，而分区中消息是顺序读写的。顺序
读写要远快于随机读写。
零拷贝：生产者、消费者对于
kafka
中消息的操作是采用零拷贝实现的。
批量发送：
Kafka
允许使用批量消息发送模式。
消息压缩：
Kafka
支持对消息集合进行压缩。
kafaka 集群搭建(windows)
参考文章：Windows 搭建Kafka 集群
kafaka 专业术语
Topic（主题）：
主题。在 Kafka 中，使用一个类别属性来划分消息的所属类，划分消息的这个类称为 topic。topic 相当于消息的分类标签，是一个逻辑概念。
Partition（分区）：
分区。topic 中的消息被分割为一个或多个 partition，其是一个物理概念，对应到系统上就是一个或若干个目录。partiiton 本身是一个 FIFO 队列，其中的消息是有序的。但在 Partition 间无法保证消息的顺序性。
segment(段):
段。将 partition 进一步细分为了若干的 segment，每个 segment 文件的最大大小相等。
Broker(中间件)
Kafka 集群包含一个或多个服务器，每个服务器节点称为一个 broker。
假设某个 topic 中有 N 个 partition，集群中有 M 个 Broker，broker 与 partition 间的数量
关系：
若 N>=M，且（N%M=0），则每个 broker 上会平均存储 N/M 个 partition。
若 N>M，且（N%M!=0），这其中会出现 broker 上分配的 partition 不平均的情况。这种情况要避免。
若 N<M，这种情况会出现有的 broker 上没有分到 partition 的情况。
Producer(生成者)
生产者。即消息的发布者，其会将某 topic 的消息发布到相应的 partition 中。
Consumer(消费者)
消费者。可以从 broker 中读取消息。
一个消费者可以消费多个 topic 的消息。
一个消费者可以消费同一个 topic 中的多个 partition 消息。
一个 partition 允许多个无关消费者同时消费。
扫描二维码关注公众号，回复：
12313645 查看本文章
Consumer Group(消费组)
consumer group 是 kafka 提供的可扩展且具有容错性的消费者机制。组内可以有多个消费者，它们共享一个公共的 ID，即 group ID。组内的所有消费者会协调在一起平均消费订阅主题的所有分区。
Kafka 可以保证在稳定状态下，一个 partition 中的消息只能被同一个 consumer group 中的一个 consumer 消费，而一个组内 consumer 只会消费某一个或几个特定的 partition。当然，一个消息可以同时被多个 consumer group 消费。
总结：
组内 consumer 与 partition 的关系 1:n
partition 与组内 consumer 的关系 1:1
这种设计方式的好处是：实现简单，弊端是：消息分配不均。
组中 consumer 数量与 partition 数量的对应关系如下。
Replicas of partition(分区副本)
分区副本。副本是一个分区的备份，是为了防止消息丢失而创建的分区的备份。
Partition Leader(分区领导)
每个 partition 有多个副本，其中有且仅有一个作为 Leader，Leader 是当前负责消息读写的 partition。即所有读写操作只能发生于 Leader 分区上。
Partition Follower(分区跟随者)
所有 Follower 都需要从 Leader 同步消息，Follower 与 Leader 始终保持消息同步。partition leader 与 follower 是主备关系，而非主从
ISR
ISR
，
In-Sync Replicas
，是指副本同步列表。
AR
，
Assigned Replicas
OSR
，
Outof-Sync Replicas
AR = ISR + ORS
offset(偏移量)
偏移量。每条消息都有一个当前 Partition 下唯一的 64 字节的 offset，它是相对于当前分区第一条消息的偏移量
offset commit(偏移量提交)
Consumer 从 partition 中取出一批消息写入到 buffer 对其进行消费，在规定时间内消费完消息后，会自动将其消费消息的 offset 提交给 broker，以让 broker 记录下哪些消息是消费过的。当然，若在时限内没有消费完毕，其是不会提交 offset 的。
提交的 offset 被写入到了一个特殊的主题__consumer_offsets 中。
其中在 kafka0.9 版本之前，offset 是由 zk 负责保存管理的，之后版本由 kafka broker 负责保 存管理。
Rebalance(负载均衡)
当消费者组中消费者数量发生变化，或 Topic 中的 partition 数量发生了变化时，partition的所有权会在消费者间转移，即 partition 会重新分配，这个过程称为再均衡 Rebalance。
再均衡能够给消费者组及 broker 集群带来高可用性和伸缩性，但在再均衡期间消费者是无法读取消息的，即整个 broker 集群有一小段时间是不可用的。因此要避免不必要的再均衡。
HW 与 LEO
HW
，
HighWatermark
，高水位，表示
Consumer
可以消费到的最高
partition
偏移量。
HW
保证了
Kafka
集群中消息的一致性。确切地说，是在
broker
集群正常运转的状态下，保证了
partition
的
Follower
与
Leader
间数据的一致性。
LEO
，
Log End Offset
，日志最后消息的偏移量。消息是被写入到
Kafka
的日志文件中的，
这是当前最后一个写入的消息在
Partition
中的偏移量。
对于
leader
新写入的消息，
consumer
是不能立刻消费的。
leader
会等待该消息被所有
ISR
中的
partition follower
同步后才会更新
HW
，此时消息才能被
consumer
消费。
Broker Controller(中间件控制层)
Kafka
集群的多个
broker
中，有一个会被选举为
controller
，负责管理整个集群中
partition
和副本
replicas
的状态。
当
partition leader
宕机后，
broker controller
会从
ISR
中选举出一个
Follower
做为新的
leader
。所谓选举就是从
ISR
中找到第一个
Follower
，直接让其当选新的
leader
。
Broker Controller
是由
zk
选举出来的。
Zookeeper
Zookeeper 负责维护和协调 broker，负责 Broker Controller 的选举。
Coordinator(协调者)
Coordinator
一般指的是运行在每个
broker
上的
group Coordinator
进程，用于管理
Consumer Group
中的各个成员，主要用于
offset
位移管理和
Rebalance
。一个
Coordinator
可
以同时管理多个消费者组。
kafaka 工作原理和过程
消息路由策略
在通过
API
方式发布消息时，生产者是以
Record
为消息进行发布的。
Record
中包含
key
与
value
，
value
才是我们真正的消息本身，而
key
用于路由消息所要存放的
Partition
。消息
要写入到哪个
Partition
并不是随机的，而是有路由策略的。
1)
若指定了
partition
，则直接写入到指定的
partition
；
2)
若未指定
partition
但指定了
key
，则通过对
key
的
hash
值与
partition
数量取模，该取模
结果就是要选出的
partition
索引；
3)
若
partition
和
key
都未指定，则使用轮询算法选出一个
partition
。
消息写入算法
消息生产者将消息发送给
broker
，并形成最终的可供消费者消费的
log
，是一个比较复
杂的过程。
1) producer
向
broker
集群提交连接请求，其所连接上的任意
broker
都会向其发送
broker
controller
的通信
URL
，即
broker controller
主机配置文件中的
listeners
地址
2)
当
producer
指定了要生产消息的
topic
后，其会向
broker controller
发送请求，请求当前
topic
中所有
partition
的
leader
列表地址
3) broker controller
在接收到请求后，会从
zk
中查找到指定
topic
的所有
partition
的
leader
，
并返回给
producer
4) producer
在接收到
leader
列表地址后，根据消息路由策略找到当前要发送消息所要发送
的
partition leader
，然后将消息发送给该
leader
5) leader
将消息写入本地
log
，并通知
ISR
中的
followers
6) ISR
中的
followers
从
leader
中同步消息后向
leader
发送
ACK
7) leader
收到所有
ISR
中的
followers
的
ACK
后，增加
HW
，表示消费者已经可以消费到该
位置了
HW 截断机制
如果
partition leader
接收到了新的消息，
ISR
中其它
Follower
正在同步过程中，还未同
步完毕时
leader
挂了。此时就需要选举出新的
leader
。若没有
HW
截断机制，将会导致
partition
中
leader
与
follower
数据的不一致。
消息发送的可靠性机制
生产者向 kafka 发送消息时，可以选择需要的可靠性级别。通过 acks 参数的值进行设置。
（
1
）
0
值
异步发送。生产者向
kafka
发送消息而不需要
kafka
反馈成功
ack
。该方式效率最高，但
可靠性最低。其可能会存在消息丢失的情况。
（
2
）
1
值
同步发送，默认值。生产者发送消息给
kafka
，
broker
的
partition leader
在收到消息后
马上发送成功
ack
（无需等待
ISR
中的
follower
同步完成），生产者收到后知道消息发送成功，
然后会再发送消息。如果一直未收到
kafka
的
ack
，则生产者会认为消息发送失败，会重发
消息。
（
3
）
-1
值
同步发送。其值等同于
all
。生产者发送消息给
kafka
，
kafka
收到消息后要等到
ISR
列表
中的所有副本都同步消息完成后，才向生产者发送成功
ack
。如果一直未收到
kafka
的
ack
，
则认为消息发送失败，会自动重发消息。
消费者消费过程解析
生产者将消息发送到
topic
中，消费者即可对其进行消费，其消费过程如下：
1) consumer
向
broker
集群提交连接请求，其所连接上的任意
broker
都会向其发送
broker
controller
的通信
URL
，即
broker controller
主机配置文件中的
listeners
地址
2)
当
consumer
指定了要消费的
topic
后，其会向
broker controller
发送
poll
请求
3) broker controller
会为
consumer
分配一个或几个
partition leader
，并将该
partitioin
的当
前
offset
发送给
consumer
4) consumer
会按照
broker controller
分配的
partition
对其中的消息进行消费
5)
当消费者消费完该条消息后，消费者会向
broker
发送一个该消息已被消费的反馈，即
该消息的
offset
6)
当
broker
接到消费者的
offset
后，会更新到相应的
__consumer_offset
中
7)
以上过程一直重复，直到消费者停止请求消息
8)
消费者可以重置
offset
，从而可以灵活消费存储在
broker
上的消息
Partition Leader 选举范围
当
leader
挂了后
broker controller
会从
ISR
中选一个
follower
成为新的
leader
。但，若
ISR
中的所有副本都挂了怎么办？可以通过
unclean.leader.election.enable
的取值来设置
Leader
选举的范围。
（
1
）
false
必须等待
ISR
列表中有副本活过来才进行新的选举。该策略可靠性有保证，但可用性低。
（
2
）
true
在
ISR
中没有副本的情况下可以选择任何一个没有宕机主机中该
topic
的
partition
副本
作为新的
leader
，该策略可用性高，但可靠性没有保证。
重复消费问题及解决方案
参考文章地址:Kafka重复消费场景及解决方案
