1. 项目要解决的核心问题与整体设计思路1.1 支付渠道监控到底在监控什么做支付系统的同学应该都有过这种经历凌晨两点被告警电话叫醒说某某渠道成功率跌到 70% 了打开后台一看数据又恢复了留下一个查无实据的告警记录。这种事情多来几次值班同学就会对告警产生免疫力真出问题的时候反而没人理。我这次做的支付渠道实时成功率统计就是冲着这个痛点去的。支付渠道成功率监控说白了就是回答三个问题当前这个渠道比如某支付机构通道、某银行通道在过去一个时间窗口内成功了多少笔、失败了多少笔、成功率是多少。看起来简单真正落地的时候会发现有几个地方特别容易扯皮第一成功率的口径怎么定。用户发起支付到回调通知到达中间隔着支付机构、银行、网络好几跳。用户那边显示支付失败但渠道回调还没到这笔算成功还是失败如果按最终结果算统计天然会延迟如果按当下已知结果算又可能出现先记为失败、后回调成功导致数据修正的情况。这个口径不定清楚后续所有统计都是糊涂账。第二窗口怎么滑。传统做法是每分钟一个计数器然后聚合最近 5 分钟的桶。这个方案实现简单但每到整分钟边界数据会出现一个毛刺比如 10:00:59 的记录归入 10:00 这个桶下一秒就归入 10:01而监控看的是 09:56~10:00 这五分钟正好看不到 10:01 刚发生的暴跌。要做到真正的滑动窗口就必须让每一条记录带着精确时间戳而不是落到某个固定桶里。第三查得快、存得省。支付系统 QPS 高的时候核心收单链路每秒几十上百笔很正常统计模块不能拖累主流程也不能无限吃内存。如果每笔支付都落到数据库再离线聚合实时性就没了如果全部放内存里裸算数据量一大就扛不住。我这次的项目就是基于 Redis 的有序集合ZSet来做一套轻量级的实时成功率统计。核心思路每个支付渠道两个 key一个存成功记录、一个存失败记录member 用订单号或者渠道侧请求流水号score 用支付结果发生时间的时间戳。查询时用 ZCOUNT 在时间戳范围内计数成功数除以总数就是成功率。这套方案我在实际线上环境跑过单机 Redis 扛日均几百万条统计记录没有压力而且统计粒度能做到秒级。1.2 为什么最终选了 Redis ZSet先说一个很多同学会问的问题统计成功率和失败次数用 Redis 的 INCR 计数器不就行了吗每笔支付成功就INCR pay:success:{channel}失败就INCR pay:fail:{channel}简单粗暴。确实简单但这个方案只能做累计值或固定时间桶。比如你每分钟开一个新的 keypay:success:{channel}:202501131230然后查最近 5 分钟要把 5 个 key 捞出来加一遍。这个方案有两个先天缺陷一是每分钟一个 key 会产生大量 key 堆积二是时间桶边缘的统计不精确刚才说的毛刺问题根本躲不掉。那用 List 行不行每笔记录 LPUSH 进去查询时 LRANGE 拉出来数也行。但 LREM、LRANGE 都是 O(N) 操作窗口内如果积累了几万条记录每次查询都要遍历一遍响应速度完全不可控。更要命的是List 不支持按时间范围跳过过期数据你得自己写逻辑去清理头部稍微一个疏忽就内存爆炸。Hash 就不用提了field 没法按时间排序做不了范围统计。ZSet 为什么合适看四个点score 天生就是时间戳。ZADD 的时候把时间戳塞进 score数据就自动按时间排好序了。查询窗口内的记录一条ZCOUNT key min max搞定时间复杂度 O(log N)N 是 key 里的记录数。这是 ZSet 最核心的、其他结构很难替代的能力。member 天然去重。支付结果回调可能重复推送渠道侧网络重试、我们自己的 MQ 重投都可能导致同一条结果被处理两次如果 member 用订单号重复上报在 ZSet 里就是幂等的score 更新一下就行不会造成重复计数。窗口清理是端到端操作。ZREMRANGEBYSCORE key -inf cutoff可以一次性删掉窗口之前的全部过期记录同样是 O(log N M) 的复杂度比 List 清理头部优雅太多。内存可控。member 是字符串订单号一般几十个字节score 是 16 字节的 double。单条记录的内存开销在百字节以内就算一个窗口积累几十万条也就是几十 MB 级别对于 Redis 来说完全在可接受范围内。当时我也考虑过用 Lua 脚本把写入记录 过期清理 统计计数在一个原子操作里做掉但实践证明把写操作和读统计拆开更加灵活写入链路只负责 ZADD延迟极低统计任务走独立逻辑可以定时跑也可以被告警系统拉取。如果强行合成一个原子脚本反而会把写链路的耗时拉长得不偿失。1.3 数据流全景与关键决策点先把整体数据流画在脑子里支付结果从渠道回调进来经过订单服务确认状态然后生产一条支付结果事件包含订单号、渠道ID、成功/失败、结果时间戳投递到消息队列。下游有一个统计消费程序订阅这个事件解析出渠道ID和结果往对应的 ZSet key 里 ZADD。监控系统定时比如每 30 秒对每个渠道执行 ZCOUNT 查询算成功率如果低于阈值就触发告警更进一步可以联动路由系统把流量切到备用渠道这就是后话了。这个流程里有三个决策点我现在回头看都是影响全局的关键渠道维度的粒度问题。我当时做过一版全局成功率就是把所有渠道的成功和失败都塞到同一个 key 里结果某银行通道波动的时候因为总基数大成功率从 99.9% 跌到 99.5% 根本看不出异常错过了几分钟的黄金处置时间。后来改成按渠道拆 key单个渠道的失败样本占比小、波动放大明显问题当场就暴露了。如果你的支付渠道下面还分具体的银行通道或子商户建议按渠道ID 子通道ID拆分粒度越细越容易定位问题。时间戳用哪个。支付结果事件里可能有好几个时间戳用户发起支付时间、渠道回调时间、我们服务处理时间。我最后选的是渠道回调时间也就是支付结果在渠道侧真正产生的时间。为什么不用我们自己的处理时间因为 MQ 消费有延迟高峰期可能积压几十秒用处理时间会导致统计窗口整体往后漂移明明 10:00 发生的一批失败到 10:01 才进入统计告警就慢了一拍。回调时间虽然是上游传过来的可能偶发不准但整体最接近真实发生时间。成功率公式的分母。这个细节我纠结了很久。分子是窗口内成功数分母应该是什么是窗口内成功失败的总数还是包含未知状态的订单如果有些订单用户发起后一直没结果比如 pending分母只算成功失败会高估成功率因为把还没结果的订单排除在外了。但反过来如果把 pending 也放进分母一个渠道突然大量请求卡住不回调成功率会被拉低反而掩盖了渠道卡单这个事实。我最终采用了双口径主告警用成功/(成功失败)辅查看用成功/(成功失败未知)两套数字都展示在监控面板上处理问题时参考后者更全面。2. 数据结构设计与写入链路2.1 ZSet 的 key、member、score 怎么设计这是整套方案的骨架设计得不好后面处处别扭。key 的命名规范。我采用的是pay:result:{channel}:{status}其中{status}是success或fail。比如某支付通道代号alipay_online那么成功记录存在pay:result:alipay_online:success失败记录存在pay:result:alipay_online:fail。拆成两个 key 而不是一个 key 里用不同 score 区段区分成功失败好处是查询简单——ZCOUNT只需要按时间范围数不需要额外过滤逻辑坏处是统计总数时要查两次成功一次、失败一次对 Redis 来说是两次 O(log N) 操作毫秒级完全可接受。为什么不把成功/失败作为 score 的小数部分比如成功的时间戳是1736745600.0失败是1736745600.1省一个 key 但搞乱了时间排序并且分数范围查询会变得极其恶心要排除小数位我劝你千万别这么干。member 用什么。这个我在线上踩过坑。一开始直接拿订单号全局唯一字符串当 member看起来没问题。但后来发现支付结果事件里同一个订单号最多可能被上报三四次渠道重推、MQ 重投、人工补单ZADD 更新 member 的 score 倒是不重复计数这本是好事可它引入了另一个问题如果同一订单先上报失败、后上报成功ZSet 里会出现该 member 同时存在于 fail 和 success 两个 key 的情况。成功率统计会把这个订单既算成功又算失败。解决办法是在写入前做一次状态机校验订单最终状态以订单服务的持久化数据为准统计这边无论先收到哪个状态都按当前最终状态来 ZADD。具体做法是消费到结果事件后先请求一次订单服务查最终状态或者读本地缓存的订单状态确认后再写入对应的 ZSet key。如果发现同一 member 已存在于相反的 key要先发一条 ZREM 删掉旧记录再写入新记录。这个逻辑必须保证原子性我用了一段 Lua 脚本-- KEYS[1]: success key, KEYS[2]: fail key, KEYS[3]: member -- ARGV[1]: score (timestamp), ARGV[2]: final status (success or fail) local targetKey if ARGV[2] success then targetKey KEYS[1] else targetKey KEYS[2] end -- 如果member在相反方向的key里存在先移除 for i 1, 2 do if KEYS[i] ~ targetKey then local existed redis.call(ZREM, KEYS[i], KEYS[3]) -- 返回值可用于统计修正 end end return redis.call(ZADD, targetKey, ARGV[1], KEYS[3])score 的精度问题。这里有一个必须提醒的细节Redis 的 score 虽然是 double但规范要求不要依赖浮点数的精确表示。时间戳我直接用秒级整数10 位完全够用。为什么不用毫秒毫秒时间戳是 13 位作为 double 存储时精度会损失double 的整数精确表示范围大约到 2^5313 位远没超理论上是安全的但秒级整数在打印、调试、跨系统传输时都更友好。如果你的业务确实需要毫秒级排序也可以存 13 位整数实测 ZADD 和 ZCOUNT 都没有精度问题但统计的窗口边界就会精确到毫秒这会导致窗口内数量计算出现微小的边界不一致。我的建议秒级足够。2.2 上报链路中的几个细节坑数据上报链路是统计准确性的源头。这里大概有四个坑每一个都能让成功率统计看起来正确、用起来坑人。消费延迟导致的时间戳失真。上面提到了用渠道回调时间而不是消费处理时间作为 score。但还有一个隐藏问题如果 MQ 积压严重比如消费程序挂了十分钟积压的旧事件会一次性涌入导致统计窗口瞬间被历史数据灌满成功率会被旧数据稀释。我当时的做法是消费程序启动后先暂停统计写入 30 秒让积压事件先消费完同时在写入逻辑里加了一个时间戳新鲜度检查如果事件里的回调时间距离当前时间超过 10 分钟直接走旁路写入一个延迟事件计数而不是正常写入 ZSet。这样统计窗口内的时间分布永远是基本实时的不会被历史补数据污染。重复上报的处理。不只在 member 去重那一步还要在消费侧做幂等。我见过同学用 Redis SETNX 做消费幂等key 设为渠道回调流水号对每笔回调只处理一次这个思路可行但额外增加一次 Redis 交互。由于 ZSet 的 member 本身天然幂等我在实际设计里省掉了这一步代价就是上面那个先失败后成功的状态修正场景需要 Lua 脚本来兜底。如果你的渠道回调确实存在极端重复场景同一笔支付回调几十次建议还是加一道幂等过滤防止 ZADD 次数过多。状态字段的解析容错。渠道回调报文里的状态字段五花八门有的返回SUCCESS有的返回TRADE_SUCCESS有的返回0表示成功还有PROCESSING、UNKNOWN等灰色状态。如果解析逻辑直接把所有非SUCCESS的状态全部归为失败会把大量用户主动取消超时未支付但渠道侧后来才回调成功的订单算成支付失败成功率直接被打到 80% 以下。我的做法是维护一张状态映射表明确哪些状态计入 fail哪些虽然非成功但也不计入 fail比如取消、关单、未知这个映射表要跟业务方对齐而不是自己拍脑袋。我摘一个简化的映射示例渠道状态统计归类说明SUCCESSsuccess明确成功TRADE_SUCCESSsuccess明确成功TRADE_CLOSED不计入用户主动关单不属于渠道失败PAY_FAILfail明确支付失败SYSTEM_ERRORfail渠道内部错误PROCESSING不计入等待最终结果不计入分母UNKNOWN不计入未知状态观察但不计入实时告警这个表在代码里就是MapString, StatStatus但别看它简单一旦渠道调整了返回码这里最容易出问题。我上线后遇到过渠道方静默增加了一个新状态码解析逻辑没有覆盖默认走了 fail导致一周内该渠道成功率异常偏低排查了很久才在日志里看到大量未识别状态码。你在落地时一定要对未识别状态码打点告警别默默吞掉。2.3 状态映射与成功率口径关于口径我再说深一层。所谓成功率口径本质上是数学公式里分母和分子的语义。实时告警和事后统计最好用两套口径因为它们的业务目标不同。实时告警的口径要敏感。假设某个渠道 95% 的成功率是正常水平我要做的是发现成功率突然掉到 80%。这时候如果把 pending、取消、关单全部加入分母不仅延迟了异常感知因为这些状态要等超时才能确认还可能因为用户取消行为的波动产生误报。所以实时告警用success / (success fail)只关注有明确结果的订单在成功和失败中的构成比例。这个比例对渠道侧故障是最敏感的——只要渠道开始大量拒绝交易分母里 fail 的占比立刻上升。事后统计的口径要全面。比如周报、月报里的渠道质量分析要用success / 全部支付请求包含取消、pending、未知等所有状态。因为这时候我想回答的问题是这个渠道上用户支付的整体体验如何如果大量订单卡在 pending即便没有明确的失败,体验也是极差的应该在周报里体现出来。这个双口径的思路后来还被推广到了告警规则上实时告警用第一口径日终巡检报表用第二口径。两者数字不同但各有用途。你如果只做一个数字要么被瞬时误报轰炸要么对慢性恶化失明两边都堵不上。3. 查询与统计实现3.1 用 ZCOUNT 计算滑动窗口内的成功与失败核心查询就两条命令ZCOUNT pay:result:alipay_online:success (now-300) now ZCOUNT pay:result:alipay_online:fail (now-300) now成功率就是success / (success fail)乘以 100 就是百分比。ZCOUNT的复杂度是 O(log N)性能极好。这里的关键是窗口的对齐问题。如果我 14:00:00 调用一次窗口是 13:55:00~14:00:0014:00:30 再调用一次窗口是 13:55:30~14:00:30。这个窗口是实时滑动的没有桶的概念所以不会出现整点毛刺。这一点比用固定一分钟 key 聚合的方式要平滑得多也是我选择 ZSet 的核心理由。但在实际写代码时有个细节容易忽略窗口时间要用当前时间还是用 Redis 的 TIME 命令如果你的应用服务器时钟和 Redis 服务器时钟存在秒级偏差那么now取的是应用服务器时间写入 ZSet 的 score 是渠道回调时间两者不是同一个时钟源。如果偏差大于窗口宽度的十分之一统计结果就会有明显偏差。我在线上环境统一用 Redis 的TIME命令获取当前时间然后传给 ZCOUNT保证读写两侧时钟一致。这个改动一行代码但避免了大量莫名其妙的成功率滞后问题。查询结果的使用场景也要区分。监控面板上每 30 秒轮询一次每次查每个渠道两个 ZCOUNT渠道数量假设 20 个总共 40 次 ZCOUNT对 Redis 来说压力很小。但如果你的渠道数量上千那就要用管道pipeline或批量脚本一次算完不然网络往返次数太多。我当时的渠道数量在两三百级别用 pipeline 把全量渠道的 ZCOUNT 打包成一次往返Redis 端耗时不到 5 毫秒。这里有一个更高效的进阶做法如果你只是想知道某个渠道当前成功率是否低于阈值其实不用先查成功数和失败数再自己算可以用 Lua 脚本在 Redis 端直接算好返回布尔值local successKey KEYS[1] local failKey KEYS[2] local windowStart tonumber(ARGV[1]) local now tonumber(ARGV[2]) local threshold tonumber(ARGV[3]) local successCount redis.call(ZCOUNT, successKey, windowStart, now) local failCount redis.call(ZCOUNT, failKey, windowStart, now) local total successCount failCount if total 0 then return 0 end if successCount / total threshold then return 1 end return 0这样告警系统只需要扫一遍所有渠道的 key不需要把原始计数拉回应用层再算。注意上面的脚本对 Lua 返回值做了约定0 表示没有异常1 表示低于阈值。total 为 0 时窗口内没有交易返回 0不触发告警避免误报。3.2 定时清理与内存控制写入数据的另一半工作是让过期数据消失不然时间一长ZSet 会无限膨胀。设计目标是Redis 中每个渠道 key 只保留一个窗口周期比如 5 分钟加少量缓冲的数据。这样每个 key 的大小稳定在窗口内交易笔数的量级。清理机制有两种实现方式工程上都可行方式一查询触发清理。每次 ZCOUNT 之前先执行一条ZREMRANGEBYSCORE key -inf (now-window-buffer)清理窗口之前的数据。优点是不需要额外任务代码简单缺点是查询路径多了一次写操作会让统计逻辑的耗时翻倍并且多个统计任务并发查询时清理操作可能互相重复执行。我一开始用的这个方案后来发现高峰期 Redis 的写放大比较明显就切换到了方式二。方式二独立定时清理任务。单独起一个定时任务每隔一分钟扫描所有统计 key执行ZREMRANGEBYSCORE key -inf (now-window-buffer)。每次清理删除的量大概就是新写入的量级Redis 压力很均匀。而且可以控制扫描节奏避免在 Redis 高峰期集中清理。我最后线上用的就是这种方式。注意这里buffer要留多少取决于你的最大延迟容忍度我设的是 60 秒等于说统计窗口的有效数据比名义窗口多留 1 分钟缓冲防止消息延迟导致一部分本该算进窗口的数据被误清理。清理脚本大致这样import redis import time r redis.Redis(host..., port6379, decode_responsesTrue) WINDOW_SECONDS 300 BUFFER_SECONDS 60 def cleanup_stats_keys(patternpay:result:*): keys list(r.scan_iter(matchpattern, count1000)) now time.time() cutoff str(now - WINDOW_SECONDS - BUFFER_SECONDS) for key in keys: r.zremrangebyscore(key, -inf, f({cutoff})注意(前缀在 Redis 里表示严格小于这样 cutoff 那一条数据会被保留不会误删边界数据。3.3 TTL 管理和 key 的熵只看清理机制还不够还要给 key 设置过期时间这个很多人容易漏。清理任务负责删 ZSet 里的旧成员但不负责删除 key 本身。如果某个渠道进入维护状态好久没有交易ZSet 里的数据会被清理任务逐步清空但 key 还在只是变成一个空壳。积少成多空壳 key 也会占一撮内存。好在 ZADD 写入的时候可以顺便设置 TTL。我建议在写入逻辑里每次 ZADD 成功后再执行一条EXPIRE key 3600意思是这个 key 至少存活一小时。Why 一小时因为统计窗口是 5 分钟清理任务每分钟会删旧数据所以正常情况下 key 里只会有最近 5~6 分钟的数据。但 TTL 设一小时是兜底——如果某渠道断崖式停交易清理任务也不再能维护它这些残留数据在一小时后自动消失不需要额外逻辑处理。ZADD pay:result:channel_x:success 1736745600 order_12345 EXPIRE pay:result:channel_x:success 3600这两个操作可以用 pipeline 合并成一次网络往返减少一次 RTT。还有一个小技巧Redis 7.0 以后支持在 ZADD 的选项里带GT、XX等条件但 EXPIRE 没有 ZADD 原生的组合写法所以 pipeline 是最省事的。内存估算可以直接算。假设每个 member 是订单号32 个字符score 按 Redis 内部存储 double 算 16 字节ZSet 是 dict skiplist 的组合每个元素大约多 60~100 字节的索引开销。单个 key 里元素数如果是 10 万条内存大概 10~15 MB。5 分钟窗口内一个渠道产生 10 万笔交易这已经是非常大的支付渠道了对应的内存也就是十几 MB30 个渠道满打满算不到 500 MB。一台标准 Redis 实例毫无压力。如果你的渠道极端到5 分钟几十万笔还得继续下钻那就是另一个量级的问题了需要考虑采样统计或者换更重的时序数据库不在这个项目范畴内。4. 告警、降级与扩展思考4.1 成功率阈值怎么定阈值设多少直接决定这个监控系统是狼来了还是真能救命。拍脑袋定一个 95% 我也干过结果是某个渠道平时成功率是 96%阈值 95% 的话偶尔有波动就触发告警一周告警十几次最后都判为抖动运营同学根本不当回事。后来我换了一套思路阈值从历史数据来而不是拍脑袋。做法是拿过去 30 天的数据按渠道、按小时统计成功率求出 P55% 分位数和平均值。阈值设为平均值 - 2×(平均值-P5)再叠加一个绝对下限。比如某渠道历史平均 96%P5 是 93%那么动态阈值就是 96% - 2×(96%-93%) 90%。跟固定阈值相比这个方案兼容了这个渠道本身就容易波动的现实只对明显恶化的波动告警。当时我实现的是一个简单的 Python 脚本每天凌晨跑一次离线数据把每个渠道的阈值更新到 Redis 的一个配置 key 里实时告警任务读取。另外两个经验持续窗口判定。不要看到一次低于阈值就告警而是连续两个窗口比如 30 秒轮询连续两轮都低于阈值才触发。这样能过滤掉单笔重试导致的瞬时抖动。告警更稳误报显著减少。配置化告警渠道。不同渠道的告警接收方不一样跟 A 渠道的负责人对接的时候告警要单独发给 A 的业务群不能一把梭全发。这个在告警系统里配置即可但很多人会忘。4.2 从统计到自动降级的联动统计结果如果只用来发告警价值只发挥了一半。真实场景里成功率暴跌往往是支付渠道出问题的前兆这时候最有价值的动作是把流量切到备用渠道。但这个动作风险高不建议直接做成全自动更合理的做法是半自动一键切换。我的实现是监控系统检测到某渠道连续 N 个窗口低于阈值自动在工单系统创建一个渠道降级申请单并把当前各渠道成功率并列展示在操作页面上。值班同学点确认后路由系统的配置中心把该渠道的权重降为 0流量切到备用渠道。整个过程从发现到切换快的话 1 分钟以内能完成。不过这里要奉劝一句自动切换的判定条件一定要加上备用渠道当前健康。有一次某主渠道确实崩了但备用渠道同时也在被大量导流因为另一个项目也在做降级结果一切过去备用渠道也被压垮两个渠道一起挂。后来我们加了备用渠道健康检查备用渠道的成功率必须高于某个值比如 92%否则切换会被系统阻止只发告警不发工单。这个防止二次雪崩的约束我认为是整个联动方案里最重要的一行判断逻辑。4.3 这套方案还能扩展到哪些场景ZSet 做滑动窗口统计其实不限于支付成功率我后来发现几个场景可以直接复用这套模式下游接口响应时长分布统计。score 存时间戳member 存请求 IDZCOUNT 统计过去 5 分钟内响应超过 500ms 的请求数再除以总请求数就是慢请求率。比逐条打日志再聚合实时得多。风控事件频率监测。比如某商户 ID 过去 5 分钟触发风控规则多少次ZSet ZCOUNT 可以秒查比把事件写入数据库再 group by 快几个数量级。限流告警。某些场景想监控单位时间请求量突增也可以把每个请求记录进 ZSet然后按窗口计数。这个方案比 Redis 内置的限流指令更灵活因为你可以同时统计多个互斥的时间窗口1 分钟、5 分钟、1 小时。基本模式都是同一套member 是唯一标识、score 是时间戳、ZCOUNT 是统计函数、ZREMRANGEBYSCORE 是过期清理。这套抽象一旦建立换个业务只是 key 的命名前缀和窗口大小不同代码能复用掉大半。5. 常见问题与排查技巧实录下面这些是我在实际运行中踩过、或者帮同事排查过的典型问题整理成速查表方便大家对照。现象可能原因排查方法解决办法成功率整体偏低状态映射表未覆盖新状态码查看消费日志中未识别状态码告警更新映射表对未知状态码打点统计数字偶发跳变同一订单先失败后成功或反过来两个 key 同时存在Lua 脚本查询 member 在两个 key 中的存在性写入前做状态机校验原子性修正告警延迟消息队列积压消费端处理不过来查看 MQ 积压数、消费耗时扩容消费者设置时间戳新鲜度检查统计结果偏向过去使用了应用服务器时间导致时钟偏移比对应用服务器与 Redis 时间统一用 Redis TIME 命令取当前时间内存缓慢增长TTL 没设置key 变成空壳也无法自动回收查看 Redis 中pay:result:*的 key 数量写入时设置 EXPIRE兜底清理渠道无交易时告警total 为 0 时返回异常检查脚本对 total0 的处理返回 0不告警成功率与离线报表不一致实时口径与离线口径不同核对口径定义明确双口径不同场景用不同公式我单独说一下其中两个最值得讲的排查经历。有一次凌晨线上告警某渠道成功率突然从 95% 跌到 70%。我第一反应是渠道故障赶紧打开渠道侧管理后台结果渠道方说一切正常。再去查统计的原始记录发现失败 key 里多了一批很奇怪的 member全是同一个订单号。你猜到了——渠道方做了一次批量重放测试把同一笔订单的结果重复上报了几百次而我们当时的 member 是订单号状态导致同一订单的多个失败状态变成了多个不同 memberZSet 无法去重统计被刷爆。修好这个问题的根本办法就是把 member 改成订单号而不是订单号状态让同一订单在同一个 key 里天然只能有一个副本。这个教训我印象很深member 的幂等设计只对同一订单同一次结果生效对同一订单多次不同结果要配合状态机修正。另一次是统计偶尔出现整分钟窗口变窄的现象。查了很久发现是我们监控系统的轮询任务在某些时刻线程被 GC 卡住导致查询延后了几十秒。原本 5 分钟的窗口因为查询延后实际上变成了 4 分 30 秒数字自然要低一些。后来在监控系统里加了窗口时长校验每次查询都先计算now - windowStart如果不足 90% 的窗口宽度就丢弃本次统计等下一个完整窗口。这个细节对准确性帮助很大。最后分享一个每天上线后值得用的小技巧可以在 Redis 里同时维护一个pay:stat:total的普通计数器每天零点从离线任务里把真实成功率算好放进去。实时统计链路如果发生任何问题你可以拿实时数字跟这个基准去对差额超过一定比例就说明统计链路有 Bug而不是渠道真的出了故障。我靠着这个对照基准至少两次在渠道方还没有感知的时候先发现了自己统计系统的日志错误。这套方案上线跑了大半年最大的体会是实时统计系统不怕数据量大怕的是口径混乱、时钟不一致和重复数据处理这三座大山。ZSet 只是提供了趁手的工具真正的功夫在于把这三座大山一个个铲平。如果你的支付渠道监控也正卡在统计不实时、告警不准确、问题定位慢上按照上面这套思路改造一遍应该能明显看到变化。
