参数服务器原理与PyTorch RPC实现：从AllReduce到多机训练避坑指南

简介：面向深度学习研究者、工程师及高校学生，这份压缩包提供了一套基于参数服务器架构的分布式深度学习解决方案，适合在数据规模大、模型结构复杂的场景下提升训练效率，也可用于机器学习类课程设计、毕业设计与期末大作业。包内共一百四十四个文件，以C/C++头文件与实现源码、Python脚本、Shell脚本、Markdown文档为主，同时包含配置文件、proto协议定义及Makefile构建脚本，整体大小约8.72MB，目录模块覆盖特征提取、数据读取、模型定义、参数服务器通信、多线程训练脚本和辅助工具，各类型分工明确，并配有说明文档与示例样本，便于按需查阅。已有三十七人学习下载，资源体量虽小，但工程代码完整，适合希望理解参数服务器工作原理、并行训练流程的读者。通过研读源码和自动化运行脚本，可掌握多节点梯度聚合与参数更新的实现思路，也能为大规模机器学习实战或学业项目提供可复用的基础框架。

1. 参数服务器不是过时的名词：多机训练卡住时，它是被反复想起来的分布式架构

模型单卡装不下，数据单机跑不完，横向加机器是最直接的解法。可等真的把四张卡扩到四台机器，多数人会发现瓶颈不在 GPU 而在参数同步：每次迭代都要把梯度汇总回某个中心节点，这个中心的带宽和计算就成了新的天花板。这时候再回头看你可能早就听过的参数服务器架构，会发现它并不是被淘汰的旧方案，在异步训练、稀疏大模型和多机容错场景里，它反而比 AllReduce 更稳。下面把这些讲清楚：参数服务器是什么、最小实现怎么写、参数怎么调、五个坑在哪，适合准备从单机过渡到多机训练又不愿一上来部署重型框架的工程师。

2. 原理拆解：参数服务器为什么把“模型状态”和“训练计算”拆开

2.1 数据并行真正的瓶颈不在数据，而在梯度汇总

数据并行是分布式深度学习最常见的第一步：每张卡或每个 worker 都持有一份完整的模型副本，各自喂不同的 mini-batch，独立完成前向和反向，最后把梯度合到一起更新模型。初学者常以为多机训练最难的是数据切分，实际上数据切分只要按索引切好就行；真正决定训练能跑多快的是梯度怎么汇总。

用 AllReduce 时，每轮迭代要执行一次全局规约：每个节点把自己的梯度广播给集群里所有节点，等所有节点都收到后各自做归并。通信量和参数规模成正比，也和节点数量耦合在一起。单机四卡时这个问题不明显，因为走 PCIe 共享内存；一旦换成多机，每次梯度同步都要跨网卡，网络往返次数和字节数会急剧上升。这也是分布式训练经常出现“卡在某个迭代等 30 秒”的原因，慢的不是 GPU 算梯度的几毫秒，而是把梯度汇齐的那几百毫秒。

参数服务器把通信拓扑从“全连接”改成“星型”。worker 只管从 server 拉最新参数，算完梯度推回去，不参与其他 worker 的通信。这样做，worker 侧的网络流量是固定的——拉一次参数加推一次梯度，与集群里总 worker 数量无关。server 侧虽然承担全部流量，但 server 本身可以水平扩展：把参数按 key 分片到多台 server，每台只处理自己负责的那一段。这是 PS 架构最朴素也最重要的设计动机。

从调优空间看，PS 也比 AllReduce 更灵活。AllReduce 很难做稀疏通信，因为每次都要全量规约；PS 则天然适配“每次只有少量参数更新”的场景，比如推荐系统的 embedding 表。梯度压缩、本地多步累积、误差反馈这些技巧，几乎都是围绕 PS 的 push/pull 结构发展出来的。理解了这一点，你就能明白为什么很多大规模推荐系统至今仍坚持 PS 而不是纯 AllReduce。

2.2 同步、异步、混合：三种更新模式都长在参数服务器上

既然梯度都要汇聚到 server，那么“什么时候更新参数”就成了三种模式的分水岭。

同步模式（BSP）要求 server 收齐本轮所有 worker 的梯度，再做一次更新，然后把新参数广播出去。数学上收敛性质与单机 SGD 几乎一致，实现也直观。代价是明显的“木桶效应”：集群里最慢的一个 worker 决定全体的迭代速度。只要某一台机器发生网络抖动或 CPU 被其他任务抢占几十秒，整个训练就跟着停滞。集群规模越大，这种尾部延迟越频繁。

异步模式（ASP）放弃同步等待。worker 算完梯度就推，server 收到就更新，worker 不等任何同伴。吞吐量高，单个 worker 的故障也几乎不影响其他人。代价是梯度陈旧问题：一个 worker 拿到的参数可能是几个迭代之前的，它推回梯度时，服务器已经用更新的参数跑过好几轮。陈旧梯度累积到一定程度，loss 会抖动甚至发散。在异步模式下做稀疏模型时，新旧版本的冲突会更严重，因为同一个 key 可能被多个 worker 反复覆盖。

现实工程里用得最多的是混合模式，业界常称 SSP。它定义了一个允许的最大滞后差 s：当最快 worker 和最慢 worker 之间版本差小于 s 时，大家自由异步跑；一旦超过 s，全局强制同步一次。s 通常取 worker 数量的四分之一到一半，具体取值要看你的网络延迟抖动有多大。实现这个模式只需要在 server 端维护每个 worker 的上一次更新版本号，代码并不复杂，但它能同时救回吞吐和稳定性。

三种模式的选择不能凭喜好，得看训练任务的容忍度。下面这张表总结了我常用的取舍依据：

2.3 参数分片和版本号：把 server 这个黑匣子打开看

当模型参数大到单机内存放不下，比如全量 embedding 表，参数服务器必须拆成多个进程。常见做法是按参数名的哈希值做范围分片：worker 计算每个参数属于哪个 server，只与负责对应分片的 server 通信。这样每一台 server 的内存压力都可控，带宽压力也分摊了。

拆完之后，一致性问题就出来了。多个 worker 并发推送梯度时，server 怎么知道谁新谁旧？答案是版本号。server 在参数更新时维护一个递增的 version，worker 拉参数时拿到当前 version，推梯度时把这个 version 带回。如果版本落后过多，server 可以拒绝这次推送或降低它的权重。在同步模式下，还需要一个全局 barrier 保证“所有人都拿到同一版参数后才能进入下一轮”。有人会用分布式锁来实现这个 barrier，但我不推荐——每次 barrier 加锁解锁都多一轮远程调用，网络抖动会把全局卡得更死。自己维护一个计数器，在 server 端判断 recv_count 是否等于 num_workers，比依赖外部锁更可控。

从架构上看，参数服务器还天然支持弹性训练。某个 worker 掉线后，server 只需把它的 recv_count 重置，或等它在超时后重新连上；而 AllReduce 里掉线常常需要整个集群重启。这也是为什么说 PS 的容错边界更清晰。不过这个好处要到训练真的跑在云上、节点经常被抢占时才真正感觉出来，本地机房反而不容易感知。

3. 落地：用 PyTorch RPC 手写一个最小参数服务器

3.1 最小实现：server 端代码与 worker 端代码

先说明方向：我见过很多团队一上来就搬 BytePS 或者 ps-lite，配置一大堆网络参数，最后卡在环境搭建上。常见做法是先抛开框架，用 PyTorch 自带的 RPC 在单机上三进程跑通，验证逻辑正确后再考虑换不换重型方案。下面这套代码是我保留的最简形态，去掉它跑不了，但不去掉你也能看得懂。

# ps_server.py —— 参数服务器节点 # 三个进程：server(rank=0) + worker(rank=1,2) import threading import torch import torch.distributed.rpc as rpc from torch import nn class ParamServer: def __init__(self, params, lr=0.1, num_workers=2, mode="sync"): self.lock = threading.Lock() self.num_workers = num_workers self.mode = mode self.grad_acc = None # 本轮梯度累加器，同步模式下使用 self.recv_count = 0 # 已收到几个 worker 的梯度 self.params = [p.detach().clone() for p in params] self.optim = torch.optim.SGD(self.params, lr=lr) def push_gradient(self, worker_rank, grads): # grads 是与 self.params 同序的梯度张量列表 with self.lock: if self.grad_acc is None: self.grad_acc = [g.clone() for g in grads] else: for i in range(len(grads)): self.grad_acc[i] += grads[i] self.recv_count += 1 if self.mode == "sync": # 核心逻辑：收齐 num_workers 个梯度才更新 if self.recv_count == self.num_workers: for p, g in zip(self.params, self.grad_acc): p.grad = g self.optim.step() self.optim.zero_grad() self.recv_count = 0 self.grad_acc = None return [p.detach().clone() for p in self.params] return None # 没凑齐，告诉 worker“再等等” else: # 异步模式：来一份梯度就更新一次 for p, g in zip(self.params, grads): p.grad = g self.optim.step() self.optim.zero_grad() return [p.detach().clone() for p in self.params] def pull_param(self): return [p.detach().clone() for p in self.params]

# ps_worker.py —— 训练 worker 节点 import torch import torch.distributed.rpc as rpc from torch import nn, optim import torch.nn.functional as F def run_worker(rank, server_name, loader, model): # world_size 固定为 3：1个 server + 2个 worker rpc.init_rpc(f"worker{rank}", rank=rank, world_size=3) server = rpc.remote(server_name, ParamServer) # 拿到远程 server for epoch in range(epochs): for x, y in loader: # 每轮迭代先拉一次当前参数，保证本地模型尽量新 latest = rpc.rpc_sync(server, ParamServer.pull_param) with torch.no_grad(): for lp, new in zip(model.parameters(), latest): lp.copy_(new) out = model(x) loss = F.cross_entropy(out, y) loss.backward() grads = [p.grad.detach().clone() for p in model.parameters()] # 推梯度，同步模式下只有凑齐时才返回新参数 new_params = rpc.rpc_sync(server, ParamServer.push_gradient, args=(rank, grads)) if new_params is not None: with torch.no_grad(): for lp, new in zip(model.parameters(), new_params): lp.copy_(new) model.zero_grad() rpc.shutdown()

代码逻辑说明：server 端最核心的是grad_acc和recv_count这对组合。同步模式下，每个 worker 各自把梯度推到 server，server 先累加不更新；等到 recv_count 等于 num_workers 时，才把累加好的梯度交给优化器 step 一次，并返回新参数。异步模式下不去判断 recv_count，每收到一份梯度就更新一次，返回的也是最新的参数。

参数说明：lr是学习率，同步多 worker 时要按 batch size 倍率缩放；num_workers是这个训练任务的总 worker 数量，必须在所有 server/worker 进程间保持一致；mode控制同步或异步。rpc.rpc_sync是阻塞调用，确保 worker 推完梯度拿到返回值后才继续下一次迭代；如果换成rpc.rpc_async，要注意返回值是 Future，需要用wait()收一下，否则容易在异步模式下弄丢返回参数。

3.2 启动与伪分布式验证：先在单机三进程跑通

下面的启动命令在同一台机器上模拟一个 server 加两个 worker：

# 终端1：起 server python ps_server.py --role server --world_size 3 --rank 0 # 终端2：起 worker0 python ps_worker.py --role worker --world_size 3 --rank 1 --train_data ./data/train_0.csv # 终端3：起 worker1 python ps_worker.py --role worker --world_size 3 --rank 2 --train_data ./data/train_1.csv

为什么先在单机跑？因为单机上 3 个进程走的是本机回环网络，能过滤掉大部分物理网络干扰，暴露真正的逻辑问题。如果这段伪分布式跑出来的 loss 和不分布式时差很多，那问题大概率在你的 PS 实现而不是网卡。

跑通后检查三件事：worker 日志能看到每步打印的 loss 且总体趋势下降；server 日志里 recv_count 能到 2 并重置，说明同步 barrier 生效；用nvidia-smi看两个 worker 的 GPU 利用率，都应该在 90% 以上而不是某个进程空转。如果利用率一高一低，多半是数据加载线程在某个进程里阻塞了。

注意：这里的 world_size 是总进程数（server + 所有 worker），不只是 worker 个数。写错这个值，RPC 初始化会在等待阶段卡死。

跑通单机伪分布式后，改成真正的多机只需要改 RPC 的初始化方式。把rpc.init_rpc里的 world_size 改为机器总数，每个进程的 rank 对应不同机器，再让各进程通过共享的init_method（比如文件系统或 TCP 地址）找到彼此。常见坑：不同机器之间的防火墙没放通 RPC 端口；或者 rank 和 worker id 混用，导致 server 接收梯度时把不同 worker 的贡献叠加到了同一个位置。

3.3 什么情况下才需要换正经 PS 框架

自己写的 PS 能跑通，并不代表能应对生产。要不要换 BytePS 或 ps-lite 这类成熟方案，我自己的判断信号有四个：

• worker 进程被调度器杀掉后，自写版本不能自动拉起并恢复训练；
• 需要把参数表按 key 分片到多机，而你的手写代码还在用全量复制；
• 训练每天跑超过十个小时，期间要保证 server 不重启不丢状态；
• 通信成为明确瓶颈，需要梯度压缩、量化等现成实现。

在没有这些信号之前，手写 RPC 版本反而是最好的学习工具。如果你是从动手深度学习那本书入门的，会发现书上默认你用单机多卡，几乎不讲 PS 这一段；等自己手写一遍 push/pull，再看 BytePS 的源码，会清楚知道它的通信优化到底改在哪一层。等你真的要换框架，也会因为写过一遍，能看懂 BytePS 里的 push/pull 到底发生在哪一层，而不只是把它当一个黑盒。

4. 参数调优：从“能跑”到“跑得快且稳”

4.1 学习率与 batch size 的线性缩放规则

多 worker 分布式训练的第一步数学定律：单机 batch size 为 B，学习率为 lr；当 N 个 worker 并行，每个 worker 的 batch size 仍是 B 时，全局 batch size 是 NB，学习率近似取 N×lr。直接从单机迁移不调整学习率，会发现在 batch size 翻倍后，模型收敛变慢甚至精度下降。

这有个前提：学习率并不能一下子跳到 N 倍。比较稳妥的做法是 warmup——先从一个较小的学习率开始，用若干个 epoch 线性增加到 N×lr。warmup 步数一般取训练总步数的 5% 到 10%，数据越不均匀，warmup 要越长。我一般先跑一个 100 步的小实验，看 loss 曲线在 warmup 结束后是继续下降还是开始震荡，震荡就说明 warmup 不够或学习率上限太高。

如果是异步模式，学习率还要进一步打折。异步模式下的有效更新方向是“旧梯度 + 新参数”，两者错位会让每一步实际走的步长偏大。常见保守做法是把异步模式学习率设为同步模式的 1/2 到 1/4，再配合延迟补偿或梯度裁剪。很多人觉得异步快，直接照搬单机学习率，结果 loss 曲线一路乱跳，这不是异步的错，是学习率根本没按模式换算。

4.2 top-k 稀疏化和误差反馈：通信带宽有限时的省钱方式

PS 架构有一个 AllReduce 做不了的事：只通信少量“重要”梯度。因为 embedding 这类模型每次只有少数 key 被更新，worker 可以只把非零分量推给 server，而全量规约很难这样精简。

即使对稠密模型，也可以做 top-k 稀疏化：把梯度展平后按绝对值排序，只保留最大的 k 个值，其余置零。被丢弃的部分不直接扔，而是累积到本地 buffer 里，下一轮和本轮梯度一起补偿回来。这个“误差反馈”机制是稀疏化的灵魂，没有它，梯度丢多了模型根本训练不起来。

# sparsify.py —— 梯度稀疏化 + 误差反馈 def topk_sparsify(grad, buffer, k_ratio=0.01): grad_vec = grad.flatten() k = max(int(grad_vec.numel() * k_ratio), 1) # 取第 k 大的绝对值作为阈值，top-k 保留 threshold = grad_vec.abs().topk(k).values[-1] mask = grad_vec.abs() >= threshold sparse_grad = grad_vec * mask # 本轮没传的部分先记到误差 buffer，下一轮再补 error = (grad_vec - sparse_grad) + buffer return sparse_grad.view(grad.shape), error

代码说明：k_ratio设为 0.01 表示只通信 1% 的梯度分量。buffer是上一轮遗留的误差，它会在下一轮被加进当前梯度，让被丢弃的信息不会永久消失。topk的阈值取第 k 大的绝对值，保证每一轮通信量稳定，不会因为某轮梯度整体特别小或特别大而波动。

用这个函数时要注意：误差反馈 buffer 要在每个 worker 本地保存，不能在 server 端做。因为 server 聚合的是所有 worker 的梯度，把误差累积在 server 会变成跨进程的全局状态，排查起来非常痛苦。稀疏度也不是越高越好，当 k_ratio 低到 1% 以下时，收敛后期会停在某个平台上不去，这时需要提高 k_ratio 或隔若干步做一次全量同步校准。

4.3 本地多步累积：减少通信频率的另一条路

如果网络已经优化到极限但延迟仍然高，可以考虑让每个 worker 本地多跑几步再 push。具体做法是：worker 用本地模型连续更新 K 个 mini-batch，K 步做完之后把累积的梯度推给 server，再把 server 的新参数覆盖到本地。

这个办法本质上是把通信频率从“每步一次”降到“每 K 步一次”，净吞吐会明显提升；但它也会改变优化轨迹，相当于在局部用更大的有效 batch size。K 取值我一般从 2 开始试，最大不超过 10。K 太大会让各 worker 的模型发散度变高，即使后期同步拉回来，精度也会打折扣。想验证 K 是否合适，可以对比同样的总步数下 K=1 和 K 放大后的收敛 loss，差异在一个点以内说明可以接受。

提示：异步模式调试期尽量先在混合模式下验证，观察 loss 趋势后再切成全异步。直接全异步排查起来会把“梯度陈旧”和“学习率不当”混在一起，很难定位根因。

5. 避坑与排查：分布式训练最容易翻车的五个地方

5.1 现象：训练像爬坡，时快时慢，某一步等了半分钟

原因：同步模式下，最慢的 worker 拖住了全局。除了物理网络抖动，最常见是某个 worker 的 GPU 被其他任务抢占，或它的 CPU 负责数据预处理进行不下去。参数服务器本身不会消除 straggler 效应，它只是把焦点放在了 server 上。

解决：先确认是不是同步模式下的尾延迟。给每个 worker 的迭代耗时做日志，如果某个 worker 的单步耗时长期大于其他人，先检查本机资源；如果波动是偶发的，给 server 端增加一个“超时跳过”策略：等待超过预设时间就忽略还没到的梯度，按已到的 worker 子集更新。或者干脆切到异步或混合模式，把滞后边界 s 设到 4 左右，让慢 worker 不至于拖死全局。

5.2 现象：loss 突然变 NaN 或发散，而且重跑一次未必复现

原因：异步模式下，陈旧梯度在高学习率下会造成灾难性更新。一个 worker 推回的梯度可能对应几个 iteration 之前的参数，此时 server 已经更新了几轮，梯度方向与当前参数不再匹配。学习率越大，这种错位越致命。

解决：把异步模式的学习率降到同步模式的 1/2 到 1/4，不要直接照搬单机的 lr；第二个做法是限制陈旧度——server 记录每个 worker 上次更新的 version，如果 worker 推送时版本落后超过设定阈值就丢弃或延迟并入；第三个做法是每次 step 前对梯度做一次归一化，把梯度模长限制在一个固定范围内，防止单次大梯度把 loss 打到十几倍。

5.3 现象：训练跑着跑着，server 进程内存一直涨，最后被 OOM 杀死

原因：server 端梯度累加器没有按预期重置。我在自写代码时出现过一次：同步模式下 recv_count 满足条件后，更新了 self.params 但忘了把 grad_acc 置为 None，下一轮新旧梯度叠加，内存和数值双双爆炸。异步模式还有一种情况：如果每个 worker 的版本参数都被保存在内存的 dict 里，而没有清理旧版本，server 会随着迭代把整份历史参数都留在内存里。

解决：检查 push_gradient 里，同步分支在 step 之后是否把 grad_acc 重置为 None；如果异步模式需要缓存历史版本做回滚，用一个固定大小的队列，只保留最近的若干版本，不要无限追加。内存曲线如果在 500 步内线性上升，基本可以锁定是这个原因。

5.4 现象：重跑训练报 address already in use，连接数疯狂增长

原因：上一次训练的 server 或 worker 进程没有顺利退出。PyTorch RPC 在进程被 kill 时不一定能主动释放端口，残留进程会一直占着端口，新的训练任务接不上。

解决：启动脚本里不要直接 nohup，先做一个预处理：找出所有历史 server/worker 进程并 kill。可以用一个 shell 脚本统一管理：

# run_ps.sh —— 清理旧进程并重新拉起 pkill -f ps_server.py 2>/dev/null pkill -f ps_worker.py 2>/dev/null sleep 2 nohup python ps_server.py --role server --world_size 3 --rank 0 > /tmp/ps_server.log 2>&1 & nohup python ps_worker.py --role worker --world_size 3 --rank 1 --train_data ./data/train_0.csv > /tmp/ps_worker0.log 2>&1 & nohup python ps_worker.py --role worker --world_size 3 --rank 2 --train_data ./data/train_1.csv > /tmp/ps_worker1.log 2>&1 &

sleep 2 是为了让操作系统的端口充分释放。如果要更可靠，可以让 server 在退出时调用rpc.shutdown()并等待绑定端口解除，再恢复默认处理。

5.5 现象：loss 收敛正常，但最终精度比单机低一两个点

原因：全局 batch size 扩大后，没有同步调整学习率、warmup 和 epoch 数。还有一个偷换概念但很常见的错误：把“每个 worker 的 epoch 数”当成“全局的 epoch 数”，导致数据被重复喂了很多遍，模型早早就过拟合。

解决：全局 epoch 数等于目标 epoch 数不变，每个 worker 只需跑全局数据的一部分。具体说，如果 N 个 worker 各跑完整数据一遍，全局等价于 N 个 epoch。所以如果目标 epoch 是 10，每个 worker 只要跑 10/N 个 epoch。配合前面说的线性缩放规则重新设学习率，精度差距一般能压到 0.5 个点以内。

5.6 日志与监控：怎么判断问题是网络、代码还是数据

写一个简单到可用的监控：在 server 端每隔一定时间打印收到的梯度字节数和耗时；worker 端记录一次迭代中“拉参数耗时”和“推梯度耗时”的占比。如果推梯度耗时占单步总耗时的 30% 以上，优先怀疑网络包大小或网卡带宽。如果占比不高但总耗时仍然很大，问题多半在 server 端 CPU 或数据加载。

下面这张表是我排查时最先看的三个指标：

如果 server 端日志里出现“梯度累计计数没有按预期增长”，我会把日志级别从 info 调到 debug，打印每个 worker 的 rank 和 version，人工核对是掉线还是逻辑分支没走到。

6. 上线前最后一把锁：用四个对比实验验证参数服务器是对的

第一实验：单 worker 的伪分布式与单机标准训练对比。把 num_workers 设为 1，让 PS 退化成“参数更新在一个 server 里、数据只来自一个 worker”，跑 50 到 100 步，记录每步的 loss。这条 loss 曲线应该和单机标准 SGD 几乎一模一样。如果在这里偏差超过 1%，说明你的代码不是参数服务器，而是某个隐藏的数据切分或初始化问题。

第二实验：两个 worker 的同步 PS，与“单机、batch size 翻倍”的 SGD 对比。两个 worker 各自吃 batch=32，server 聚合后相当于一次 batch=64 的全局更新；单机用 batch=64 直接跑同样的数据分布。两者 loss 曲线如果趋势差在 0.5 个点内，说明 PS 的同步语义正确。

第三实验：扩展性验证。把 worker 从 2 个扩到 4 个，看单步吞吐（每秒处理样本数）是否接近线性增长。网络状态好的时候，4 个 worker 相对 2 个 worker 应该接近 2 倍；如果只有 1.3 到 1.4 倍，先查通信是不是占满了网卡带宽，再考虑梯度压缩。线性扩展不等于逻辑正确，但它能暴露同步模式下的通信瓶颈。

第四实验：部署验证。训练结束后，把保存在 server 的最终参数导出，在单卡推理服务上加载，和普通单机训练的模型在同一份验证集上对比精度。这一步主要验证“参数同步过程中是否有累积的损伤”。有些问题 loss 曲线看上去正常，精度却悄悄掉了，把两个模型的输出做逐样本差异对比，差异率在 0.1% 到 0.5% 以内才敢发上线。

我给自己定的规矩是“每个新模型上线前，先跑一遍这四个实验，再写上线申请”。有一次我偷懒，只看了 loss 下降就切到异步模式上线，结果推理端明显感觉到单 batch 多训练，最后回滚才发现是陈旧梯度把 embedding 更新带偏了。这些步骤并不复杂，但每一步都能提前拦下一个会坑到生产的问题。希望这条验证路径能帮到你。

本文还有配套的精品资源，点击获取