电商数据抓取系统最危险的故障，往往不是任务报错，而是任务连续显示“执行成功”，数据库里的商品却开始重复、覆盖，甚至出现“标题来自上午、价格来自下午、库存来自另一家店铺”的混合记录。我排查过一类典型系统：任务每 10 分钟启动一次，正常耗时约 8 分钟，开发人员认为周期设置合理；但在促销日，单次耗时升到 17 分钟，下一轮任务已经启动，最终同一商品在数据库中产生了 3 条记录，旧价格还覆盖了新价格。

这类问题表面上像解析错误或数据库性能不足，根因却经常位于调度周期、任务并发、重试机制、业务唯一键和数据版本控制之间的断点。本文不讨论如何绕过平台限制，也不把“提高抓取速度”当作解决方案，而是按照任务触发、数据采集、结果校验、写入数据库和异常恢复的完整链路，给出一条开发人员可以直接执行的排查路径。

一、先讲核心结论：存储混乱通常是时间线失控

1. 不要先问“哪条 SQL 写错了”，先还原任务时间线

当开发人员发现数据库里有重复商品、价格回退或字段错配时，第一反应通常是检查 INSERT、UPDATE 或字段映射。但在实际排查中，SQL 只是最后一个环节。更有价值的问题是：哪一个任务实例，在什么时间，拿着哪一批数据，对哪一条记录执行了什么操作。

如果没有 run_id、batch_id、worker_id 和采集时间，数据库只会留下“结果”，不会留下足够的因果信息。你看到商品当前价格是 89 元，却不知道这条记录来自 09:00 任务、09:10 任务，还是一次延迟 20 分钟才完成的重试请求。

我通常把问题拆成五个时间点：计划触发时间、任务实际开始时间、源数据采集时间、数据库提交时间、任务最终结束时间。很多“新数据被旧数据覆盖”的故障，都是因为开发人员只记录了 updated_at，却没有保存 source_time 和 batch_id。

2. 任务成功不等于数据正确

调度器往往只关心进程是否返回 0，或者接口是否返回 HTTP 200。只要程序没有抛出未捕获异常，任务就会被标记为成功。但这并不代表数据没有重复、关键字段没有为空，也不代表本批次的所有商品都已经正确落库。

例如，一次批量写入处理 10,000 个 SKU，其中 9,800 个成功、200 个因字段校验失败被跳过。如果程序最后仍返回成功，调度器会认为任务完成，下一轮任务可能再次抓取并重复处理这 200 个 SKU。久而久之，系统形成“任务成功率 100%，业务数据完整率 96%”的错觉。

排查时必须同时看任务状态和数据质量状态。前者回答“程序有没有跑完”，后者回答“结果是否满足业务要求”。这两个状态不能用一个 success 字段代替。

3. 真正需要治理的是“同一业务事实被重复或错误地写入”

电商采集系统保存的可能是当前状态，也可能是历史快照，还可能是原始响应。三者的存储逻辑不同。当前状态表通常希望同一个店铺、商品和 SKU 只有一条有效记录；历史快照表允许同一商品在不同采集时间出现多条记录；原始层则更关注保留采集证据。

如果这三种模型混在一张表里，开发人员很容易把“历史记录变多”误判为重复数据，也可能为了消除重复而误删本应保留的价格变化。先定义这张表要表达什么，再讨论去重，是排查的第一条原则。

二、真实场景：为什么平时正常，促销日突然失控

1. 一个典型的商品价格采集案例

下面这个案例采用脱敏后的情景数据，数字用于还原排障过程，不代表某一家企业的公开统计。系统每天采集多个店铺的商品标题、价格、库存和活动标签，数据库分为商品主表、SKU 状态表和价格历史表。

最初的任务配置是每 10 分钟执行一次。普通时段单次任务耗时在 5 到 8 分钟之间，开发人员观察到任务通常能在下一次触发前结束，因此没有设置并发限制。促销活动开始后，目标页面响应变慢，部分接口出现超时，单次任务 P95 耗时升至 14 分钟，P99 耗时达到 22 分钟。

这类故障有一个很容易被忽略的特征：监控面板显示任务没有失败，数据库连接池也没有持续报错，应用 CPU 甚至没有达到上限。但数据质量已经开始下降。原因是系统的吞吐能力、任务并发能力和业务写入正确性并不是同一个指标。

2. 真正造成覆盖的不是“谁先开始”，而是“谁最后写入”

假设任务 A 在 10:00 开始，任务 B 在 10:10 开始。A 读取到商品价格 99 元，但因页面响应慢，直到 10:28 才写入；B 在 10:10 读取到促销价格 89 元，并于 10:18 完成写入。如果 A 没有版本条件，10:28 的旧数据就会覆盖 B 在 10:18 写入的新数据。

数据库中的最终结果可能是 99 元，updated_at 也是 10:28。只看这两个字段，开发人员很容易认为 99 元是最新数据。实际上，A 的数据库提交时间更晚，但源数据采集时间更早。提交晚不代表业务版本新，updated_at 不能替代 source_time。

如果系统还把标题、价格、库存拆成三次独立更新，问题会进一步放大。标题请求来自 A，价格请求来自 B，库存请求又来自一次重试，最终一行记录看起来完整，却没有任何一个字段真正属于同一采集快照。

3. 重试如何把一次不确定性变成两次写入

网络超时是采集系统中最容易制造重复的场景之一。应用发送写入请求后，数据库可能已经提交，但应用没有及时收到响应，于是根据超时策略重新发送。对于应用来说，第一次请求是“未知结果”；对于数据库来说，第一次请求可能已经是“成功结果”。

如果写入使用自增主键，每次重试都会生成新记录。即便业务字段完全相同，数据库也不会认为它们重复，因为技术主键不同。这个问题通常在日志中表现为“第一次请求超时，第二次请求成功”，而数据库中却有两行完全相同的商品数据。

修复重点不是简单降低重试次数，而是为每个业务写入请求生成稳定的幂等标识。重试时必须携带相同的幂等键，让数据库或应用层识别“这是同一个业务动作的再次提交”。

三、常见误区：为什么很多修复会越改越复杂

1. 误区一：任务没有报错，所以数据不可能是任务问题

这是最常见的判断错误。调度器通常不理解业务数据，它只知道进程退出码、心跳或接口响应。如果程序成功执行了错误的业务逻辑，或者部分商品被静默跳过，任务仍然可能被标记为成功。

我建议将任务结果拆成三层：执行结果、处理结果、质量结果。执行结果表示程序是否正常退出；处理结果表示读取、解析和写入了多少条；质量结果表示重复率、空值率、异常价格比例是否超过阈值。

2. 误区二：加一把分布式锁就解决了

分布式锁可以阻止多个任务实例同时运行，但它无法解决所有存储问题。如果同一任务只有一个实例，单条请求仍然可能因为超时重试而重复写入；如果唯一键设计错误，锁释放后仍然会保存错误记录；如果旧批次延迟写入，锁也不能阻止它覆盖新批次。

锁本身还有失效风险。任务耗时超过锁的过期时间时，第二个实例可能重新获得锁；网络分区或节点暂停也可能导致持锁状态与实际执行状态不一致。因此，锁必须配合租约续期、持有者标识、超时兜底和任务状态校验。

锁解决的是“同时有几个执行者”，幂等解决的是“同一业务动作重复执行后结果是否一致”，版本控制解决的是“旧数据能否覆盖新数据”。这三个问题不能相互替代。

3. 误区三：只用商品 ID 作为唯一键

在电商场景中，商品 ID 并不总是业务唯一。相同商品可能出现在不同店铺、不同销售区域、不同活动页面或不同规格下。若只使用商品 ID 去重，可能把本应分开的记录强行合并。

更合理的唯一键通常需要结合业务上下文，例如 shop_id、product_id、sku_id 和 region_code。若保存的是价格历史，还需要加入 snapshot_time 或业务版本；若保存的是当前状态，则应保证同一业务实体只保留一条有效记录。

唯一键不是字段越多越好。字段过多会导致同一商品因为采集时间、格式化差异或空值变化而无法去重。设计时应先回答：“两条记录在业务上是否代表同一个事实？”再决定键的组成。

4. 误区四：把所有异常都归因于数据库性能

数据库慢会造成超时，但“数据混乱”不等于“数据库性能不足”。如果数据库执行时间稳定，应用仍然重复提交同一批数据，优化索引并不能解决重复记录；如果字段映射错误，增加连接数只会让错误数据写得更快。

判断性能是否为根因，需要同时看 SQL 执行耗时、锁等待、连接池等待、事务提交耗时和应用重试次数。只有当这些指标与异常时间段同步上升时，才适合把性能作为主线继续分析。

5. 误区五：发现重复后直接删除“多余记录”

直接删除重复数据可能破坏排障证据。你需要先知道重复记录来自哪个任务、哪个批次、哪次重试，以及它们是否已经同步到下游系统。尤其是价格、库存等敏感数据，错误记录可能已经影响报表、告警或业务决策。

更稳妥的做法是先建立隔离表或异常标记，将受影响批次保留，再确认主记录选择规则。清洗规则应有明确依据，例如优先保留版本最高、采集时间最新且字段校验通过的记录，而不是简单保留自增 ID 最大的一行。

四、专业判断逻辑：用六个问题定位根因

1. 第一个问题：任务周期是否小于真实执行耗时

不要只看平均耗时。平均值会掩盖高峰期的尾部延迟，应该至少观察 P95 和 P99。一个任务平均耗时 6 分钟、P99 耗时 18 分钟，而调度周期是 10 分钟，系统在大多数时候看似正常，但每次出现慢任务都可能制造重叠。

可以用一个简单的风险判断：

重叠风险 = 任务运行时长的高分位值 ÷ 调度周期
当 P95 / 调度周期 < 0.8：

通常有较充足缓冲，但仍需观察异常重试。

当 P95 / 调度周期 ≥ 1：

应视为存在常态化重叠风险。

当 P99 / 调度周期 ≥ 2：

需要重点排查三轮任务同时运行的可能性。

这个公式不是严格的概率模型，而是排障优先级工具。它的作用是帮助开发人员先判断是否值得查任务重叠，而不是用一个平均耗时数字过早下结论。

2. 第二个问题：是否存在多个调度器副本

在容器化部署中，最容易被忽略的情况是：应用扩容了 3 个副本，每个副本都启动了同一个定时任务。开发人员以为只有一份任务，实际上每 10 分钟有 3 个实例同时抓取相同店铺。

排查时应检查容器启动日志、进程列表、worker_id 和节点分布。如果同一个 task_id 在相同计划时间出现多个不同 worker_id，且没有分片设计，优先怀疑调度器重复启动。

任务调度与任务执行最好分离。调度器只负责生成一个明确的任务事件，执行器通过队列领取任务；如果必须在应用进程内运行定时器，也要确保只有一个受控实例负责触发。

3. 第三个问题：重复是整批发生，还是单条发生

整批重复通常指向任务重跑、调度器重复启动或批量接口重试。单条重复更可能来自某些商品的网络超时、字段校验失败后的局部重试，或者分页游标处理错误。

可以按 batch_id、run_id 和业务键统计重复分布。如果某个 run_id 贡献了大部分重复记录，说明问题偏向任务级；如果多个 run_id 都只在少量 SKU 上重复，说明应重点查看单条重试和数据解析流程。

SELECT
shop_id,

product_id,

sku_id,

COUNT(*) AS record_count,

MIN(collected_at) AS first_collected_at,

MAX(collected_at) AS last_collected_at

FROM product_snapshot

GROUP BY shop_id, product_id, sku_id

HAVING COUNT(*) > 1

ORDER BY record_count DESC;

这条查询适用于历史快照表的初步统计。若表本身就允许同一 SKU 在不同时间存在多条记录，还需要把时间窗口、批次号或版本条件纳入判断，不能看到 COUNT 大于 1 就全部认定为脏数据。

4. 第四个问题：数据库写入是否具备幂等条件

应用层常见的“先查询、再插入”并不能保证幂等。两个任务同时查询，可能都发现数据库中不存在这条记录，然后同时插入。即使代码逻辑看起来正确，也会在并发条件下产生重复。

更可靠的做法是由数据库唯一约束提供最后一道防线，再配合 INSERT … ON CONFLICT、MERGE 或等价的 Upsert 语义。数据库约束不能替代业务判断，但它能把并发竞争从“静默制造重复”变成“可观察的冲突”。

CREATE UNIQUE INDEX uq_product_current
ON product_current (shop_id, product_id, sku_id);

INSERT INTO product_current (

shop_id,

product_id,

sku_id,

price,

stock,

source_time,

batch_id,

version

)

VALUES (

:shop_id,

:product_id,

:sku_id,

:price,

:stock,

:source_time,

:batch_id,

:version

)

ON CONFLICT (shop_id, product_id, sku_id)

DO UPDATE SET

price = EXCLUDED.price,

stock = EXCLUDED.stock,

source_time = EXCLUDED.source_time,

batch_id = EXCLUDED.batch_id,

version = EXCLUDED.version

WHERE product_current.version < EXCLUDED.version;

示例中的版本字段必须具有业务含义，不能简单使用数据库写入时间。若多个采集器的版本号无法统一，应使用可比较的批次序列、源站事件时间或由调度器生成的单调递增版本。

5. 第五个问题：旧数据是否可能晚于新数据提交

这是并发抓取系统中最容易被漏掉的一步。开发人员常常认为后启动的任务一定后完成，实际上网络延迟、页面响应、分页数量和重试都会改变完成顺序。

建议对每条写入记录至少保留 source_time、collected_at、received_at、updated_at 和 batch_id。发生覆盖时，按照这些字段重建时间线，而不是只看数据库当前值。

更新条件可以表达为“只有新版本才能覆盖旧版本”。例如，若 incoming_version 小于 current_version，则拒绝更新并记录 stale_write_count。这个指标非常有价值，因为它能把过去悄悄发生的数据回退变成可监控事件。

6. 第六个问题：采集、清洗和业务写入是否耦合过紧

如果解析器直接更新核心业务表，任何一次字段识别失败都可能覆盖原有正确值。比如价格字段解析失败后返回空值，更新语句仍然执行，最终把 89 元覆盖成空值或 0 元。

更安全的结构是先把原始响应保存到原始层，再进行标准化，最后更新当前状态表。这样即使标准化规则需要回滚，也可以从原始数据重新处理，而不必再次请求源站。

五、具体排查：从日志、数据库到代码逐层验证

1. 先补齐一组真正有用的日志字段

很多系统的日志只有“开始抓取”和“任务成功”，这对定位并发故障几乎没有帮助。日志至少要让人回答四个问题：谁执行的、执行哪一批、处理了多少、最终写入了什么。

日志字段不需要全部写入一行超长文本。建议将任务级日志、批次级日志和业务键级日志分开：任务级日志描述运行状态，批次级日志描述数量和耗时，业务键级日志只在失败、冲突或异常变化时记录，避免日志量失控。

2. 用数据库查询确认重复数据的形态

第一步统计重复键，第二步确认重复记录是否来自同一批次，第三步判断这些记录的字段是否完全相同。如果完全相同，优先怀疑重试或任务重复执行；如果字段不同，优先检查采集时间、版本和分步更新。

SELECT
shop_id,

product_id,

sku_id,

batch_id,

COUNT(*) AS batch_records,

MIN(received_at) AS first_received_at,

MAX(received_at) AS last_received_at

FROM product_snapshot

WHERE received_at >= :start_time

AND received_at < :end_time

GROUP BY shop_id, product_id, sku_id, batch_id

HAVING COUNT(*) > 1

ORDER BY batch_records DESC;

如果重复集中在同一个 batch_id，问题更接近批内重复；如果同一个业务键跨多个 batch_id 重复，则要区分历史快照是否本来就允许多版本。如果当前状态表出现多个 batch_id，则通常是唯一键或写入模型不完整。

3. 检查字段是否来自不同批次

可以在当前状态表暂时增加字段来源标记，例如 price_batch_id、stock_batch_id 和 title_batch_id。正式系统不一定要永久保留这些字段，但在排障期间非常有用。

SELECT
product_id,

title_batch_id,

price_batch_id,

stock_batch_id,

updated_at

FROM product_current

WHERE product_id = :product_id;

如果同一商品的三个核心字段来自不同批次，说明系统采用了分字段独立更新，或者多个任务并发修改同一行。此时仅仅清理重复记录没有意义，必须重新审视写入粒度：是以完整快照替换，还是允许字段级更新。

4. 检查任务是否重叠的 SQL 思路

任务表至少应记录 start_time、end_time 和 run_id。把每一次运行看成一个时间区间，就能判断任意两次执行是否相交。下列查询展示的是通用思路，具体语法需要根据数据库类型调整。

SELECT
a.run_id AS first_run,
b.run_id AS second_run,
a.start_time AS first_start,
a.end_time AS first_end,
b.start_time AS second_start,
b.end_time AS second_end
FROM task_run a
JOIN task_run b
ON a.task_id = b.task_id
AND a.run_id = :start_time
AND b.start_time

区间相交只说明存在并发，不代表一定造成了错误。还要继续确认两次运行是否处理了同一店铺、同一 SKU 或同一分页范围。如果任务按店铺分片，重叠可能是安全的；如果所有任务都处理全量数据，风险则明显更高。

六、写入设计：幂等、唯一键和版本控制如何配合

1. 先区分三种常见数据表

当前状态表表达“现在是什么状态”。同一个店铺、商品和 SKU 通常只保留一条有效记录，适合查询当前价格和库存。

历史快照表表达“过去某个时间是什么状态”。同一 SKU 在不同采集时间出现多条记录是正常的，重点是快照时间和批次不能混乱。

原始采集表表达“系统当时收到过什么”。它可以保存原始响应、抓取时间、请求标识和解析版本，主要用于复核、回放和规则变更后的重新处理。

2. 幂等键要描述业务动作，而不是随便生成随机数

如果每次重试都重新生成 UUID，数据库无法知道两次请求是否属于同一业务动作。稳定的幂等键应该在第一次请求生成，并在重试、消息重投和任务恢复时保持不变。

对于当前状态写入，可以使用 shop_id、product_id、sku_id 作为业务实体键，再由 version 控制更新顺序。对于历史快照，可以使用业务键加采集批次或源事件时间。对于原始响应，则可以使用请求参数摘要、页面标识和采集批次生成请求级唯一标识。

不要把当前时间直接拼进幂等键。这样每次重试都会得到不同键，等于主动放弃幂等。也不要把所有解析字段都拼入键，因为价格变化会让同一业务实体被当成全新实体。

3. 版本控制比单纯 updated_at 更可靠

updated_at 只能表示某次数据库操作发生的时间，不能说明数据版本。一个旧批次晚到并提交时，updated_at 反而会变得更新，因此它无法阻止旧数据覆盖新数据。

版本可以来自任务批次序列，也可以来自源数据时间，但必须保证比较规则稳定。更新时应明确拒绝低版本写入，并将拒绝事件写入日志。不要默默丢弃 stale write，否则下次故障仍然无法判断系统是否持续收到旧数据。

UPDATE product_current
SET
price = :price,
stock = :stock,
source_time = :source_time,
batch_id = :batch_id,
version = :version
WHERE shop_id = :shop_id
AND product_id = :product_id
AND sku_id = :sku_id
AND version

如果更新影响行数为 0，不应直接认为 SQL 失败。它可能表示当前记录版本更高，也可能表示业务键不存在。应用需要进一步查询并记录 rejected_as_stale、not_found 或 validation_failed 等具体原因。

4. 完整快照写入和字段级更新各有边界

完整快照写入的优点是字段来源一致，适合标题、价格、库存等应当属于同一采集时点的数据。缺点是某个字段解析失败时，不能贸然用空值覆盖旧状态，需要设置字段级校验和保留策略。

字段级更新适合不同来源、不同刷新频率的数据，例如库存每 2 分钟更新，商品描述每天更新。但它要求每个字段拥有独立的来源时间和版本，否则不同批次混合会被误认为是正常状态。

七、不同场景下的行动建议

1. 如果数据库突然出现大量重复记录

第一步暂停或降频高风险任务，避免异常规模继续扩大。第二步保留原始表、任务日志和异常时间窗口。第三步统计重复记录按 run_id、batch_id、worker_id 的分布，判断是整批重复还是局部重试。

1. 冻结受影响时间段的自动清洗和删除操作。
2. 统计重复业务键、重复批次和重复来源。
3. 确认重复记录是否已同步到报表、库存或告警系统。
4. 补充唯一约束前，先评估历史重复数据对上线变更的影响。
5. 修复写入幂等后，再进行小批量回放验证。

如果当前表没有唯一约束，不建议直接在生产环境添加约束。应先用临时表或离线脚本统计冲突，确定保留规则，再清理历史数据，最后添加约束防止问题复发。

2. 如果主要表现为新价格被旧价格覆盖

重点查版本和时间线，不要先查重复数据。选择几个已知异常 SKU，列出所有相关任务实例、源数据时间、写入时间和版本号，再按事件顺序排序。

如果发现旧采集批次晚写入，优先增加版本条件和 stale write 监控。如果发现多个字段来自不同批次，说明更新粒度存在问题，应考虑完整快照写入，或为每个字段补充来源版本。

3. 如果只有促销活动期间出现问题

不要只把任务周期临时改长。需要同时分析数据量增长、响应耗时、重试次数、分页变化和目标接口的合规访问限制。降低请求频率、采用允许的增量范围和控制并发，往往比盲目增加节点更稳妥。

促销期间可采用“高峰保护模式”：限制同一店铺的并发任务数，扩大超时后的退避间隔，暂缓低优先级字段采集，并将价格和库存等关键字段与商品描述分开调度。

4. 如果系统部署在多个节点或多个容器中

先确认调度器是否只运行一份。如果每个副本都启动定时器，应将调度器独立部署，或通过可靠的分布式协调机制确保单一触发源。

如果业务确实需要并发采集，应按店铺、商品区间或分页范围分片，并把分片标识纳入任务参数和幂等键。不能只依靠“每个节点自己抢任务”，否则发生节点重启或消息重投时很难判断任务边界。

5. 如果数据库中只有少量异常记录

少量异常不代表可以忽略。它可能是系统在高峰、网络抖动或单个特殊商品上的边界行为。建议保留异常样本，增加针对性监控，而不是立即投入大型架构改造。

对于低频、低价值字段，可以接受一定比例的延迟重试；对于价格、库存和订单相关数据，则应设置更严格的版本和完整性规则。治理力度应与业务损失匹配。

6. 如果需要支持历史价格和当前状态同时查询

不要让一张表同时承担当前状态和历史审计两个目标。建议原始层保存采集证据，快照层保存每次有效采集结果，当前状态表只保留通过版本和质量校验的最新状态。

这样的分层会增加存储量和数据处理流程，但能显著降低误删历史、错误覆盖当前值和无法回放的风险。对于有价格趋势、库存变化或活动复盘需求的系统，额外存储通常比反复人工修复更便宜。

八、不同方案的取舍：不要用复杂架构掩盖基础缺陷

1. 单实例串行执行与分布式并发执行

单实例串行执行最容易保证顺序，适合数据量有限、任务频率不高且对实时性要求一般的系统。它的缺点是吞吐有限，单节点故障可能影响整批任务。

分布式并发执行可以提高吞吐和故障恢复能力，但需要处理任务分片、幂等、节点重复领取、消息重投和版本乱序。如果唯一键和版本控制还没有建立，扩容往往只是把错误写入速度提高。

2. 任务锁与队列调度

任务锁适合解决“同一任务不允许同时运行”的问题，改造快，适合先止损。但它不适合高并发分片任务，也不能替代业务幂等。

队列调度适合把任务拆成可重试、可观测的工作单元。它可以限制消费者并发、隔离慢任务并支持失败重放，但引入了消息重复、消费确认和顺序控制等新问题。

我的建议是：如果当前问题只是一个全量任务发生重叠，先用调度器并发限制和任务状态表止损；如果任务规模已经需要分片处理，再引入队列，并同步建设幂等键、死信处理和版本控制。

3. 数据库 Upsert 与应用层去重

应用层去重容易理解，也便于加入复杂业务规则，但并发条件下可能发生竞态。数据库 Upsert 能利用唯一约束保证最终一致性，但复杂条件更新和跨表事务需要更谨慎地设计。

通常不应二选一。应用层负责校验业务字段和生成稳定幂等键，数据库负责用唯一约束和事务阻止并发写入破坏数据边界。两层共同存在，才能既表达业务规则，又提供最后防线。

九、长期治理：把一次故障变成可验证的系统能力

1. 建立任务状态机，而不是只保留成功和失败

建议至少区分 pending、running、success、partial_success、failed、retrying 和 canceled。partial_success 尤其重要，因为很多采集任务并不是全成或全败，而是部分店铺、部分分页或部分 SKU 失败。

状态机还应记录状态变更时间和原因。一个任务从 running 进入 retrying，不应只记录“网络异常”，还应记录失败范围、重试次数、退避时间和下一次计划。这样才能区分系统性故障与单个商品异常。

2. 给质量监控设置业务阈值

质量监控不要只设置“任务失败告警”。更有价值的监控包括单批数据量突增或突降、重复键数量、关键字段空值率、价格异常变化、版本回退次数和任务并发实例数。

3. 在写入前设置“拒绝更新”规则

对关键字段来说，写入前拒绝错误数据比写入后清洗更便宜。例如商品标识为空、价格超出合理范围、库存出现不可能的负值、版本号低于当前值时，可以拒绝覆盖当前状态，但把原始数据保留到异常表供复核。

这里要注意“拒绝更新”不等于“丢弃数据”。被拒绝的记录应带有 rejection_reason、batch_id 和 raw_record_id，便于判断是源数据变化、解析规则缺陷还是任务乱序。

4. 让修复具备回放能力

如果只有最终业务表，没有原始数据和批次边界，任何解析规则修复都必须重新访问数据源，既增加访问压力，也可能因为页面变化而无法还原历史状态。

保留原始数据需要考虑存储成本、保留周期、敏感信息脱敏和访问权限。可以只保留关键字段及响应摘要，也可以设置冷热分层。重要的是，系统应能够回答：“这条当前状态是由哪一次原始采集、经过哪个解析版本生成的？”

十、开发人员可直接执行的排查清单

1. 十分钟快速判断

如果线上刚出现存储混乱，不要马上重构。先用十分钟完成基本分流，确定问题属于任务重叠、重复重试、旧数据覆盖还是字段解析异常。

• 查看最近 24 小时任务的 P95、P99 耗时，是否超过调度周期。
• 按 task_id 和计划时间统计同一时刻的运行实例数。
• 检查重复业务键是否集中在同一个 run_id 或 batch_id。
• 抽取 3 至 5 个异常 SKU，比较 source_time、received_at 和 updated_at。
• 确认是否存在超时后自动重试，以及重试是否复用相同幂等键。
• 检查当前状态表是否有正确的业务唯一约束。
• 确认异常数据是否已经同步到下游报表、库存或告警系统。

2. 一小时深度排查

1. 导出异常时间窗口内全部 task_run 记录，重建任务区间。
2. 按 worker_id 查看是否存在多个节点重复触发相同任务。
3. 按业务键、批次号和版本号统计重复与回退分布。
4. 检查写入 SQL 是否包含版本条件、事务边界和唯一冲突处理。
5. 审查超时、异常和消息重投路径，确认是否可能重复提交。
6. 验证关键字段解析失败时是否会覆盖已有值。
7. 确定历史数据清洗规则，并先在副本或临时表中验证。

3. 上线前必须验证的场景

不要只测试正常运行。定时采集系统至少需要覆盖以下异常场景：任务执行超过一个周期、节点在写入前重启、数据库提交后应用超时、消息重复投递、旧批次晚于新批次完成、单个字段解析失败，以及同一任务在多个副本中同时启动。

每个场景都要验证两个结果：一是任务状态是否能准确反映情况，二是数据库最终状态是否符合幂等和版本规则。只验证“程序没有报错”远远不够。

十一、结语：先控制时间线，再谈采集规模

电商数据抓取系统的存储混乱，通常不是因为“抓得不够快”，而是因为系统没有准确表达一次任务、一个批次、一条业务事实和一个数据版本之间的关系。任务重叠会制造并发，重试会制造重复，缺少唯一键会放大重复，缺少版本条件又会让旧数据覆盖新数据。

我的判断顺序始终是：先看任务周期与高分位耗时，再看执行实例和批次边界，然后查重试与幂等，最后检查唯一键、版本控制和字段映射。这个顺序的价值在于，它能先用低成本证据排除高概率根因，避免一上来就引入复杂队列、分布式锁或大规模数据重构。

下一步可以直接做三件事：为任务补充 run_id、batch_id、worker_id、source_time 和 retry_count；为当前状态表建立经过业务确认的唯一约束；为更新语句增加版本条件，并监控 stale write。完成这三步后，系统未必立刻变得更快，但你会第一次真正知道数据为什么变化、哪一批数据出了问题，以及下一次异常应该在哪里被拦截。

真正可靠的采集系统，不是永远不失败，而是失败时不会悄悄污染存储，并且能够用日志、批次和版本把问题还原出来。

免费注册

咨询方案

扫码咨询方案