没有合适的资源?快使用搜索试试~ 我知道了~
Kafka 负载均衡在 vivo 的落地实践.doc
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 88 浏览量
2022-07-08
23:02:50
上传
评论
收藏 2.92MB DOC 举报
温馨提示
试读
16页
Kafka 负载均衡在 vivo 的落地实践.doc
资源推荐
资源详情
资源评论
Kafka 负载均衡在 vivo 的落地实践
副本迁移是 Kafka 最高频的操作,对于一个拥有几十万个副本的集群,通过人工
去完成副本迁移是一件很困难的事情。Cruise Control 作为 Kafka 的运维工具,它包含了
Kafka 服务上下线、集群内负载均衡、副本扩缩容、副本缺失修复以及节点降级等功能。
vivo 互联网服务器团队-You Shuo
副本迁移是 Kafka 最高频的操作,对于一个拥有几十万个副本的集群,通过人工去完成副
本迁移是一件很困难的事情。Cruise Control 作为 Kafka 的运维工具,它包含了 Kafka 服务
上下线、集群内负载均衡、副本扩缩容、副本缺失修复以及节点降级等功能。显然,Cruise
Control 的出现,使得我们能够更容易的运维大规模 Kafka 集群。
备注:本文基于 Kafka 2.1.1 开展。
一、 Kafka 负载均衡
1.1 生产者负载均衡
Kafka 客户端可以使用分区器依据消息的 key 计算分区,如果在发送消息时未指定 key,
则默认分区器会基于 round robin 算法为每条消息分配分区;
否则会基于 murmur2 哈希算法计算 key 的哈希值,并与分区数取模的到最后的分区编号。
很显然,这并不是我们要讨论的 Kafka 负载均衡,因为生产者负载均衡看起来并不是那么
的复杂。
1.2 消费者负载均衡
考虑到消费者上下线、topic 分区数变更等情况,KafkaConsumer 还需要负责与服务端交
互执行分区再分配操作,以保证消费者能够更加均衡的消费 topic 分区,从而提升消费的性
能;
Kafka 目 前 主 流 的 分 区 分 配 策 略 有 2 种 ( 默 认 是 range , 可 以 通 过
partition.assignment.strategy 参数指定):
range: 在保证均衡的前提下,将连续的分区分配给消费者,对应的实现是 RangeAssignor;
round-robin:在保证均衡的前提下,轮询分配,对应的实现是 RoundRobinAssignor;
0.11.0.0 版本引入了一种新的分区分配策略 StickyAssignor,其优势在于能够保证分区均衡
的前提下尽量保持原有的分区分配结果,从而避免许多冗余的分区分配操作,减少分区再分
配的执行时间。
无论是生产者还是消费者,Kafka 客户端内部已经帮我们做了负载均衡了,那我们还有讨
论负载均衡的必要吗?答案是肯定的,因为 Kafka 负载不均的主要问题存在于服务端而不是
客户端。
二、 Kafka 服务端为什么要做负载均衡
我们先来看一下 Kafka 集群的流量分布(图 1)以及新上线机器后集群的流量分布(图
2):
从图 1 可以看出资源组内各 broker 的流量分布并不是很均衡,而且由于部分 topic 分区集
中分布在某几个 broker 上,当 topic 流量突增的时候,会出现只有部分 broker 流量突增。
这种情况下,我们就需要扩容 topic 分区或手动执行迁移动操作。
图 2 是我们 Kafka 集群的一个资源组扩容后的流量分布情况,流量无法自动的分摊到新扩
容的节点上。此时,就需要我们手动的触发数据迁移,从而才能把流量引到新扩容的节点上。
2.1 Kafka 存储结构
为什么会出现上述的问题呢?这个就需要从 Kafka 的存储机制说起。
下图是 Kafka topic 的存储结构,其具体层级结构描述如下:
每个 broker 节点可以通过 logDirs 配置项指定多个 log 目录,我们线上机器共有 12 块盘,
每块盘都对应一个 log 目录。
每个 log 目录下会有若干个[topic]-[x]字样的目录,该目录用于存储指定 topic 指定分区的
数据,对应的如果该 topic 是 3 副本,那在集群的其他 broker 节点上会有两个和该目录同名
的目录。
客户端写入 kafka 的数据最终会按照时间顺序成对的生成.index、.timeindex、.snapshot 以
及.log 文件,这些文件保存在对应的 topic 分区目录下。
为了实现高可用目的,我们线上的 topic 一般都是 2 副本/3 副本,topic 分区的每个副本都
分布在不同的 broker 节点上,有时为了降低机架故障带来的风险,topic 分区的不同副本也
会被要求分配在不同机架的 broker 节点上。
了解完 Kafka 存储机制之后,我们可以清晰的了解到,客户端写入 Kafka 的数据会按照
topic 分区被路由到 broker 的不同 log 目录下,只要我们不人工干预,那每次路由的结果都
不会改变。因为每次路由结果都不会改变,那么问题来了:
随着 topic 数量不断增多,每个 topic 的分区数量又不一致,最终就会出现 topic 分区在
Kafka 集群内分配不均的情况。
比如:topic1 是 10 个分区、topic2 是 15 个分区、topic3 是 3 个分区,我们集群有 6 台机
器。那 6 台 broker 上总会有 4 台 broker 有两个 topic1 的分区,有 3 台 broke 上有 3 个 topic3
分区等等。
这样的问题就会导致分区多的 broker 上的出入流量可能要比其他 broker 上要高,如果要
考虑同一 topic 不同分区流量不一致、不同 topic 流量又不一致,再加上我们线上有 7000 个
topic、13 万个分区、27 万个副本等等这些。
这么复杂的情况下,集群内总会有 broker 负载特别高,有的 broker 负载特别低,当 broker
负载高到一定的时候,此时就需要我们的运维同学介入进来了,我们需要帮这些 broker 减
减压,从而间接的提升集群总体的负载能力。
当集群整体负载都很高,业务流量会持续增长的时候,我们会往集群内扩机器。有些同学
想扩机器是好事呀,这会有什么问题呢?问题和上面是一样的,因为发往 topic 分区的数据,
其路由结果不会改变,如果没有人工干预的话,那新扩进来机器的流量就始终是 0,集群内
原来的 broker 负载依然得不到减轻。
三、如何对 Kafka 做负载均衡
3.1 人工生成迁移计划和迁移
如下图所示,我们模拟一个简单的场景,其中的 T0-P0-R0 表示 topic-分区-副本,假设 topic
各分区流量相同,假设每个分区 R0 副本是 leader。
我们可以看到,有两个 topic T0 和 T1,T0 是 5 分区 2 副本(出入流量为 10 和 5),T1 是
3 分区 2 副本(出入流量为 5 和 1),如果严格考虑机架的话,那 topic 副本的分布可能如下:
假设我们现在新扩入一台 broker3(Rack2),如下图所示:由于之前考虑了 topic 在机架上
的分布,所以从整体上看,broker2 的负载要高一些。
剩余15页未读,继续阅读
资源评论
书博教育
- 粉丝: 1
- 资源: 2837
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功