适用场景全新升级!扩展 Dragonfly2 作为分布式缓存系统架构 | 龙蜥技术

简介: 对于不存在的一个远端源地址,Dragonfly无法分发数据应该怎么办?

640.png

文/龙蜥社区开发者

Dragonfly2 简介

Dragonfly 作为龙蜥社区的镜像加速标准解决方案,是一款基于 P2P 的智能镜像和文件分发工具。它旨在提高大规模文件传输的效率和速率,最大限度地利用网络带宽。在应用分发、缓存分发、日志分发和镜像分发等领域被大规模使用。


现阶段 Dragonfly 基于 Dragonfly1.x 演进而来,在保持 Dragonfly1.x 原有核心能力的基础上,Dragonfly 在系统架构设计、产品能力、使用场景等几大方向上进行了全面升级。


Dragonfly 架构主要分为三部分 Manager、Scheduler、Seed Peer 以及 Peer 各司其职组成 P2P 下载网络,Dfdaemon 可以作为 Seed Peer 和 Peer。详细内容可以参考架构文档(链接见文末),下面是各模块功能:

  • Manager:维护各 P2P 集群的关联关系、动态配置管理、用户态以及权限管理等功能。也包含了前端控制台,方便用户进行可视化操作集群。
  • Scheduler:为下载节点选择最优下载父节点。异常情况控制 Dfdaemon 回源。
  • Seed Peer:Dfdaemon 开启 Seed Peer 模式可以作为 P2P 集群中回源下载节点, 也就是整个集群中下载的根节点。
  • Peer:通过 Dfdaemon 部署,基于 C/S 架构提供 dfget 命令行下载工具,以及 dfget daemon 运行守护进程,提供任务下载能力。

 

640 (49).png

更多详细信息可以参考 Dragonfly 官网(链接见文末)

问题背景

虽然 Dragonfly 的定位是一个基于 P2P 的文件分发系统,但是分发的文件必须是能够从网络上下载的文件,无论是 rpm 包还是容器镜像内容,最终都是有一个地址源的,用户可以通过 dfget 命令向 dfdaemon 发起下载请求,然后 Dragonfly P2P 系统负责下载,如果数据不在其他 Peer 上,那么 Peer 或者 SeedPeer 自己会回源,直接从源下载数据,然后返回给用户。


但是有些场景我们需要分发的数据是某个节点上生成的,不存在一个远端的源地址,这个时候 Dragonfly 就无法分发这种数据了。所以我们希望 Dragonfly 能够增加对这种场景的支持,其实相当于把 Dragonfly 当作了一个分布式的基于 P2P 的缓存和任意数据分发系统。

扩展 Dragonfly2

所以我们设想中的 Dragonfly 缓存系统架构是这样的:

640 (50).png

  • 每个计算节点上(比如神龙)部署一个 dfdaemon,作为一个 peer 加入 P2P 网络。
  • 接受来自本节点的请求
  • 为其他 peer 提供上传服务
  • 每个 peer 只负责管理自己本地的 cache 数据,不负责回源,回源由业务进程负责
  • 每个集群可以部署一个到多个基于 ECS 的 scheduler 节点。
  • 记录文件 P2P 网络的文件信息
  • 下载调度
  • 多 scheduler 节点解决单点故障问题
  • 每个 cache 系统中的文件都会通过 ringhash 映射到某个 scheduler 上
  • 一个或者多个 Manager 作为集群管理者。
  • 负责向 scheduler 和 peer 节点发送动态配置
  • 收集 metrics 等信息


接口设计

dfdaemon 接口

原来的 daemon 接口:

pkg/rpc/dfdaemon/dfdaemon.proto
// Daemon Client RPC Service
service Daemon{
  // Trigger client to download file
  rpc Download(DownRequest) returns(stream DownResult);
  // Get piece tasks from other peers
  rpc GetPieceTasks(base.PieceTaskRequest)returns(base.PiecePacket);
  // Check daemon health
  rpc CheckHealth(google.protobuf.Empty)returns(google.protobuf.Empty);
}

新增  4 个接口:

service Daemon { 
// Check if given task exists in P2P cache system
rpc StatTask(StatTaskRequest) returns(google.protobuf.Empty);
// Import the given file into P2P cache system
rpc ImportTask(ImportTaskRequest) returns(google.protobuf.Empty);
// Export or download file from P2P cache system
rpc ExportTask(ExportTaskRequest) returns(google.protobuf.Empty);
// Delete file from P2P cache system
rpc DeleteTask(DeleteTaskRequest) returns(google.protobuf.Empty);
}

scheduler 接口

原来的 scheduler 接口:

// Scheduler System RPC Service
service Scheduler{
// RegisterPeerTask registers a peer into one task.
rpc RegisterPeerTask(PeerTaskRequest)returns(RegisterResult);
// ReportPieceResult reports piece results and receives peer packets.
// when migrating to another scheduler,
// it will send the last piece result to the new scheduler.
rpc ReportPieceResult(stream PieceResult)returns(stream PeerPacket);
// ReportPeerResult reports downloading result for the peer task.
rpc ReportPeerResult(PeerResult)returns(google.protobuf.Empty);
// LeaveTask makes the peer leaving from scheduling overlay for the task.
rpc LeaveTask(PeerTarget)returns(google.protobuf.Empty);
}

 

新增 2 个接口,下载复用之前的 RegisterPeerTask()接口,删除复用之前的LeaveTask() 接口:

// Scheduler System RPC Service
service Scheduler{
// Checks if any peer has the given task
rpc StatTask(StatTaskRequest)returns(Task);
// A peer announces that it has the announced task to other peers
rpc AnnounceTask(AnnounceTaskRequest) returns(google.protobuf.Empty);
}

接口请求时序图

StatTask

640 (51).png

ImportTask

640 (52).png

ExportTask

640 (53).png

DeleteTask

640 (54).png

代码实现

目前代码已经合并,可以在 Dragonfly v2.0.3 版本中使用。

upstream PR:

https://github.com/dragonflyoss/Dragonfly2/pull/1227


使用方法

除了增加新的接口之外,我们还增加了一个叫 dfcache 的命令,用于测试,使用方法如下:

- add a file into cache system
dfcache import --cid sha256:xxxxxx --tag testtag /path/to/file
- check if a file exists in cache system
dfcache stat --cid testid --local # only check local cache
dfcache stat --cid testid # check other peers as well
- export/download a file from cache system
dfcache export --cid testid -O /path/to/output
- delete a file from cache system, both local cache and P2P network
dfcache delete -i testid -t testtag

测试及效果

测试方法

通过新增的 dfcache 命令,在一个节点上向 P2P cache 系统中添加不同大小的文件,然后在另外一个节点上针对这个文件做查询、下载、删除等操作。例如:

# dd if=/dev/urandom of=testfile bs=1M count =1024
# dfcache stat -i testid # 检查一个不存在的文件
# dfcache import -i testid testfile
# on another node
# dfcache stat -i testid
# dfcache export -i testid testfile.export

测试效果

两台 ecs,网络走 vpc,带宽 3.45 Gbits/s (约 440MiB/s):

640 (55).png

下载的 ecs 磁盘带宽 180MiB/s 左右:

640 (56).png

640 (57).png

相关阅读链接:

1、Dragonfly1.x 链接地址:

https://github.com/dragonflyoss/Dragonfly

2、Dragonfly 架构文档:

https://d7y.io/zh/docs/concepts/terminology/architecture/

3、Dragonfly 官网链接:

https://d7y.io/

4、龙蜥云原生SIG地址链接:

https://openanolis.cn/sig/cloud-native

—— 完 ——


加入龙蜥社群


加入微信群:添加社区助理-龙蜥社区小龙(微信:openanolis_assis),备注【龙蜥】与你同在;加入钉钉群:扫描下方钉钉群二维码。

640 (5).png

相关文章
|
9月前
|
负载均衡 测试技术 调度
大模型分布式推理:张量并行与流水线并行技术
本文深入探讨大语言模型分布式推理的核心技术——张量并行与流水线并行。通过分析单GPU内存限制下的模型部署挑战,详细解析张量并行的矩阵分片策略、流水线并行的阶段划分机制,以及二者的混合并行架构。文章包含完整的分布式推理框架实现、通信优化策略和性能调优指南,为千亿参数大模型的分布式部署提供全面解决方案。
2572 4
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
251 2
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
11月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
1478 3
|
9月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
9月前
|
缓存 运维 监控
Redis 7.0 高性能缓存架构设计与优化
🌟蒋星熠Jaxonic,技术宇宙中的星际旅人。深耕Redis 7.0高性能缓存架构,探索函数化编程、多层缓存、集群优化与分片消息系统,用代码在二进制星河中谱写极客诗篇。
1711 3
|
9月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
604 1
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
631 61
|
10月前
|
消息中间件 监控 Java
Apache Kafka 分布式流处理平台技术详解与实践指南
本文档全面介绍 Apache Kafka 分布式流处理平台的核心概念、架构设计和实践应用。作为高吞吐量、低延迟的分布式消息系统,Kafka 已成为现代数据管道和流处理应用的事实标准。本文将深入探讨其生产者-消费者模型、主题分区机制、副本复制、流处理API等核心机制,帮助开发者构建可靠、可扩展的实时数据流处理系统。
851 4
|
10月前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
9月前
|
机器学习/深度学习 监控 PyTorch
68_分布式训练技术:DDP与Horovod
随着大型语言模型(LLM)规模的不断扩大,从早期的BERT(数亿参数)到如今的GPT-4(万亿级参数),单卡训练已经成为不可能完成的任务。分布式训练技术应运而生,成为大模型开发的核心基础设施。2025年,分布式训练技术已经发展到相当成熟的阶段,各种优化策略和框架不断涌现,为大模型训练提供了强大的支持。
1084 0

热门文章

最新文章