京东实时消息队列JDQ技术实践与探索
•
2 gefällt mir•316 views
胡晓花, 京东 京东实时消息队列JDQ是基于Kafka打造的广泛服务于京东各个业务的实时消息平台。本次分享主要介绍一下实时消息队列JDQ的平台建设与技术实践之路，并浅谈Kafka与Pulsar的应用实践区别。 https://www.meetup.com/Beijing-Kafka-Meetup/events/281812695/
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 京东实时消息队列JDQ技术实践与探索
Ähnlich wie 京东实时消息队列JDQ技术实践与探索 (20)
Mehr von confluent
Mehr von confluent (20)
京东实时消息队列JDQ技术实践与探索
- 1. 京东实时消息队列JDQ技术实践与探索 • 胡晓花 • 技术与数据中心-数据与智能部 • 2021年11月20号
- 3. Ø 实时计算平台消息队列JDQ平台基础介绍 • 基于开源社区Kafka框架以发布订阅模式为下游提供服 务打造的消息队列平台。目前是升级到了Kafka2.5.0 版本。 • 提供实时数据存储服务( 数据库日志 , 流量数据等 ),并 在大数据量系统承担着流量削峰、异步缓冲、系统解 耦以及作为实时数据分析数据源等重要作用。 • 赋能公司内部京东物流、京东健康、京东科技、京东 云等40+一级部门，以及搜推、黄金眼、商智、实时 大屏、UMP、MDC监控等1300+的业务线。 • 实时数据管道JDQ平台与实时数据采集平台DTS平台以 及实时计算JRC（基于Flink）平台相辅相成，同共同 致力于打造大数据生态系统。 一、JDQ平台基础介绍-平台架构
- 4. 一、JDQ平台基础介绍-业务规模 Ø JDQ业务增长情况 • 以历年大促峰值流出量为例，历年大促业务增 长情况如下图。 • 集群日生产行数7万亿+（看右图），日吞吐 量16PB+。 • 下图是逐年大促增长情况。 21.4 0 5 10 15 20 25 2017年618 2017年双11 2018年618 2018年双11 2019年618 2019年双11 2020年双618 2020年双11 2021年618 2021年开门红 2021年双11 JDQ2017年～2021年大促峰值流出量增长情况（TB/min）
- 5. 一、JDQ平台基础介绍-客户端监控 Ø JDQ生产者客户端监控 • Topic粒度生产行数监控如右图上图，注意关注 生产增长趋势同环比监控、零值报警监控信息； • Topic分区粒度生产行数监控如右图下图，主要 关注每个分区数据生产量是否均匀，是否存在热 点分区； • 生产鉴权（user/client.id）的速度监控如左下图， 如果出现大于零的情况，则表示消费阻塞，被限 速。
- 6. 一、JDQ平台基础介绍-客户端监控 Ø JDQ消费者客户端监控 • 消费积压如右图上图； • 分区消费积压如右下图； • 消费鉴权（user/client.id）的速度监控如 左下图，如果出现大于零的情况，则表示 消费阻塞，被限速。
- 7. Ø JDQ集群服务端监控 • 集群稳定性指标监控 ü 机器连通性异常、节点活跃、UnderReplicatedPartitions数量、 IsrExpandsPerSec、IsrShrinksPerSec、ActiveControllerCount等指标。 • 集群压力指标监控 ü 带宽情况、磁盘使用率、broker的TCP连接数、RequestQueueSize、 ResponseQueueSize、 TotalProduceRequestsPerSec等指标。 一、JDQ平台基础介绍-服务端监控
- 8. Ø JDQ高可用架构方案 ü 根据业务重要性、业务数据量以及业务特征类型，JDQ平台提供了多样性高可用架构。 二、JDQ高可用架构 跨机房主备全链路双活方案 ü 从数据接入、实时数据存储、实时计算，到数据应用层进行全链 路垮机房双活部署，若发生故障，无需切换；如黄金眼业务。 读写分离方案 跨机房高可用集群部署 一键切换服务进行跨机房主/备集群切换 ü 写集群跨机房分流、读集群跨机房双活；如京东APP流量业务。 ü 严格保障每个topic分区的副本跨机房跨机架（POD）部署；如 UMP、MDC、京东科技监控系统业务。 ü 依次按照等级（L0～L3）和优先恢复L0/L1核心业务的原则，通过 一键切换服务实现跨机房主/备集群切换。 可接受分钟级切换延迟非零级业务系统， 生产/消费上下游多为同一业务方 实效性要求高，大促期间数据量增 长可控的监控数据 高吞吐量、高峰值 业务、消费下游多 零级核心业务 JDQ高可用架构方案
- 9. 二、JDQ高可用架构 Ø JDQ高可用架构-跨机房主备全链路双活 ü 针对零级核心业务不允许丢数与延迟的要求，进行全链路跨机房异地双活方案部署。跨机房主备全链路双活方案如下图。 JDQ主流集群 JDQ备流集群 数据采集 自助上报 数据采集 自助上报 JRC/JDQ客户端 JRC/JDQ客户端 机房A数据流主流 数据应用层进行数据结果切换或展示 机房B数据流备流
- 11. 二、JDQ高可用架构 Ø JDQ高可用架构-跨机房多副本分布 ü 针对实效性要求高、数据量较平稳以及数据保留时间在小时级别的企业监控数据，提供跨机房多副本分布集群部署如下图。可实 现秒级恢复，并且可容忍集群50%机器故障达到跨机房、跨机架容灾。 Leader Follower Follower Follower Leader Follower Follower Follower Topic-分区0 Topic-分区1 RackA-0 RackA-1 RackB-0 RackB-1 机房A 机房B Leader Follower Follower Follower Topic-分区2 Leader Follower Follower Follower Topic-分区3 JDQ
- 12. 二、JDQ高可用架构 Ø JDQ高可用架构-一键切换服务 ü 按照等级（L0～L3）依次恢复和按照优先恢复L0/L1等级业务的原则进行JDQ一键切换服务进行跨机房主/备集群切换。 机房A-JDQ集群 机房B-JDQ集群 生产 生产 消费 消费 JDQ一键切换功能 JDQ一键切换功能
- 13. Ø JDQ技术优化实践-MM优化 ü JDQ集群间数据同步服务MirrorMaker4.0服务优化，随着业务的数据量增长，MM性能达到瓶颈，性能受压缩方式影响大。优化：去 中间数据解压缩、压缩环节，去掉对压缩方式的依赖。 读写分离与跨机房部署 • 读写分离：分担生产（写集群）、消费（读集群）压力，生产、消费解耦。 • 双读热备：跨机房数据镜像。 • 跨机房读集群部署既减轻单个机房压力，又可实现跨机房物理隔离与容灾。 JDQ-MM数据镜像服务架构与优化研发设计 三、JDQ技术优化实践 机房A 机房B Producer Producer Producer Producer Producer Producer Consumer Consumer Consumer Consumer Consumer Consumer push push pull pull MM MM MM MM JDQ写集群 JDQ写集群 JDQ读集群 JDQ读集群 跨机房 互备 跨机房 互备 JDQ读写分离高可用架构图 JDQ-MirrorMaker JDQ-A Cluster JDQ-B Cluster Buffer MM-Consumer MM-Producer Deserializer Decompress Consumer Record Producer Record Serializer Compress Record Batch Record Batch x x x x x x x x JDQ-MM优化数据同步流程图 消耗CPU
- 14. 三、JDQ技术优化实践 Ø JDQ技术优化实践-MM优化 ü 下面是经过我们特殊优化之后MM的性能压测结果（注：相同条件下，使用线上流量数据进行压测）。 ü 相比与优化之前MM任务，CPU的使用率从90%左右下降到20%， 降低4倍以上（左上图）。 ü 相比与MM3.0，MM4.0每分钟单Pod单分区同步数据量从500w增 加到800w，速度提升60%，同时GC次数减小（左下图）。 ü 同时，我们按照我们的业务场景进行了相应的功能研发： • 支持指定数据字段过滤； • 支持单任务同步多topic并切自动识别同步topic列表信息变更。 • 支持多种数据同步策略： a) Follow模式：源/目标集群严格进行数据； b) 针对存在消息key热点数据采取粘性分区策略进行目标 集群数据的二次均衡（主要是为了消除源集群按照消息 key存在热点分区问题，从而保障目标集群的消费下游 均衡消费）。 c) 按照消息key做hash同步数据（为了解决源集群与目标 集群分区不一致，目标集群可按需扩分区）。
- 15. 三、JDQ技术优化实践 Ø JDQ技术优化实践-跨机架topic分区均衡策略 ü 默认的一般创建Topic分区的方法，Topic/分区分布策略是尽可能的保证跨机架分散分布 。在集群新创建开始或者非扩容阶段，基本上 磁盘使用率，带宽等资源以及处理请求量的压力是均匀的。 Topic分区创建默认策略（指定rack）： • 尽可能地让每个分区的副本都分配到不同的rack上； • 循环选择每个rack的broker进行分配分区的第一个副本，其 余分区副本优先选择没有副本的机器，直至所有机器都有副 本，接下就是round-robin进行分配。 • 若发现集群不均问题使用kafka-reassign-partitions.sh进行 均衡。 但是随着topic数量的增减、某些topic数据量的增减或者经过扩缩容之后的集群存在资源不均衡、压力不均衡的现象。所以就需要考虑 集群节点资源、压力均衡的方法！ BrokerID Rack 0 rack1 1 rack3 2 rack3 3 rack2 4 rack2 5 rack1 PartitionID Rack 0 0,3,1 1 3,1,5 2 1,5,4 3 5,4,2 4 4,2,0 5 2,0,3 6 0,4,2 按照Rack排序BrokerID列表：0, 3, 1, 5, 4, 2 假设创建的topic，partition:7,replicas=3
- 16. 三、JDQ技术优化实践 Ø JDQ技术优化实践-跨机架topic分区均衡策略 ü 在保障高可用前提下，随着topic的增加或者经过扩容之后的集群，需要均衡集群内节点压力，解决集群的资源压力（磁盘、带宽、请 求量）热点问题。 ü 目标：能够根据不同节点在带宽、磁盘等资源使用率以及请求压力上的差异，使得每台机器上资源使用情况与压力情况逐渐趋向收敛 阈值，从而达到资源最大均衡分配的目的。 需要考虑的影响因素： • 磁盘使用率 • 流入/流出带宽 • 请求量压力 • TCP 连接数 收敛阈值（平均值）：47%； 收敛差值：当前使用率-收敛域值； 收敛范围：42~52%（收敛差值：-5～5%）的属于标准收敛 范围，此范围内的数据不做迁移； 收敛迁移策略：1->7，3->8，0->5,6 BrokerID Rack 磁盘使用率（%） 收敛差值% 0 rack1 73 28 1 rack3 64 17 2 rack3 50 3 3 rack2 68 21 4 rack2 52 5 5 rack1 39 -8 6 rack1 29 -18 7 rack3 27 -20 8 rack2 21 -26 以磁盘作为因素举例
- 17. 三、JDQ技术优化实践 Ø JDQ技术优化实践-跨机架topic分区均衡策略 ü 需要考虑机器上的哪些topic分区进行迁移呢？本次以迁移 b1àb7举例简化流程进行示例。 ü 均衡要求： • 每一个分区副本必须跨机架分布，比如每个分区的副 本数等于机架数（rack是逻辑概念）； • 各个rack的分区/副本分布均匀（与第一点相关）； • 同一个topic的分区尽可能分散分布在所有节点，不会 造成过于集中分布； • 数据移动最少，但各节点尽量均衡。 ü 进一步： • 对于磁盘来讲，多磁盘多目录？磁盘大小不一？ • 在迁移磁盘的时候不仅仅要考虑磁盘打散，也需要考 虑是否会造成带宽热点？请求量热点？ 对b1的topic-partition按照存储进行top排序， 并获取所有所有topic信息； 输出b1~b7均衡计划 记录迁移操作到均衡计划； 更新b1与b7磁盘使用率； Y N Y Y Y top0～topm； 预迁移之后b7是否满足收敛要求？并 且不会造成topic分区过于集中分布？ b1和b7是否达到收敛要求？ Y N 预计算最小分区是否令b7满足收敛标 准？ Y N b1-b7均衡计划为空的处 理策略 N JDQ跨机架topic分区均衡策略简化流程图
- 18. 四、JDQ云原生实践 Ø JDQ云原生实践-JDQ容器化技术方案 ü Statefulset：JDQ 容器化集群的核心控制器，管 理与控制整个 JDQ 容器化集群的生命周期。 ü JDQ Pod：封装 JDQ Broker的资源单位。 ü PVC：JDQ 数据存储卷的声明。 ü PV：给 JDQ PVC 提供实际数据存储卷的资源单 位。 ü Local PV：以本地磁盘作为存储的一种 PV。 ü ChubaoFS：京东内部云自研的原生的分布式存 储文件系统。 ü Service：JDQ 对外提供容器化服务的声明。 ü NodePort：通过将端口映射到物理机对外提供访 问的服务。 ü LoadBalance：通过负载均衡对外提供访问的服 务。 ü Helm：k8s部署的包管理工具。
- 19. 四、JDQ云原生实践 Ø JDQ技术优化实践-JDQ容器化Broker状态 保持与数据持久化存储 ü 每一个 Broker Pod 分配一个唯一的持久化的 Broker ID，BrokerID的规则： Min_Broker_ID + Pod_ID，其中 Min_Broker_ID 为用户设置值， 默认为 0；Pod_ID 为 Statefulset为每个 Pod 生 成的状态标识 ID。这个 Broker ID 元数据在 Pod 重启后也会被再次分配给这个 Pod。 ü 支持CFS、LocalPV两种存储模式；主要介绍持 久化远程存储CFS。 ü 每一个 Broker Pod 产生的 Topic 数据在 ChubaoFS 进行持久化，这些 Topic 数据在 Pod 重启后也会和这个 Pod 进行再次的关联绑定。 ü CFS Client实现Pod与存储路径的映射，CFS路径 生成规则： $PodName=$ChartName+$StorageType+kaf ka+$BrokerID 四、JDQ云原生实践 Ø JDQ技术优化实践-JDQ容器化Broker状态 保持与数据持久化存储 ü 每一个 Broker Pod 分配一个唯一的持久化的 Broker ID，BrokerID的规则： Min_Broker_ID + Pod_ID，其中 Min_Broker_ID 为用户设置值， 默认为 0；Pod_ID 为 Statefulset为每个 Pod 生 成的状态标识 ID。这个 Broker ID 元数据在 Pod 重启后也会被再次分配给这个 Pod。 ü 支持CFS、LocalPV两种存储模式；主要介绍持 久化远程存储CFS。 ü 每一个 Broker Pod 产生的 Topic 数据在 ChubaoFS 进行持久化，这些 Topic 数据在 Pod 重启后也会和这个 Pod 进行再次的关联绑定。 ü CFS Client实现Pod与存储路径的映射，CFS路径 生成规则： $PodName=$ChartName+$StorageType+kaf ka+$BrokerID
- 20. 四、JDQ云原生实践 Ø JDQ技术优化实践-亲和性打标 ##节点独占 podAntiAffinity requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app.kubernetes.io/name operator: In values: - jdq topologyKey: kubernetes.io/hostname ##机型选择/业务类型打标 nodeAffinity requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - lf-jrdw-rt-*-*-*-*.?.?.?
- 21. 感谢您的时间 THANKS