微店（微盟旗下电商平台）的全量商品详情 API 分布式请求实践，核心目标是高效覆盖所有商品、规避平台限制、保障数据完整性。微店 API 在权限体系、调用限制、数据结构上有显著差异，需针对性设计方案。以下从实践角度拆解关键环节：
micro.item_get
公共参数
| 名称 | 类型 | 必须 | 描述 |
|---|---|---|---|
| key | String | 是 | 调用key（必须以GET方式拼接在URL中） |
| secret | String | 是 | 调用密钥 |
| api_name | String | 是 | API接口名称（包括在请求地址中）[item_search,item_get,item_search_shop等] |
| cache | String | 否 | [yes,no]默认yes，将调用缓存的数据，速度比较快 |
| result_type | String | 否 | [json,jsonu,xml,serialize,var_export]返回数据格式，默认为json，jsonu输出的内容中文可以直接阅读 |
| lang | String | 否 | [cn,en,ru]翻译语言，默认cn简体中文 |
| version | String | 否 | API版本 |
一、微店 API 的核心限制与特性（实践前提）
需先明确微店开放平台的约束：
- 权限与授权：商品详情 API（如
weidian.item.get）需基于 “店铺授权”，即需先获取目标店铺的access_token（有效期通常 2 小时，需定期刷新），无授权的调用直接返回401 Unauthorized。 - QPS 限制：单店铺授权下的 API 调用有 QPS 上限（通常 50-200，不同店铺可能因等级调整），跨店铺调用共享全局 QPS（如 appkey 总 QPS=1000）。
- IP 限制：单 IP 对微店服务器的请求频率过高（如 1 分钟内超 500 次）可能被临时封禁（返回
403 Forbidden或超时），且 IP 黑名单机制较严格。 - 分页与全量限制：商品列表 API（如
weidian.items.list）分页返回，单页最大 20 条，且全量获取时需遍历所有分页（若店铺有 10 万商品，需 5000 次分页请求）。
二、分布式架构设计（适配全量场景）
全量商品请求需处理 “海量店铺 + 海量商品” 的双层任务，架构需支持分层任务调度、店铺级隔离、全量覆盖保障，典型架构如下：
[店铺源] → [店铺队列] → [店铺调度] → [商品队列] → [商品调度] → [执行节点集群] → [微店API] ↓ ↓ ↓ ↓ [token管理] [分页任务生成] [店铺级限流] [监控与重试]
1. 任务源与双层队列：解决全量 “店铺 - 商品” 层级问题
全量商品请求的起点是 “店铺列表”，需先获取店铺，再遍历每个店铺的商品，因此需设计双层队列：
- 店铺源：需覆盖所有目标店铺（如从业务数据库同步的店铺 ID 列表，含是否授权的标记）。
- 店铺队列（第一层）：用 RabbitMQ 的
x-delay-message延迟队列存储待处理店铺，按 “店铺授权有效期” 排序（优先处理即将过期的 token 对应的店铺，避免授权失效）。 - 商品队列（第二层）：每个店铺的商品任务单独分片（如按店铺 ID 哈希分区），避免不同店铺的商品任务混流，便于按店铺控制 QPS。
2. 店铺调度：生成全量商品分页任务
店铺调度模块从店铺队列消费店铺信息，核心职责是 “将店铺转化为可执行的商品分页任务”：
- token 刷新：调用微店
token.refresh接口刷新即将过期的access_token（提前 30 分钟触发），并存储到 Redis（key=shop:{shop_id}:token）。 - 分页任务生成：
- 先调用
weidian.items.list获取店铺商品总数（total_count），计算总页数（total_page = ceil(total_count / 20)）。 - 按页码生成分页任务（如
shop_id=123&page=1、shop_id=123&page=2），推送到对应店铺的商品队列。
3. 商品调度：按店铺级 QPS 控制全局速率
商品调度中心负责协调节点资源，核心是 “按店铺分配配额”（因微店 QPS 限制以店铺为单位）：
4. 执行节点：精细化请求执行与容错
执行节点从商品队列消费分页任务，核心是 “合规调用 + 完整获取商品详情”：
- 本地限流：按店铺 ID 粒度用漏桶算法限流（如店铺 A 的节点本地 QPS≤50），避免单节点超店铺配额。
- 请求封装：
- 分页请求携带
page和page_size=20，获取商品 ID 列表后，批量调用weidian.item.get（支持批量查询，一次最多 10 个商品 ID），减少请求次数。
- 失败处理：
- 分类重试：
429（店铺 QPS 超限）→ 延迟重试（延迟时间 =(当前重试次数+1)*10s，最多 5 次），并临时下调该店铺配额（如降 10%）。401（token 失效）→ 触发店铺调度模块的 token 刷新，任务回退到店铺队列头部。5xx（微店服务错误）→ 立即重试（最多 3 次），失败则标记为 “待人工处理”。
- 断点续传：记录每个店铺的已完成页码（Redis key=
shop:{shop_id}:last_page），若节点宕机，重启后从last_page+1继续，避免重复请求。
5. 数据存储与缓存：支撑全量数据落地
全量商品数据量大（如 100 万商品，每条 1KB 即 100GB），需兼顾存储效率和查询需求：
- 分布式缓存：Redis 集群存储热点商品（如近 24 小时有更新的商品），key=
item:{item_id}，过期时间 2 小时（微店商品更新较频繁）。 - 持久化存储：用 MySQL 分库分表（按
item_id哈希分片）存储全量商品，字段含shop_id、title、price、stock、update_time等，同时用 Elasticsearch 建立索引（支持按店铺、分类、价格区间检索）。 - 增量标记：每次全量请求后，对比商品的
update_time，标记 “新增 / 修改 / 下架” 状态，便于业务系统同步。
6. 监控与全量校验：保障数据完整性
全量请求的核心风险是 “漏数据”，需通过监控和校验机制兜底：
- 核心监控指标：
- 店铺维度：每个店铺的任务完成率（
已完成页数/总页数）、失败页码分布、token 刷新成功率。 - 商品维度：单店铺商品总数（API 返回）与实际存储数的差值、重复商品 ID 数（需去重）。
- 系统维度：节点并发数、代理 IP 可用率、队列堆积量（单店铺商品队列堆积超 100 页即告警）。
- 全量校验机制：
- 每日全量完成后，随机抽取 10% 的店铺，重新调用其商品列表 API，对比总页数与实际完成页数，差异超 5% 则触发补爬。
- 对 “下架商品”（API 返回
is_deleted=true），校验是否在存储中标记，避免垃圾数据堆积。
三、关键挑战与解决方案
- 全量任务规模失控：
- 问题：若店铺数量超 1 万，单店铺平均 100 页，总任务量达 100 万，可能压垮队列。
- 解决：按 “店铺等级” 分批次执行（如核心店铺优先，普通店铺分时段执行），并限制单批次并发店铺数（如同时处理 500 个店铺）。
- token 刷新连锁失败：
- 问题：若大量店铺 token 同时过期，集中刷新可能触发
token.refresh接口的 QPS 限制。 - 解决：token 过期时间分散化（初始授权时按店铺 ID 哈希错开 30 分钟），并为
token.refresh单独配置 QPS（如 200QPS），超过则进入延迟队列。
- 分页数据不一致：
- 问题：全量过程中店铺商品更新（如新增 / 下架），导致分页数据偏移（如第 5 页商品 ID 与初始获取的列表不一致）。
- 解决：分页任务生成时记录 “快照时间”，若执行时发现
total_count变化超 10%，则重新生成该店铺的分页任务。
四、合规性与成本优化
- 成本优化：
- 非核心店铺降低全量频率（如从每日 1 次改为每 3 日 1 次），通过增量接口（如
weidian.items.update.list）获取更新商品。 - 批量调用优先（
weidian.item.get一次查 10 个商品，比单条调用节省 90% 请求量）。
错误码解释
| 状态代码(error_code) | 状态信息 | 详细描述 | 是否收费 |
|---|---|---|---|
| 0000 | success | 接口调用成功并返回相关数据 | 是 |
| 2000 | Search success but no result | 接口访问成功，但是搜索没有结果 | 是 |
| 4000 | Server internal error | 服务器内部错误 | 否 |
| 4001 | Network error | 网络错误 | 否 |
| 4002 | Target server error | 目标服务器错误 | 否 |
| 4003 | Param error | 用户输入参数错误 | 忽略 |
| 4004 | Account not found | 用户帐号不存在 | 忽略 |
| 4005 | Invalid authentication credentials | 授权失败 | 忽略 |
| 4006 | API stopped | 您的当前API已停用 | 忽略 |
| 4007 | Account stopped | 您的账户已停用 | 忽略 |
| 4008 | API rate limit exceeded | 并发已达上限 | 忽略 |
| 4009 | API maintenance | API维护中 | 忽略 |
| 4010 | API not found with these values | API不存在 | 忽略 |
| 4012 | Please add api first | 请先添加api | 忽略 |
| 4013 | Number of calls exceeded | 调用次数超限 | 忽略 |
总结
微店全量商品详情 API 的分布式请求，核心是 “以店铺为单位的分层调度”：通过双层队列解耦店铺与商品任务，按店铺 QPS 精准限流，结合 token 生命周期管理和分页断点续传，保障全量覆盖；同时通过代理池、监控校验和增量优化，平衡效率、稳定性与成本。需针对性设计调度策略。
