优惠券失效与价格变动实时感知：定时轮询与增量更新混合策略

我先说明一下这次的情况。

用户提供的项目标题是"优惠券失效与价格变动的实时感知机制：基于定时轮询与增量更新的混合策略"，项目正文、关键词、摘要描述均为空，只给了热搜词"定时轮询、增量更新、实时感知机制"。所以我围绕标题本身和这三组热搜词展开，把它写成一篇偏技术架构方向的实战分享型博文，模拟一位后端开发者在电商优惠券/价格感知场景下的设计与踩坑复盘。章节名称按标题特性独立设计，不套模板。

下面直接输出文章正文。

1. 为什么优惠券失效和价格变动需要"实时感知"

先说一个几乎所有做过电商或交易系统的人都会遇到的场景：用户在商品详情页看到"领券减30"的提示，加入购物车，填完地址准备付款，结果结算页弹出一行小字——"您使用的优惠券已失效"。有时候更隐蔽，优惠券明明没过期，但是商品本身的到手价变了，用户没有重新进入商品页，看到的还是旧价格，等真正下单时才发现对不上。

这种问题在技术侧看起来不复杂，就是"数据变了，客户端不知道"。但在实际业务里，它牵扯的不只是用户体验，还有一堆隐性的连锁反应：客诉量上升、订单取消率变高、优惠券核销率失真，甚至运营做活动复盘时发现券的核销数据跟实际订单对不上，搞不清到底是用户不用券还是券根本用不出去。

"实时感知"这四个字，听起来像是个很简单的要求，但真正落地的时候会发现，它卡在两个绕不开的现实条件上。

第一，业务数据的变化源非常分散。优惠券可能会有失效状态变更（被用户手动退回、被风控判废、过期自动失效、被运营后台批量作废），价格变动更是复杂——秒杀价、限时折扣、会员价、地区差异价、优惠叠加规则调整，任何一个配置变动都会影响用户最终看到的到手价。这不是一张表的数据变化，是多个服务、多个配置源之间的联动变化。

第二，客户端和服务端之间没有常驻的、稳定的双向通道。App、H5、小程序，它们的网络环境差异很大，服务端没法随时向所有在线用户主动推送一条"你正在看的商品降价了"的消息——即便有长连接，也不可能靠推送解决所有场景。

所以，绝大多数团队最终落地的方案，不是单一的推送，也不是纯粹的轮询，而是定时轮询与增量更新的混合策略。我在这篇文章里把这个思路掰开揉碎讲清楚，包括服务端怎么设计变更记录、客户端怎么合并数据、轮询间隔怎么定、增量数据丢失了怎么办，以及在真实业务中踩过哪些坑。

这个内容适合谁看？如果你正在做一个带有"数据状态敏感"属性的业务——优惠券、预售商品、票务库存、行情报价——并且被"数据实时性做不到、性能又扛不住"这个问题卡住过，这篇文章应该能给你一个可以直接参考的框架。

2. 纯轮询和纯推送都不够：先拆解两种朴素方案的死穴

在给出混合策略之前，有必要先把两种"看起来能解决问题"的朴素方案讲透。很多团队一开始都会在这两个方案里二选一，然后被现实教育一顿。

2.1 定时轮询的问题不在"定时"，而在"全量"

定时轮询是入门成本最低的方案。客户端每隔一段时间，把当前页面涉及的数据全部拉一遍，把服务端返回的最新结果覆盖到本地。优惠券列表变了？拉一遍。商品价格变了？拉一遍。库存变了？再拉一遍。逻辑上没有难点，服务端也不用做什么复杂设计。

但方案一旦到了真实流量下，问题立刻暴露。

假设一个中大型电商平台，日活用户200万，其中50万用户同时停留在某个商品页或优惠券列表页。如果每个用户每30秒轮询一次，服务端平均每秒要处理的请求量大约是50万除以30，约1.67万QPS。这还只是"页面停留"产生的轮询量，没算用户主动下拉刷新、切Tab、进入结算页等行为。而每次轮询如果都返回全量数据——比如一个用户的可用券列表有几十条，每条包含券ID、金额、门槛、品类限制、有效期等多字段——那单次响应体轻松到几十KB甚至上百KB。算下来，这个模块一天光轮询产生的出网流量就是T级别起步。

更要命的是，全量轮询在"数据没变"的时候依然在消耗资源。业务低谷期，99%的轮询返回的都是"无变化"，但服务端还是跑了相同的查询逻辑、做了相同的序列化、送出了相同体积的包。我见过有团队这方案上线后，优惠券服务高峰期CPU直接冲到90%，连正常的领券请求都被拖慢了，最后不得不把轮询间隔从30秒改到5分钟——用户体验立刻恶化，用户明明领了券，过了几分钟去看券还在，再刷新又没了，客服都疯了。

所以，定时轮询的问题本质上不是"定时"这个动作有问题，而是"全量拉取"这个设计在数据规模大、状态变化稀疏的场景下，性价比极低。

2.2 增量更新的优势在于"只传变化"，但它必须有兜底

增量更新的思路是：服务端只在数据发生变化时，告诉客户端"哪条数据变了、变成了什么"，客户端只更新这一条，不重拉整个列表。

这个方向是对的，但增量更新单独拿出来用，也会遇到一个很现实的问题——客户端怎么知道"从哪个时间点开始的数据变化"？

比如用户在App上停留了40分钟，前30分钟收到的增量消息都正常处理了，第31分钟网络切了一下，中间的几条增量消息丢了、没收到。那客户端本地缓存里的数据，从第30分钟之后就跟服务端不一致了。这种不一致如果不修复，用户会看到一张已经失效的券仍然显示"可用"，或者一个已经涨价的商品仍然显示"到手价199"。

增量更新的另一个尴尬点是：第一次进入页面的用户、清过缓存的用户、换了设备的用户，本地没有任何数据基础，你给他推增量，他也不知道往哪儿合并。必须先有一次全量基础数据的拉取，之后才能在这个基础上应用增量。

所以，纯增量方案稳定性的前提，是"客户端和服务端之间绝对不能丢消息"。但在移动互联网的现实网络环境下，这几乎是不可能的。只要有丢增量，就必然要有一种机制来做对账、修复、收敛。

2.3 混合策略的本质：用全量兜底，用增量提效

现在把两个方案放在一起看，就很容易理解为什么业界普遍采用混合策略了。

定时轮询的可靠之处在于"全量对比，错了也能纠正过来"，但它笨重、昂贵；增量更新的高效之处在于"只传