KafKa 架构和实战
KafKa 介绍
Kafka 是一个分布式,分区的,多副本,多生产者,多订阅者,基于zookeeper协调的分布式日志系统(也可以当做MQ系统),常见可以用于web/nginx日志,访问日志, 消息服务等等,主要应用场景是:日志收集系统和消息系统。
kafka 主要设计目标:
- 以时间复杂度o(1)的方式提供消息持久化能力,即使对TB级以上数据也能保证正常时间的访问性能。
- 高吞吐率,最低一般也是每秒100k条消息的传递
- 支持kafka server键的消息分区,及分布式消费,同时保证每个partition内的消息顺序传输
- 同时支持离线数据处理和实施数据处理
- 支持在线水平拓展
两种主要的消息传递模式:
- 点对点模式
-
发布-订阅模式 大部分的消息选用的是发布-订阅模式,kafka 是一种发布订阅模式 对于消息中间件,消息分推拉两种模式,kafka 只有消息的拉取,没有推送,可以通过轮询实现消息的推送。
-
kafka 在一个或多个可以跨越多个数据中心的服务器上作为集群运行。
- kafka 集群中按照主题分类管理,一个主题可以有多个分区,一个分区可以有多个副本分区。
- 每个记录由一个键,一个值和一个时间戳组成。
kafka 四个核心API:
- producer API : 允许应用程序将记录流发布到一个或多个kafka 主题
- Consumer API: 允许应用程序订阅一个或多个主题并处理为其生成的记录流
- Streams API: 允许应用程序充当流处理器,使用一个或多个主题的输入流,并生成一个或多个输出主题的输出流,从而有效地把输入流转换为输出流。
- Connector API: 允许构建和运行将kafka主题链接到现有应用程序或数据系统的可重用生产者或者使用者,例如,关系数据库的连接器可能会捕获对表的所有更改。
KafKa 优势
- 高吞吐量:单机每秒处理几十上百万的消息量,即使存储了许多TB 消息,也能保持稳定的性能
- 高性能: 单个节点可以支持上千个客户端,保证0停机和零数据的丢失
- 持久化数据存储: 将消息持久化到磁盘,通过数据持久化到硬盘以及replication 防止数据丢失 0拷贝 顺序读,顺序写 利用Linux的页缓存
- 分布式系统,易于向外拓展,所有的producer ,broker 和consumer 都会有多个,均为分布式的,无需停机即可拓展机器,多个producer,consumer可能是不同的应用。
- 可靠性-kafka 是分布式,分区,复制和容错的。
- 客户端状态维护: 消息被处理的状态是在consumer 端维护,不是由server 端维护,当失败时能自动平衡。
- 支持 online和 offline的场景
- 支持多种客户端语言。
kafka 应用场景
- 日志收集: 手机各种服务的log,通过统一接口服务的方式开放给各种consumer;
- 消息系统: 解耦生产者和消费者,缓存消息等
- 用户活动跟踪: 记录web或者app 的活动,活动信息被服务器发布到kafka的topic,然后消费者订阅topic来做实时的监控分析,也可以存在数据库
- 运营指标: 收集各种分布式应用的数据,生产各种操作的集中反馈,比如报警和报告
- 流式处理:spark streaming 和storm
基本架构
消息和批次
kafka 的数据单元称为消息,可以把消息看成数据库中一个数据行或者一条记录,消息由字节数组成,消息有键,键也是一个字节数组, 当消息以一种可控的方式写入不同的分区时,会用到键,为了提高效率,消息被分批写入kafka,批次就是一组消息,这些消息属于同一个主题和分区 把消息分成批次可以减少网络开销,批次越大,单位时间内处理的消息就越多,单个消息的传输时间就越长,批次数据被压缩,这样可以提升数据的 传输和生存能力,但是需要更多的计算处理。
模式
消息模式schema 有许多选项,像json 和xml ,但是缺乏强类型处理能力,可以使用apache avro,avro 提供了一种紧凑的序列化格式,消息和模式分开, 当模式发生变化时,不需要重新生成代码,还支持强类型和模式进化,数据格式一致性消除了消息读写操作之间的耦合性。
主题和分区
kafka 消息通过主题进行分类,主题类似于数据库表或者文件系统里的文件夹,主题可以被分为若干分区,一个主题通过分区分布于kafka集群中,提供了横向拓展的能力
生产者消费者
生产者创建消息,消费者消费消息 一个消息被发布到一个特定的主题上,生产者在默认情况下把消息均衡地分不到主题的所有分区上: 直接指定消息的分区 根据消息的key散列取模得出分区 轮询指定分区 消费者通过偏移量来区分已经读过的消息,从而消费消息。 消费者是消费组的一部分,消费组保证每个分区只能被一个消费者使用,避免重复消费
broker 和集群
一个独立的kafka 是一个broker,broker 接受来自生产者消息,为消息设置偏移量,并提交到磁盘保存,
broker 为消费者提供服务,对读取分区的请求做出响应,返回已经提交到磁盘上的消息,单个broker 可以轻松处理数千个分区以及每秒百万的消息量。
每个集群都有一个broker是集群控制器(自动从集群的活跃成员中选举出来)控制器负责管理工作:zookeeper 临时分布式锁
将分区分配给broker
监控broker
集群的一个分区属于一个broker为分区首领
一个分区可以分配给多个broker,此时会发生分区复制。
分区复制提供了消息冗余,高可用副本分区不负责消息的读写。
producer
生产者创建消息,该角色将消息发布到Kafka 的topic 中broker 接受到生产者发送的消息后,broker 把消息追加到当前用于追加数据的segment 文件中,一般情况下,一个消息会被发布到一个特定的主题上
- 默认情况下,通过轮询把消息均衡地发布到主题的所有分区上
- 在某些情况下,生产这会把消息直接写到指定的分区,通过消息键和分区器来实现,分区器为键生成一个散列值,将其映射到指定的分区上,这样可保证包含通一个键的消息会被写到同一个分区上。
- 生产者也可以使用自定义的分区器,根据不同的业务规则将消息映射到分区。
consumer
消费者读取消息
- 消费者订阅一个或者多个主题,并且按照消息生成的顺序读取他们
- 消费者通过检查消息的偏移量来区分已经读取过的消息,偏移量是另一种元数据,它是一个不断递增的整数值,在创建消息时,kafka 会把它添加到消息里,在给定的分区里,每个消息的偏移量都是唯一的,消费者把每个分区最后读取的消息偏移量保存在zookeeper 或 kafka 上,如果消费者关闭或重启,他的读取状态不会丢失
- 消费者是消费组的一部分,确保每个分区只能被一个消费者使用
- 如果一个消费者失效,消费组里的其他消费者可以接管失效消费者的工作,再平衡,分区重新分配
Broker
一个独立的kafka服务器成为broker,broker为消费者提供服务,对读取分区的请求做出响应,返回已经提交到磁盘上的消息。
- 如果某topic 有N 个partition ,集群有N个broker,每个broker 存储该topic 的一个partition
- 如果某topic 有 N 个partition ,集群有(N+M)个broker,那么其中N个broker 存储该topic 的一个partition,剩下的M个broker 不存储该topic 的partition
-
如果某topic 有 N 个partition ,集群中 broker少于N个,那么一个 broker存储该topic 的一个或多个partition ,会造成kafka 集群不均衡
broker 是集群的组成部分,每个集群都有一个broker, 同时充当了集群控制器的角色 控制器负责管理工作,包括将分区分配给broker 和监控broker 在集群中,一个分区从属于一个broker,该broker被成为分区的首领
Topic
每条发布到kafka 集群的消息都有一个类别,这个类别被称为Topic
物理上不同topic 的消息分开存储
主题就好比数据库的表,尤其是分库分表之后的逻辑表。
Partition
- 主题可以被分为若干个分区,一个分区就是一个提交日志
- 消息以追加的方式写入分区,然后以先入先出的顺序读取
- 无法在整个主题范围内保证消息的顺序,但可以保证消息在单个分区内的顺序
- kafka通过分区来实现数据冗余和伸缩性。
- 需要严格保证消息的消费顺序的场景下,需要将partition数目设置为1
replicas
kafka使用主题来组织数据,每个主题被分为若干个分区,每个分区有多个副本,那些副本被保存在broker上,每个broker 可以保存成百上千个属于不同主题和分区的副本。 副本有以下两种类型:
- 首领副本,每个分区都有一个首领副本,为了保证一致性,所有生产者请求和消费者请求都会经过这个副本。
- 跟随者副本,首领副本之外的副本都是跟随者副本,跟随者副本不处理来自客户端的请求,他们的唯一任务就是从首领那里复制消息,保持与首领一致的状态,如果首领发生崩溃,其中的一个跟随者会被提升为新首领。
offset
生产者offset
消息写入的时候,每个分区都有一个offset,这个offset 就是生产者offset,同时也是这个分区的最新最大的offset 有些时候没有指定某一个分区的offset,这个工作kafka帮我们完成
副本
kafka通过副本保证高可用,副本分为首领副本和追随者副本,跟随者副本包括同步副本和不同步副本,在发生首领副本切换时候, 只有同步副本可以切换为首领副本,
AR
分区中的所有副本统称为AR AR=ISR+OSR
ISR
所有与 leader 副本保持一定程度同步的副本,包括leader 组成ISR ,ISR 集合是AR 集合中的一个子集,消息也会发送到leader副本, 然后follower副本才能从leader 副本中拉取消息进行同步,同步期间内follower 副本相对于leader 副本而言会有一定程度的滞后,可以通过参数进行配置。
OSR
与Leader副本同步滞后过多的副本(不包括leader) 副本,组成osr,在正常情况下,所有的follower副本都应该与 Leader 副本保持一定程度的同步,即AR=ISR ,OSR 集合为空。
HW
HW 是High Watermak 的缩写,表示一个特定消息的偏移量,消费只能拉取到这个offset之前的消息
LEO
last end offset 当前日志文件中下一条待写入消息的offset