没有合适的资源?快使用搜索试试~ 我知道了~
2. 如果没有可用的分区,则在该主题所有分区中分配分区号 1. 会首先在可用的分区中分配分区号 3. 如果record没有提供分区号,也没有提供key,则使用轮
资源详情
资源评论
资源推荐
2. 如果没有可用的分区,则在该主题所有分区中分配分区号。
1. 会首先在可用的分区中分配分区号
3. 如果record没有提供分区号,也没有提供key,则使用轮询的方式分配分区
号。
1. 如果record提供了分区号,则使用record提供的分区号
2. 如果record没有提供分区号,则使用key的序列化后的值的hash值对分区
数量取模
分区规则
分区器
6. 元数据返回有两种方式:一种是通过阻塞直接返回,另一种是通过回调返
回。
5. 落盘到 broker 成功,返回生产元数据给生产者。
4. 批次发送后,发往指定分区,然后落盘到 broker;如果生产者配置了
retrires 参数大于 0 并且失败原因允许重试,那么客户端内部会对该消息进行
重试。
3. 批次发送的条件为:缓冲区数据大小达到 batch.size 或者 linger.ms 达到
上限,哪个先达到就算哪个。
2. 生产消息时,内部其实是异步流程;生产的消息先经过拦截器->序列化器-
>分区器,然后将消息缓存在缓冲区(该缓冲区也是在Producer创建时创
建)。
1. Producer创建时,会创建一个Sender线程并设置为守护线程。
生产流程
允许重试但是不设置 max.in.flight.requests.per.connection 为1,存在
消息 乱序的可能,因为如果两个批次发送到同一个分区,第一个失败了 重
试,第二个成功了,则第一个消息批在第二个消息批后。i
retries
bootstrap.servers
key.serializer
compression.type
value.serializer
leader等待所有同步的副本确认该消息。保证了只要有 一个同步副本存在,
消息就不会丢失。这是最强的可用性保证。等 价于acks=-1。
all / -1
不能保证服务器是否收到该 消息,retries设置也不起作用,因为客户端不关
心消息是否发送 失败。客户端收到的消息偏移量永远是-1。
生产者不等待broker的任何消息确认。只要将消息放到了 socket的缓冲区,
就认为消息已发送。
0
如果leader确认了消息就宕机,则可 能会丢失消息,因为follower副本可能
还没来得及同步该消息。
leader将记录写到它本地日志,就响应客户端确认消息, 而不等待follower
副本的确认。
1
acks
参数配置
生产者
一般更推荐选择将 offset 保存在 kafka 自己的 __consumer_offsets 的主题
中,不建议存到 ZooKeeper,因为 ZooKeeper 不适合高并发
3. 消费组订阅的主题每个分区只能分配给消费组一个消费者。
1. 消费组有一个或多个消费者,消费者可以是一个进程,也可以是一个线程
2. group.id是一个字符串,唯一标识一个消费组
特性
所以向消费者组添加消费者是横向扩展消费能力的主要方式
当消费者组中只有一个消费者时,每个分区的消息都由该消费者消费
当消费者组中的消费者数大于分区时,多出来的消费者会被闲置,订阅不到任
何消息
当消费者组中的消费者数与分区数相同时,每个消费者都可以分配到一个分区
消费策略
消费者组
bootstrap.servers
Offset
3. 生产者也可以使用自定义的分区器,根据不同的业务规则将消息映射到分
区。
1. 默认情况下通过轮询把消息均衡地分布到主题的所有分区上。
2. 在某些情况下,生产者会把消息直接写到指定的分区。这通常是通过消息
键和分区器来实现的,分区器为键生成一个散列值,并将其映射到指定的分区
上。这样可以保证包含同一个键的消息会被写到同一个分区上。
生产策略
生产者将消息发布到 Kafka 的 topic 中。broker 接收到生产者发送的消息
后,broker 将该消息追加到 当前用于追加数据的 segment 文件中
Producer
LEO(Log End Offset):表示了当前日志文件中下一条待写入消息的
offset
OSR(Out-Sync Replicas)
ISR(In-Sync Replicas)
AR(Assigned Replicas):分区中所有副本的统称
HW(High Watermark):俗称高水位,它表示了一个特定消息的偏移量
分类
首领以外的副本都是跟随者副本。跟随者副本不处理来自客户端的请求,它们
唯一的任务就是从首领那里复制消息,保持与首领一致的状态。如果首领发生
崩溃,其中的一个跟随者会被提升为新首领。
跟随者副本包括同步副本和不同步副本,在发生首领副本切换的时候,只有同
步副本可以切换为首领副本。
跟随者副本
每个分区都有一个首领副本。为了保证一致性,所有生产者请求和消费者请求
都会经过这个副本。
首领副本
Replicas
4. 如果一个消费者失效,消费组里的其他消费者可以接管失效消费者的工
作,再平衡,分区重新分配。
1. 消费者订阅一个或多个主题,并按照消息生成的顺序读取它们。
3. 消费者是消费组的一部分。群组保证每个分区只能被一个消费者使用。
2. 消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量是另一种
元数据,它是一个不断递增的整数值,在创建消息时,Kafka 会把它添加到消
息里。在给定的分区里,每个消息的偏移量都是唯一的。消费者把每个分区最
后读取的消息偏移量保存在Zookeeper 或Kafka上,如果消费者关闭或重
启,它的读取状态不会丢失。
Consumer
5. 在需要严格保证消息的消费顺序的场景下,需要将partition数目设为1。
1. 主题可以被分为若干个分区,一个分区就是一个提交日志。
4. Kafka 通过分区来实现数据冗余和伸缩性。
2. 消息以追加的方式写入分区,然后以先入先出的顺序读取。
3. 无法在整个主题范围内保证消息的顺序,但可以保证消息在单个分区内的
顺序。
Partition
3. 如果某topic有N个partition,集群中broker数目少于N个,那么一个
broker存储该topic的一个或多个partition。在实际生产环境中,尽量避免这
种情况的发生,这种情况容易导致Kafka集群数据不均衡。
1. 如果某topic有N个partition,集群有N个broker,那么每个broker存储该
topic的一个 partition。
2. 如果某topic有N个partition,集群有(N+M)个broker,那么其中有N个
broker存储该topic的一个partition,剩下的M个broker不存储该topic的
partition数据。
Broker
Topic
核心概念
Connector API:允许构建和运行将 Kafka 主题连接到现有应用程序或数据
系统的可重用生产者或使用者。例如,关系数据库的连接器可能会捕获对表的
所有更改。
Producer API:允许应用程序将记录流发布到一个或多个Kafka主题。
Streams API:允许应用程序充当流处理器,使用一个或多个主题的输入
流,并生成一个或多个输出主题的输出流,从而有效地将输入流转换为输出
流。
Consumer API:允许应用程序订阅一个或多个主题并处理为其生成的记录
流。
四个核心 API
常见可以用于 web/nginx 日志、访问日志,消息服务等等
一个分布式、分区的、多副本的、多生产者、多订阅者,基于 zookeeper 协
调的分布式日志系统
概述
消息系统
日志收集系统
主要应用场景
每个记录由一个键,一个值和一个时间戳组成。
一般的消息中间件,消息分推(push)/拉(poll)两种模式,Kafka 只有拉
(poll),没有推(push),可以通过轮询实现消息的推送
Kafka 集群中按照主题分类管理,一个主题可以有多个分区,一个分区可以有
多个副本分区。
Kafka 在一个或多个可以跨越多个数据中心的服务器上作为集群运行。
特点
支持在线水平扩展
以时间复杂度为 O(1) 的方式提供消息持久化能力,即使对TB级以上数据也能
保证常数时间的访问性能。
同时支持离线数据处理和实时数据处理。
支持 Kafka Server 间的消息分区,及分布式消费,同时保证每个 partition
内的消息顺序传输。
高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒 100K 条消息
的传输。
主要设计目标
Kafka 属于这种
发布 - 订阅模式
点对点传递模式
两种消息传递模式
基本介绍
8. 支持多种客户端语言。Kafka支持Java、.NET、PHP、Python等多种语
言。
1. 高吞吐量:单机每秒处理几十上百万的消息量。即使存储了许多TB的消
息,它也保持稳定的性能。
7. 支持 online 和 offline 的场景。
2. 高性能:单节点支持上千个客户端,并保证零停机和零数据丢失。
6. 客户端状态维护:消息被处理的状态是在Consumer端维护,而不是由
server端维护。当失败时能自动平衡。
3. 利用Linux的页缓存
2. 顺序读,顺序写
1. 零拷贝
3. 持久化数据存储:将消息持久化到磁盘。通过将数据持久化到硬盘以及
replication防止数据丢失。
5. 可靠性 - Kafka是分布式,分区,复制和容错的。
4. 分布式系统,易于向外扩展。所有的Producer、Broker和Consumer都会
有多个,均为分布式的。无需停机即可扩展机器。多个Producer、
Consumer可能是不同的应用。
优势
broker 和集群
消息和批次
生产者和消费者
模式
主题和分区
基本架构
流式处理:比如 Spark Streaming 和 Storm 。
日志收集:一个公司可以用Kafka可以收集各种服务的Log,通过Kafka以统
一接口服务的方式开放给各种Consumer;
运营指标:Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的
数据,生产各种操作的集中反馈,比如报警和报告;
消息系统:解耦生产者和消费者、缓存消息等;
用户活动跟踪:Kafka经常被用来记录Web用户或者App用户的各种活动,如
浏览网页、搜索、点击等活动,这些活动信息被各个服务器发布到Kafka的
Topic中,然后消费者通过订阅这些Topic来做实时的监控分析,亦可保存到
数据库;
应用场景
概念与基本架构
Kafka
陈后主
- 粉丝: 30
- 资源: 340
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0