一、需求背景：折扣信息为什么要用系统来管

数字游戏商店的促销节奏呈现“高频次、短周期、多区域”的特点。同一款作品在不同区域商店、不同硬件版本上的价格与折扣力度可能完全不同；“新史低”“平史低”这类标签，往往是玩家判断“现在是否值得入手”的核心依据。然而这些信息分散在多个商店页面与社区帖子中，人工跟踪存在三个明显痛点：

1. 时效性差：促销往往限时限量，人工发现时可能已经结束；
2. 口径不一：不同信息渠道对“史低”的统计窗口、币种口径不一致，容易误判；
3. 存在价格操纵：部分商品会在促销前悄悄抬价，制造“大折扣”假象，没有历史价格数据支撑就难以识破。

因此，对开发者而言，构建一个自动化的“折扣监控与历史低价提醒系统”，既是典型的数据工程练手项目，也能沉淀出通用的价格采集、时序计算与消息推送能力。

二、核心概念与数据建模

2.1 需要采集哪些数据

一个可用的监控系统，通常围绕以下几类数据展开：

• 商品主数据：标题、所属平台档位、语言支持、支持人数、第三方媒体综合评分等；
• 价格数据：原价（划线价）、现价（成交价）、折扣率、币种与区域；
• 规格数据：不同硬件档位下的最高分辨率与帧率，例如入门档位可能只有 1080P/30FPS，而高配档位可以跑到 4K/60FPS，这类规格直接影响购买决策；
• 市场参考数据：如二手实体盘行情价，可作为数字版定价合理性的交叉参照。

2.2 关键指标定义

在写代码之前，先把口径定义清楚，避免“各说各话”：

• 历史最低价（史低）：观察窗口内出现过的最低成交价；
• 新史低：当前价格严格低于历史最低价；
• 平史低：当前价格等于历史最低价；
• 折扣率：折扣率 =（原价 − 现价）/ 原价 × 100%，注意与商店展示口径核对，防止四舍五入造成偏差。

2.3 最小数据模型

可以用三张核心表承载：

product        (id, title, platform_tier, language, player_count, media_score)
price_record   (id, product_id, captured_at, region, currency,
                list_price, paid_price, discount_rate, source)
alert_rule     (id, product_id, user_id, threshold_price,
                threshold_discount, channel, enabled)

price_record 按时间追加写入，天然形成价格时序曲线；alert_rule 表达用户的订阅意图，是提醒服务的核心。

三、系统架构：五个层次拆解

推荐采用“采集—计算—存储—服务—推送”的分层架构：

1. 采集层：由定时调度器驱动，按商品清单抓取商店接口或页面。要特别注意频控与合规，使用指数退避与随机抖动，避免对目标站点造成压力；
2. 计算层：负责价格清洗、多币种归一（统一按当日汇率折算，并保存汇率快照）、史低判定与异常检测；
3. 存储层：商品主数据与订阅规则放关系型数据库；价格记录按时间分表或采用时序化存储；抓取到的原始页面快照可归档到对象存储，便于回溯与审计；
4. 服务层：对外提供商品详情、价格曲线、订阅管理三类接口；
5. 推送层：通过消息队列削峰填谷，再由消费者分发到站内信、邮件、Webhook 等通道。

四、关键算法与示意代码

4.1 史低判定

核心逻辑非常简洁：

function judge(product, current):
    history = load_price_history(product.id)
    lowest  = argmin(history, key = paid_price)
    if current.paid_price < lowest.paid_price:
        tag = "NEW_LOW"            # 新史低
    else if current.paid_price == lowest.paid_price:
        tag = "TIE_LOW"            # 平史低
    else:
        tag = "NORMAL"
    if tag in ("NEW_LOW", "TIE_LOW"):
        key = idempotency_key(product.id, current.paid_price, tag)
        if not exists(key):        # 幂等去重，防止重复轰炸
            put_message(alert_queue, build_alert(product, current, tag))
    return tag

两点工程细节值得强调：

• 幂等去重：以“商品 + 价格 + 标签”生成幂等键，同一轮促销只提醒一次；
• 噪声控制：极小幅度的价格波动（例如汇率浮动导致的几分钱差异）应设置容差阈值，避免产生“伪史低”。

4.2 “先涨后降”识别

伪折扣的典型手法是促销前抬价。可以用一个简单规则做初筛：

baseline = average(paid_price of last 30 days before promo)
if list_price_during_promo > baseline * 1.1:
    mark(product, "SUSPECTED_FAKE_DISCOUNT")

被标记的商品在推送文案中附带“近 30 天价格曲线”，让用户自行判断，比直接下结论更稳妥。

4.3 异常值防护

采集到的数据必须过一遍校验：现价为零或负数、折扣率超过 100%、原价与现价相等却标注高额折扣等，都应进入待人工复核队列，而不是直接入库。

五、工程实践与稳定性保障

• 可观测性：对采集成功率、抓取时延、队列积压深度设置监控告警，异常时先于用户发现问题；
• 弹性伸缩：大型促销季（如年末活动）任务量可能是平日的数倍，采集与计算服务建议容器化部署，按队列积压指标自动扩缩容；
• 日志治理：抓取失败原因多样（超时、频控、页面改版），建议将日志接入集中式日志服务，按错误码聚合分析；
• 灰度与回滚：判定规则（如史低容差、折扣口径）调整时先灰度一小批商品，确认无误再全量；
• 云上落地：这类系统无需自建机房，基于通用云产品组合即可快速搭建——对象存储存放页面快照、消息队列解耦推送、日志服务集中检索、监控告警保障稳定性。以百度智能云为例，其提供的上述通用产品能力，配合容器平台部署采集与计算服务，可以显著降低运维负担，让开发者更专注于判定算法与用户体验本身。

六、扩展方向

当基础链路跑通后，还有不少值得延伸的方向：

1. 心愿单订阅：用户对特定商品设定目标价，触达方式从“广播式促销播报”升级为“个性化精准提醒”；
2. 值得买指数：将媒体评分、折扣深度、史低距离（现价与史低的差距）加权打分，帮助用户快速筛选；
3. 多源比价：引入二手实体盘行情等市场数据，形成数字版与实体版的交叉参照；
4. 可视化开放：提供价格曲线图表与开放接口，让社区生态基于数据做二次创作。

七、小结

从“新史低 29、折扣 85%”这样的原始促销信息，到一套自动化、可信赖的折扣监控系统，本质上是把“人工看页面”翻译成“数据管道 + 判定算法 + 通知链路”的工程问题。先把指标口径定义严谨，再以分层架构保证可扩展性，最后用监控告警与幂等去重守住稳定性，一个个人项目级别的比价提醒服务即可水到渠成。对于希望快速落地的团队，合理复用云上的对象存储、消息队列、日志服务等通用能力，能把更多精力留给真正产生差异化的算法与产品体验上。