|
|
51CTO旗下网站
|
|
移步端
创造专栏

Kafka 集群在马蜂窝大数量平台的僵化与使用扩展

Kafka 是那时热门的信息队列中间件,他可以临时地处理海量数据,具备高吞吐、低延时等特点及可靠的信息异步传递机制,可以很好地解决不同系统间数据的交流和传递问题。

笔者:马蜂窝技术| 2020-01-03 09:53

Kafka 是那时热门的信息队列中间件,他可以临时地处理海量数据,具备高吞吐、低延时等特点及可靠的信息异步传递机制,可以很好地解决不同系统间数据的交流和传递问题。

Kafka 在马蜂窝也有特别普遍的使用,为无数主导的工作提供支撑。本文将围绕 Kafka 在马蜂窝大数量平台的使用实践,介绍相关工作场景、在 Kafka 使用的不同阶段我们相遇了哪些问题以及如何解决、后还有哪些计划等。

Part.1.使用场景

副 Kafka 在大数量平台的使用场景来看,重点分为以下三类:

着重类是将 Kafka 表现必发娱乐登录,提供大数量平台对临时数据的存储服务。副来源和用途两个维度来说,可以将临时数据分为业务端 DB 数量、监督类型日志、基于埋点的客户端日志(H5、WEB、APP、小程序)和劳务端日志。

其次类是为数据分析提供数据源,各埋点日志会作为数据源,支持并对接公司离线数据、实时数据仓库及分析系统,包括多维查询、实时 Druid OLAP、日志明细等。

先后三类是为工作方提供多少订阅。除了在大数量平台内部的使用之外,咱们还采用 Kafka 为引进搜索、大交通、酒店、情节中心等主导业务提供多少订阅服务,如用户实时特征计算、他家实时画像训练及实时推荐、反作弊、工作监控报警等。

重点采用如下图所示:

Part.2.形成的路

四个级次

最初大数量平台之所以引入 Kafka 表现业务日志的采集处理系统,重点是考虑到它高吞吐低延迟、铺天盖地订阅、数量回溯等特征,可以更好地满足大数量场景的急需。但随着业务量的迅猛增多,以及在工作使用和系统维护中遇到的题材,例如注册机制、监督机制等的不健全,导致出现问题无法快速稳定,以及部分点上临时任务发生故障后没有快速恢复导致消息积压等, 使 Kafka 集群的祥和和可用性得受到挑战,经验了几次严重的故障。

消灭以上问题对我们来说迫切而艰难。针对大数量平台在采取 Kafka 上生活的组成部分痛点,咱们从集群使用到应用层扩展做了一连串的实行,完全来说包括四个级次:

着重阶段:版本升级。围绕平台数据生产和消费方面存在的组成部分瓶颈和题材,咱们针对目前的 Kafka 本子进行技术选型,末了确定使用 1.1.1 本子。

其次阶段:能源隔离。为了支持业务的高效发展,咱们完善了多集群建设以及集群内 Topic 间的风源隔离。

先后三阶段:权限控制和监理告警。

第一在安全地方,最初的 Kafka 集群处于裸跑状态。出于多产品线共用 Kafka,很容易由于误读其他工作的 Topic 导致数据安全问题。故此我们基于 SASL/ SCRAM + ACL 增长了鉴权的效应。

在监控告警方面,Kafka 脚下决定成为实时计算中步入数据源的外部配,这就是说其中 Lag 积压情况、吞吐情况就变成实时任务是否正常的要害指标。故此,大数量平台构建了联合的 Kafka 监督告警平台并命名「雷达」,多维度监控 Kafka 集群及利用方情况。

先后四阶段:使用扩展。最初 Kafka 在对商店各业务线开放的经过中,出于缺少统一的采取规范,导致了部分作业方的不科学运用。为解决该痛点,咱们构建了暂时订阅平台,穿过应用服务的样式赋能送工作方,贯彻数据生产和消费申请、平台的客户授权、采用方监控告警等很多环节流程化自动化,制造从需求方使用到资源全方位管控的总体闭环。

下围绕几个关键点为大家展开介绍。

基本实践

1. 版本升级

先前大数量平台一直采取的是 0.8.3 这一 Kafka 最初本版,而截止到目前,Kafka 法定最新的 Release 本子已经到了 2.3,于是乎长期采取 0.8 本子过程中渐渐遇到的许多瓶颈和题材,咱们是能够通过版本升级来解决之。

举例,以下是部分之前使用旧版时常见的题材:

  • 缺乏对 Security 的支持:生活数据安全性问题及无法通过认证授权对水源使用细粒度管理
  • broker under replicated:意识 broker 处于 under replicated 状态,但不确定问题的产生原因,困难以消灭。
  • 新的 feature 无法运用:如事务消息、幂等信息、信息时间戳、信息查询等。
  • 客户端的对 offset 的治本依赖 zookeeper, 对 zookeeper 的采取过重, 增长运维的复杂度
  • 监督指标不健全:如 topic、partition、broker 的多寡 size 指标, 同时 kafka manager 等监控工具对低版本 kafka 支持不好
  • 同时对部分目标版本的性状进行了选型调研,如:

  • 0.9 本子, 增长了配额和多样性, 其中安全认证和授权是咱们最关心的效应
  • 0.10 本子,更细粒度的年华戳. 可以基于偏移量进行快速的多寡查找,找到所要的年华戳。这在临时数据处理中基于 Kafka 数据源的多寡重播是极其重大的
  • 0.11 本子, 幂等性和 Transactions 的支持及副本数据丢失/数量不一致的消灭。
  • 幂等性意味着对于同一个 Partition,面对 Data 的多次发布,Kafka broker 头就足以完成自动去重;
  • 对 Transactions 的支持使一个事情下发布多枝消息到多个 Topic Partition 时,咱们可以行使他以原子性的措施被完成。在我们的上游消费者中,有的是都是用 Flink 做一些流处理的上班,故此在数据处理及故障恢复时仅一次语义则显得尤为关键。而 0.11 本子对于事务的支持则可以保证与 Kafka 交互的 Flink 使用实现端到头仅一次语义, 支持 EOS 可以对数据可靠性有绝对要求, 比如交易、风控等景象下的要害支持。
  • Leader Epoch:消灭了以前依赖水位表示副本进度可能造成的多寡丢失/数量不一致问题。
  • 1.1 本子,运维性的升级。比如当 Controller Shut Down,想要关闭一个 Broker 的时节,先前需要一个很长很复杂的经过在 1.0 本子得到很大的改良。
  • 末了摘取 1.1 本子, 则是因为出于 Camus 与 Kafka 本子的丰富性及 1.1 本子已经满足了动用场景中任重而道远新特点的支持的归纳考量。此地再简单说一下 Camus 组件,同样是由 Linkedin 开源,在我们的大数量平台中举足轻重表现 Kafka 数量 Dump 到 HDFS 的要害措施。

    2. 能源隔离

    先前由于工作的纷繁和范围不大,大数量平台对于 Kafka 集群的分割比较简便。于是乎,一段日子后导致企业工作数据混杂在总共,某一个作业主题存在的无理使用都有可能导致某些 Broker 负载过重,影响到其它正常的工作,甚至一些 Broker 的故障会出现影响整个集群,导致全公司工作不可用之风险。

    针对以上的题材,在集群改造上做了两地方履行

    按功能属性拆分独立的集群

    集群内部 Topic 零度的风源隔离

    (1)集群拆分

    按照效益维度拆分多个 Kafka 物理集群,拓展工作隔离,降低运维复杂度。

    以目前最重要的埋点数据使用来说, 脚下拆分为三类集群,各项集群的效应定义如下:

  • Log 集群:各端的埋点数据采集后会优先落地到该集群, 故此这个过程不能出现由于 Kafka 题材导致采集中断,这对 Kafka 可用性要求很高。故此该集群不会对外提供订阅,合同消费方可控;同时该集群业务也表现离线采集的源头,数量会通过 Camus 组件按小时时间粒度 dump 到 HDFS 官方,这部分数据参与后续的离线计算。
  • 全量订阅集群:该集群 Topic 中的绝大部分数目是副 Log 集群实时同步过来的。地方我们提出了 Log 集群的多寡是不对外的,因此全量集群就承担了消费订阅的天职。脚下第一是用于平台内部的暂时任务中,来对多个工作线的数据分析并提供分析服务。
  • 生性定制集群:先前提到过,咱们可以根据工作方需求来拆分、统一数据日志源,同时我们还支持定制化 Topic,该集群只要求提供分流后 Topic 的出生存储。
  • 集群整体架构划分如下图:

    (2)能源隔离

    Topic 的话务量大小是集群内部进行资源隔离的要害依据。例如,咱们在工作中埋点日志量较大的两个数据源分别是今后端埋点数据源 server-event 和嘴上的埋点 mobile-event 数据源,咱们要避免存储两个数据的主题分区分配到集群中同一个 Broker 上的兴奋点。穿过在不同 Topic 拓展物理隔离,就足以避免 Broker 上的话务量发生倾斜。

    3. 权限控制和监理告警

    (1)权限控制

    起来介绍时我们说过,最初 Kafka 集群没有安装安全检查处于裸跑状态,故此只要知道 Broker 的过渡地址即可生产消费,生活严重的多寡安全性问题。

    一般来说, 采用 SASL 的客户多会选择 Kerberos,但就平台 Kafka 集群的采取场景来说,他家系统并不复杂,采用 Kerberos 就有些大材小用, 同时 Kerberos 相对复杂,生活引发任何题材的风险。此外,在 Encryption 地方, 由于都是运行在内网环境,故此并没有使用 SSL 加密。

    末了平台 Kafka 集群使用 SASL 表现鉴权方式, 基于 SASL/ SCRAM + ACL 的轻量级组合方式,贯彻动态创建用户,保护数据安全。

    (2)监督告警

    先前在集群的采取中我们经常发现,消费应用的性质无缘无故变差了。剖析问题的由来, 普通是后退 Consumer 读取的多寡大概率没有打中 Page- cache,导致 Broker 头机器的本要首先从光盘读取数据加载到 Page- cache 官方后,才能将军结果返还给 Consumer,相当于本来可以服务于写操作的录像带现在要读取数据了, 影响了动用方读写同时降低的集群的性质。

    这会儿就要求找出滞后 Consumer 的使用进行事前的干涉从而减少问题发生,故此监控告警无论对平台还是用户都有着重要的含义。下介绍一下我们的实行思路。

    完全方案:

    完全方案主要是基于开源组件 Kafka JMX Metrics+OpenFalcon+Grafana:

  • Kafka JMX Metrics:Kafka broker 的里间指标都以 JMX Metrics 的样式暴露给外部。1.1.1 本子 提供了丰富的监察指标,满足监控需要
  • OpenFalcon:小米开源的一款企业级、高可用、可扩展的正本求源监控体系
  • Grafana:Metrics 可视化系统,大家比较熟悉,可对接多种 Metrics 数据源。
  • 关于监控:

  • Falcon-agent:布局到每台 Broker 上, 剖析 Kafka JMX 指标上报数据
  • Grafana:用于可视化 Falcon Kafka Metrics 数量,对 Cluster、Broker、Topic、Consumer 4 个角色制作监控大盘。
  • Eagle:获取消费组 Active 状态、消费组 Lag 积压情况,同时提供 API,为监控告警系统「雷达」提供监督数据。
  • 关于告警:

    雷达系统: 自研监控体系,穿过 Falcon 及 Eagle 获取 Kafka 指标,重组设定阈值进行告警。以消费方式举例,Lag 是衡量消费情况是否健康的一个重要指标,如果 Lag 一直增加,必须要对他进行拍卖。

    发生问题的时节,不仅 Consumer 组织者要掌握,他的客户也要掌握,故此报警系统也要求通知到他家。现实措施是通过企业微信告警机器人自动提醒对应消费组的主管或使用者及 Kafka 集群的官员。

    监督示例:

    4. 使用扩展

    (1)实时数据订阅平台

    实时数据订阅平台是一番提供 Kafka 采用全流程管理的体系利用,以工单审批的措施将数据生产和消费申请、平台用户授权、采用方监控告警等很多环节流程化自动化, 并提供统一管控。

    基本思想是基于 Kafka 数据源的位置认证和权力控制,增长多少安全性的同时对 Kafka 上游应用进行管理。

    (2)谱的申办流程

    不论是生产者还是顾客之急需,采用方首先会以工单的措施提出订阅申请。报名信息包括业务线、Topic、订阅方式等信息;工单最终会流转到平台等待审批;如果审批通过,采用方会分配到授权账号及 Broker 地点。迄今,采用方就足以拓展例行的生产消费了。

    (3)监督告警

    对于平台来说,权限与资源是绑定的,能源得以是用于生产的 Topic 或消费使用的 GroupTopic。一旦权限分配后,对于该部分资源之采取就会自动在我们的雷达监控体系开展登记,用于资源整个生命之潜伏期的监察。

    (4)数量重播

    由于对数据完整性和准确性的勘查,脚下 Lamda 架构已经是大数量的一种备用架构方式。但从另一方面来说, Lamda 架构也存在资源之无数使用和付出力度高等问题。

    实时订阅平台可以为消费组提供任意位点的份额置,支持对临时数据按时间、位点等多种艺术的多寡重播, 并提供对 Kappa 架构场景的支持,来解决以上痛点。

    (5)主题管理

    为什么提供主题管理?举一些很简单的例证,比如当我们想让一个用户在集群上创办他自己之 Kafka Topic,这会儿显然是不指望让它直接到一个节点上操作的。因此刚才所讲的劳务,甭管是对客户来讲,还是管理员来讲,咱们都要求有一度界面操作它,因为不可能所有人都通过 SSH 扮演连服务器。

    故此需要一个提供管理力量的劳务,创造统一的进口并引入主题管理的劳务,包括主题的创造、能源隔离指定、主题元数据管理等。


    (6)数量分流

    在头里的架构中, 采用方消费 Kafka 数量的舒适度都是每个 Kafka Topic 保留 LogSource 的全量数据,但在采取中许多消费方只要求花费各 LogSource 的一部分数据,可能也就是某一个用到下几个埋点事件的多寡。如果需要下游应用自己写过滤规则,确认存在资源之浪费及利用方便性的题材;此外还有一些场景是要求多个数据源 Merge 在一起来使用的。

    基于上面的两种情景, 我人实现了按业务方需求拆分、统一并录制化 Topic 支持跨数据源的多寡合并及 appcode 和 event code 的任意组个条件的筛选规则。

    Part.3.持续计划

    消灭数据重复问题。为了消灭当前平台实时流处理中因故障恢复等因素导致数据重复的题材,咱们正在尝试用 Kafka 的工作机制结合 Flink 的两段提交协议实现端到头的仅一次语义。脚下已经在平台上小规模试用, 如果通过测试,名将会在生养条件下推广。

    Consumer 限流。在一写多读场景中, 如果某一个 Consumer 借鉴大量读光碟, 会影响 Produce 除其他消费者操作的延期。l故此,穿过 Kafka Quota 公有制对 Consume 限流及支持动态调整阈值也是咱们继续的主旋律

    气象扩展。基于 Kafka 推而广之 SDK、HTTP 等多种消息订阅及生产方式,满足不同语言环境及场景的采取需求。

    【本文是51CTO专栏作者马蜂窝技术之原创文章,笔者微信公众号马蜂窝技术(ID:mfwtech)】

    戳这里,瞧该作者更多好文

    【编纂推荐】

    1. 高考问Kafka,这一篇全搞定
    2. 如何应对性能优化的题材,才能打动阿里面试官?
    3. Java中的JVM字符串性能优化
    4. 那天处理千亿级日志量,Kafka是如何形成的?
    5. Java多点程优化都不会,怎么拿Offer?
    【义务编辑: 武晓燕 TEL:(010)68476606】

    点赞 0
  • Kafka  集群  多极化
  • 分享:
    大家都在看
    猜你喜欢
  • 马蜂窝技术

    马蜂窝技术