没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
解释下 Kafka 中位移(offset)的作用
标准答案:在 Kafka 中,每个主题分区下的每条消息都被赋予了一个唯一的 ID 数值,用于标识它
在分区中的位置。这个 ID 数值,就被称为位移,或者叫偏移量。一旦消息被写入到分区日志,它
的位移值将不能被修改。
答完这些之后,你还可以把整个面试方向转移到你希望的地方:
1、如果你深谙 Broker 底层日志写入的逻辑,可以强调下消息在日志中的存放格式
2、如果你明白位移值一旦被确定不能修改,可以强调下“Log Cleaner 组件都不能影响位移值”这件
事情
3、如果你对消费者的概念还算熟悉,可以再详细说说位移值和消费者位移值之间的区别
阐述下 Kafka 中的领导者副本(Leader Replica)和追随者副本(Follower Replica)的区别
推荐的答案:Kafka 副本当前分为领导者副本和追随者副本。只有 Leader 副本才能对外提供读写服
务,响应 Clients 端的请求。Follower 副本只是采用拉(PULL)的方式,被动地同步 Leader 副本中的数
据,并且在 Leader 副本所在的 Broker 宕机后,随时准备应聘 Leader 副本。
加分点:
1、强调 Follower 副本也能对外提供读服务。自 Kafka 2.4 版本开始,社区通过引入新的 Broker 端参
数,允许 Follower 副本有限度地提供读服务。
2、强调 Leader 和 Follower 的消息序列在实际场景中不一致。通常情况下,很多因素可能造成
Leader 和 Follower 之间的不同步,比如程序问题,网络问题,broker 问题等,短暂的不同步我们可
以关注(秒级别),但长时间的不同步可能就需要深入排查了,因为一旦 Leader 所在节点异常,可能
直接影响可用性。
注意:之前确保一致性的主要手段是高水位机制(HW),但高水位值无法保证 Leader 连续变更场景
下的数据一致性,因此,社区引入了 Leader Epoch 机制,来修复高水位值的弊端。
如何设置 Kafka 能接收的最大消息的大小?
对于 SRE 来讲,该题简直是送分题啊,但是,最大消息的设置通常情况下有生产者端,消费者端
broker 端和 topic 级别的参数,我们需要正确设置,以保证可以正常的生产和消费。
Broker端参数:message. max. bytes,max. message. bytes(topic级别),replica. fetch. max. bytes(否则 follow
会同步失败)
Consumer 端参数:fetch. message. max. bytes
监控 Kafka 的框架都有哪些?
对于 SRE 来讲,依然是送分题。但基础的我们要知道,Kafka 本身是提供了 JMX (Java Management
Extensions)的,我们可以通过它来获取到 Kafka 内部的一些基本数据。
1、Kafka Manager:更多是 Kafka 的管理,对于 SRE 非常友好,也提供了简单的瞬时指标监控。
2、Kafka Monitor:LinkedIn 开源的免费框架,支持对集群进行系统测试,并实时监控测试结果。
3、CruiseControl:也是 Linkedln 公司开源的监控框架,用于实时监测资源使用率,以及提供常用运维
操作等。无 UI 界面,只提供 REST API,可以进行多集群管理。
4、JMX 监控:由于 Kafka 提供的监控指标都是基于 JMX 的,因此,市面上任何能够集成 JMX 的
框架都可以使用,比如 Zabbix 和 Prometheus。
5、已有大数据平台自己的监控体系:像 Cloudera 提供的 CDH 这类大数据平台,天然就提供 Kafka
监控方案。
6、JMXTool:社区提供的命令行工具,能够实时监控 JMX 指标。可以使用 Kafka-run-class. sh
Kafka. tools. JmxTool 来查看具体的用法。
Broker 的 Heap Size 如何设置?
1、其实对于 SRE 还是送分题,因为目前来讲大部分公司的业务系统都是使用 Java 开发,因此 SRE
对于基本的 JVM 相关的参数应该至少都是非常了解的,核心就在于 JVM 的配置以及 GC 相关的知
识。
2、标准答案:任何 Java 进程 JVM 堆大小的设置都需要仔细地进行考量和测试。一个常见的做法
是,以默认的初始 JVM 堆大小运行程序,当系统达到稳定状态后,手动触发一次 Full GC,然后通
过 JVM 工具查看 GC 后的存活对象大小。之后,将堆大小设置成存活对象总大小的 1.5~2 倍。对于
Kafka 而言,这个方法也是适
用的。不过,业界有个最佳实践,那就是将 Broker 的 Heap Size 固定为 6GB。经过很多公司的验证,
这个大小是足够且良好的。
如何估算 Kafka 集群的机器数量?
1、该题也算是 SRE 的送分题吧,对于 SRE 来讲,任何生产的系统第一步需要做的就是容量预估以
及集群的架构规划,实际上也就是机器数量和所用资源之间的关联关系,资源通常来讲就是 CPU,
内存,磁盘容量,带宽。但需要注意的是,Kafka 因为独有的设计,对于磁盘的要求并不是特别高,
普通机械硬盘足够,而通常的瓶颈会出现在带宽上。
2、在预估磁盘的占用时,你一定不要忘记计算副本同步的开销。如果一条消息占用 1KB 的磁盘空
间,那么,在有 3个副本的主题中,你就需要 3KB的总空间来保存这条消息。同时,需要考虑到整
个业务 Topic 数据保存的最大时间,以上几个因素,基本可以预估出来磁盘的容量需求。
3、需要注意的是:对于磁盘来讲,一定要提前和业务沟通好场景,而不是等待真正有磁盘容量瓶
颈了才去扩容磁盘或者找业务方沟通方案。
4、对于带宽来说,常见的带宽有 1Gbps 和 10Gbps,通常我们需要知道,当带宽占用接近总带宽的
90%时,丢包情形就会发生。
Leader 总是-1,怎么破?
1、对于有经验的 SRE 来讲,早期的 Kafka 版本应该多多少少都遇到过该种情况,通常情况下就是
Controller 不工作了,导致无法分配 leader,那既然知道问题后,解决方案也就很简单了。重启
Controller 节点上的 Kafka 进程,让其他节点重新注册 Controller 角色,但是如上面 ZooKeeper 的作用,
你要知道为什么 Controller 可以自动注册。
2、当然了,当你知道 controller 的注册机制后,你也可以说:删除 ZooKeeper 节点/controller,触发
Controller 重选举。Controller 重选举能够为所有主题分区重刷分区状态,可以有效解决因不一致导
致的 Leader 不可用问题。但是,需要注意的是,直接操作 ZooKeeper 是一件风险很大的操作,就好
比在 Linux 中执行了 rm-rf/xxx 一样,如果在/和 xxx 之间不小心多了几个空格,那“恭喜你”,今年白
干了。
LEO、LSO、AR、ISR、HW 都表示什么含义?
讲真,我不认为这是炫技的题目,特别是作为 SRE 来讲,对于一个开源软件的原理以及概念的理
解,是非常重要的。
1、LEO (Log End Offset):日志末端位移值或末端偏移量,表示日志下一条待插入消息的位移值。举
个例子,如果日志有 10 条消息,位移值从 0 开始,那么,第 10 条消息的位移值就是 9。此
时,LEO×10。
2、 LSO( Log Stable Offset):这是 Kafka 事务的概念。如果你没有使用到事务,那么这个值不存在
(其实也不是不存在,只是设置成一个无意义的值)。该值控制了事务型消费者能够看到的消息范围。
它经常与 Log Start Offset,即日志起始位移值相混淆,因为有些人将后者缩写成 LSO,这是不对
的。在 Kafka 中,LSO 就是指代 Log Stable Offset。
3、AR (Assigned Replicas):AR 是主题被创建后,分区创建时被分配的副本集合,副本个数由副本因
子决定。
4、ISR ( In- Sync Replicas): Kafka 中特别重要的概念,指代的是 AR 中那些与 Leader 保持同步的副
本集合。在 AR 中的副本可能不在 ISR 中,但 Leader 副本天然就包含在 ISR 中。
5、HW (High watermark):高水位值,这是控制消费者可读取消息范围的重要字段。一个普通消费者
只能“看到”Leader 副本上介于 Log Start Offset 和 HW(不含)之间的所有消息。水位以上的消息是对
消费者不可见的。
需要注意的是,通常在 ISR 中,可能会有人问到为什么有时候副本不在 ISR 中,这其实也就是上面
说的 Leader和 Follower不同步的情况,为什么我们前面说,短暂的不同步我们可以关注,但是长时
间的不同步,我们需要介入排查了,因为 ISR 里的副本后面都是通过 replica. lag. time. max. ms,即
Follower 副本的 LEO 落后 Leader LEO 的时间是否超过阈值来决定副本是否在 ISR 内部的。
Kafka 能手动删除消息吗?
1、Kafka 不需要用户手动删除消息。它本身提供了留存策略,能够自动删除过期消息。当然,它
是支持手动删除消息的。
2、对于设置了 Key 且参数 cleanup. policy=compact 的主题而言,我们可以构造一条的消息发送给
Broker,依靠 Log Cleaner 组件提供的功能删除掉该 Key 的消息。
剩余11页未读,继续阅读
资源评论
入伍击寇
- 粉丝: 129
- 资源: 4706
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功