LOCAL 通道选卡策略
适用范围：商户发起代收时，系统从平台跑分账户池里给这笔订单挑一张「接单卡」。
本文用通俗的话讲清楚「哪些卡可以接、谁优先接、为什么这么设计」，方便运营、风控、客服快速理解。
1. 一句话概览
先用一连串「门槛」过滤掉不该接的卡（含认证免检期），再在剩下的卡里按「最近表现好的优先」做加权随机抽签，取排序第一的可派卡并尝试占位加锁、冻结余额，成功即派单。
选卡过程不再实时调用爬虫校验登录态；每张卡由后台按各自节奏自扫描，扫描通过后写入 Redis「免检期」，免检期内视为认证有效、可参与派单。
2. 选卡流程总览
补充说明：
- 同金额已被占用、余额冻结失败等情况会换下一张卡，不会调爬虫。
- 若当前没有任何处于「认证免检期」内的卡，LOCAL 通道直接失败，订单交给下一个支付通道。
3. 基础合格条件（最低门槛）
只有同时满足下面这些条件的卡，才会进入后续的 6 条派单规则：
| 条件 | 通俗说明 |
|---|---|
| 用户账户正常 | 跑分用户没被冻结、没被禁用 |
| 卡片可接单 | 未删除、已开启卖币；数据库显示已认证 |
| 认证免检期内 | Redis 中有该卡的「认证有效」标记（见第 6 节） |
| 余额够用 | 可用余额 ≥ 本次代收金额 |
| 金额达标 | 本次金额不低于该用户设置的最低接单金额 |
这一层是「硬性资格」，连这一关都过不了的卡，不会出现在后续名单里。
4. 6 条派单规则（逐张过滤）
候选名单进来以后，每张卡会被这 6 条规则依次检查，任何一条不满足就直接淘汰。所有「今天」「近 10 分钟」等时间，均按印度时间计算。
规则 ①：当天成功收款不能超过上限
- 什么意思：每张卡每天最多接若干笔「已经收到钱」的订单。默认上限 13 笔，可在管理后台「钱包列表」按卡人工调整（0～100 笔；设为 0 表示当天不再派单）。
- 怎么数：把这张卡当天的银行到账流水，和平台上已成功的代收订单合在一起，按交易号去重后计数。
- 满了怎么办：今天不再派单；印度时间次日 0 点自动清零（计数清零，上限配置本身不变）。
规则 ②：进行中订单不能超过容量上限
- 什么意思：还没出结果的订单太多，就不能再压新单。
- 怎么算：先看今天还能成功几笔（该卡配置的单日成功上限 减去已成功笔数），再按「预估成功率 50%」折算还能接多少在途单。以下示例均按默认上限 13 笔计算：
- 今天 0 笔成功 → 最多同时接 26 笔进行中
- 今天 6 笔成功 → 最多同时接 14 笔进行中
- 今天 12 笔成功 → 最多同时接 2 笔进行中
- 若某卡上限被调整为 20 笔，则公式中的「13」替换为该卡当前配置值。
- 「进行中」包括：支付中、审核中、失败倒计时、失败待补单。
- 目的：从「今天总共还能压多少单」的角度控总量。
规则 ③：同时进行的活单最多 3 笔（试探期更严）
- 什么意思：这张卡同时正在支付或正在审核的订单，平时最多 3 笔。
- 为什么需要：规则 ② 在卡刚开张时上限很宽（最多 26），如果一瞬间灌进很多单，可能多笔一起失败，来不及触发规则 ④ 的冷却。规则 ③ 把「此刻正在跑的单」压到 3 笔，降低误匹配和失败堆积风险。
- 和规则 ② 的区别：
- 规则 ② 看「今天总共还能压多少在途量」，会随已成功笔数变少而变紧。
- 规则 ③ 只看「此刻正在支付/审核的单」，固定上限 3 笔。
- 两条同时生效，取更严的那条。
- 试探期（更严）：若这张卡「最近一次成功之后又已连续失败 3 笔」，失败计数还没被新成功清零，那么即使 30 分钟冷却已过，同时进行的活单也临时只允许 1 笔：
- 冷却结束后先派 1 笔试水；
- 试水单还在跑时，不再派第 2 笔；
- 试水成功 → 失败计数清零，恢复 3 笔上限；
- 试水又失败 → 重新进入 30 分钟冷却。
规则 ④：连续失败 3 笔，冷却 30 分钟
- 什么意思：最近一次成功之后已连续失败 3 笔，且最近一笔失败发生在 30 分钟内 → 暂停派单。
- 哪些算失败：取消、支付超时、订单失败。
- 哪些算成功：银行到账成功，或平台代收订单成功，取最近的那一次。
- 怎么解除：
- 等满 30 分钟 → 可以重新派单，但失败计数不会清零，进入规则 ③ 的「试探期」，一次只放 1 笔；
- 出现一笔新的成功 → 失败计数清零，完全恢复正常。
规则 ⑤：10 分钟内同卡同金额不能重复接
- 什么意思：这张卡过去 10 分钟内，已经有一笔相同金额的代收单还在支付中或审核中，则不再接新的同金额单。
- 为什么需要：到账匹配主要靠「金额 + 时间窗口」。同卡短时间两笔同金额，容易把一笔到账对错单。
- 并发保护：选中前，系统会立刻给「这张卡 + 这个金额」加一把短期锁（默认 10 分钟），和上面的查询规则一起用，避免高并发下重复派单。锁没抢到就换下一张卡；订单结束或派单失败时会自动释放。
规则 ⑥：当天接太多且成功率太低
- 什么意思：这张卡今天代收已经不少，但整体成功率很差 → 暂停派单，让给更稳的卡。
- 怎么算（与管理后台「今日接单量 / 今日成功率」一致）：
- 统计今天印度时间 0 点到次日 0 点之间，这张卡接的所有代收子单；
- 总笔数 = 上述范围内全部子单；
- 成功笔数 = 其中已成功的子单；
- 成功率 = 成功笔数 ÷ 总笔数。
- 拦截条件（须同时满足）：
- 总笔数 ≥ 10 笔；
- 成功率 低于 20%（恰好 20% 不拦截）。
- 怎么恢复：
- 印度时间次日 0 点后重新计数；
- 或当天再成功几笔，让成功率回到 ≥ 20%。
- 用户通知：被拦截时，会给该卡用户发 Telegram 英文提醒，建议更换 UPI 绑定的主银行；每张卡每天最多提醒一次。
边界示例：
| 当天笔数 | 成功笔数 | 是否拦截 |
|---|---|---|
| 9 | 0 | 否（未满 10 笔） |
| 10 | 1 | 是（10% < 20%） |
| 15 | 3 | 否（恰好 20%） |
| 20 | 3 | 是（15% < 20%） |
5. 谁优先接单？（加权随机抽签）
过滤完之后，候选名单往往还剩很多张。这一步决定「先试哪张」——不是完全随机，也不是简单谁成交量大谁第一，而是综合「最近表现 + 新人照顾」来抽签排序。
5.1 得分怎么算
| 项 | 含义 |
|---|---|
| 加分：近两天活跃度 | 昨天 0 点到明天 0 点（共 2 个印度自然日）内，这张卡银行流水里「真实收款成功」的笔数（不含平台订单统计，和规则 ① 的 13 笔口径不同） |
| 减分：当天失败 | 今天作为接单方的代收订单里，已取消/超时/失败的笔数 |
| 加分：新人照顾 | 该跑分账户历史成功**代付（出款）**越少，名下所有卡加分越多。默认：代付成功不足 6 笔时，每少 1 笔加 2 分；代付 ≥ 6 笔后不再加分 |
| 基础得分 | （活跃度 − 当天失败，最低按 0 算）+ 新人加分，再 +1 保底，确保冷门卡也有机会 |
| 实际抽签权重 | 对基础得分做「压缩」（指数 0.6），避免超级活跃卡把其它卡完全挤没 |
压缩效果示例：
| 基础得分 | 压缩后权重 |
|---|---|
| 1 | 1.00 |
| 5 | 2.63 |
| 10 | 3.98 |
| 20 | 6.06 |
举例：A 卡近两天收款 20 笔、今天失败 2 笔，基础得分 19，压缩后约 5.87；B 卡近两天 0 笔、今天没失败，基础得分 1。A 仍更容易排前面，但不会把 B 完全封死。
新人加分阶梯（按累计成功代付笔数）：
| 累计成功代付 | 新人加分 | 基础得分（活跃度为0时） | 压缩后权重 |
|---|---|---|---|
| 0 笔 | +12 | 13 | 4.71 |
| 1 笔 | +10 | 11 | 4.23 |
| 3 笔 | +6 | 7 | 3.21 |
| 5 笔 | +2 | 3 | 1.93 |
| ≥ 6 笔 | 0 | 1 | 1.00 |
新人逻辑：代付越少 → 越需要多接代收攒余额 → 更快完成首笔出款。同一跑分账户名下的多张卡共享同一份新人加分，避免开多卡刷加成。
5.2 抽签怎么理解
可以想成 加权抽奖：
- 得分越高的卡，「抽奖券」越多，越可能排在前面先试。
- 一次性排出全部卡的尝试顺序（抽过的不再重复）。
- 压缩算法让头部卡有优势，但不会通吃全部机会。
5.3 当天失败为什么要扣分？
如果只看昨天表现，今天已经连续失败的卡仍可能被优先派单，成功率会继续变差。把当天失败从得分里扣掉，能让「今天状态差的卡」快速靠后。
5.4 为什么要照顾新跑分用户？
跑分用户要完成「接代收 → 攒余额 → 申请代付出款」才算走通流程。新人近两天活跃度往往是 0，按旧规则很难排到前面，首笔出款慢、体验差。
加上新人加分后，从未出款的用户会明显靠前；每完成一笔代付，加分逐步减少；代付满 6 笔后回归正常竞争。
6. 认证免检期与按卡自扫描
6.1 选卡侧（不再调爬虫）
加权排序后，系统只从处于「认证免检期」内的卡里取第一张，尝试同金额占位与余额冻结；全程不调爬虫。
| 情况 | 处理方式 |
|---|---|
| 在免检期内 | 可参与派单 |
| 免检期已过期或未预热 | 不参与派单，等后台自扫描刷新 |
| 同金额已被占用 | 换下一张 |
| 余额冻结失败 | 换下一张；该跑分用户本轮不再试其它卡 |
6.2 后台按卡自扫描
每张已认证卡有各自的下一次扫描时刻，四钱包统一 20 分钟免检/扫描间隔；写入 nextDue 时在 [interval, 2×interval) 窗口内按分钟桶查 ZSET 负载，选最空时段（并列时用 userCardId 打破平局），避免到期扎堆：
| 钱包类型 | 免检/扫描间隔 |
|---|---|
| Mobikwik / PhonePe / Freecharge / Navi / 其它 | 20 分钟 |
- 扫描通过 → 写入免检期（TTL 与 nextDue 对齐），并自适应调度下一轮扫描。
- 确认失效 → 降级为未认证、清免检期、通知用户。
- 瞬时异常（网络抖动、爬虫繁忙等） → 约 2 分钟后重试，不立刻降级。
- 绑卡/重认证成功 → 立即写入免检期并入队扫描。
- 仍在免检期内被 tick 扫到 → 仅重排 nextDue，不延长 TTL。
每分钟 tick 从队列取出已到期的卡，每轮最多处理 80 张、4 路并发调 crawler，把爬虫压力均匀摊开。
6.3 上线预热
新版本发版前，需运行 profile_valid_warmup.py（见服务端仓库脚本）对全部已认证卡写入初始免检期与扫描队列，避免切换瞬间 LOCAL 无可用卡。
7. 选中之后做了什么？
选中 = 同金额占位成功 + 余额冻结成功（选卡时完成，不调爬虫）：
- 冻结余额：避免同一笔钱被多单重复占用。
- 生成 UPI 收款码：返回给商户/用户付款。
- 后续付款、提交 UTR、爬虫对账、补单、超时关单等，由其它流程继续处理。
8. 常见场景速查
| 场景 | 系统行为 |
|---|---|
| 一张卡刚刚成功收了一笔 | 失败计数清零；今日剩余配额减 1；得分略升；活单上限恢复 3 笔 |
| 一张卡连续 3 笔失败 | 冷却 30 分钟，期间跳过 |
| 冷却刚结束、还没有新成功 | 进入试探期，同时只允许 1 笔活单 |
| 一瞬间灌进多笔订单 | 同卡最多 3 笔同时在跑（试探期仅 1 笔） |
| 一张卡过去两天很活跃 | 抽签排名靠前；今天每失败 1 笔扣 1 分 |
| 一张卡过去两天没动静 | 得分最低，但仍有机会被抽到 |
| 跑分账户从未成功代付过 | 新人大幅加分，名下卡明显靠前 |
| 跑分账户已成功代付 6 笔及以上 | 新人加分归零，按正常活跃度竞争 |
| 免检期内 token 实际已掉线 | 仍可能派单；等下次自扫描发现后降级 |
| 免检期刚过期、扫描尚未跑到 | 暂不参与派单 |
| 用户刚绑卡/重认证 | 立即进入免检期，可接单 |
| 同一用户两张卡都有效，但余额只够冻一笔 | 先成功的选中；该用户本轮不再试其它卡 |
| 商户连续下两笔同金额 | 同卡不会重复接，约 10 分钟后解除 |
| 今天 10 笔代收只成功 1 笔（10%） | 触发规则 ⑥，当天暂停 |
| 今天 15 笔代收成功 3 笔（20%） | 不拦截 |
| LOCAL 无任何免检期内卡 | 创单失败，转下一支付通道 |
9. 关键参数一览（运营可读版）
| 参数 | 当前值 | 含义 |
|---|---|---|
| 单卡每日成功上限 | 默认 13 笔，可按卡配置（0～100） | 每天每张卡成功收款上限；0=当天不再派单；管理后台钱包列表可人工调整 |
| 预估成功率 | 50% | 折算「还能压多少在途单」用的假设值 |
| 同时活单上限（正常） | 3 笔 | 正在支付或审核的订单最多 3 笔 |
| 同时活单上限（试探期） | 1 笔 | 冷却结束但失败计数未清零时 |
| 连续失败触发冷却 | 3 笔 | 最近一次成功之后 |
| 冷却时长 | 30 分钟 | 从最近一笔失败算起 |
| 同金额互斥窗口 | 10 分钟 | 同卡短时间不接相同金额 |
| 低成功率拦截门槛 | 10 笔起 | 且成功率低于 20% |
| 低成功率阈值 | 20% | 恰好 20% 不拦截 |
| 加权统计窗口 | 近 2 天 | 印度自然日，看银行收款活跃度 |
| 权重压缩 | 0.6 次方 | 防止头部卡概率过高 |
| 新人判定 | 代付成功 < 6 笔 | 不足则按缺少笔数加分 |
| 新人每少 1 笔加分 | 2 分 | 可在后台策略中调整 |
| 四钱包免检/扫描间隔 | 20 分钟 | Mobikwik / PhonePe / Freecharge / Navi 统一 |
| 自扫描 tick 间隔 | 1 分钟 | 每分钟检查到期卡 |
| 每 tick 最多扫描 | 80 张 | 限流保护爬虫 |
| tick 内并发 worker | 4 | 单卡 ~4s 时吞吐约 60 张/min，覆盖 916 卡/20min 稳态需求 |
| tick 分布式锁 | 6 分钟 | 覆盖一轮并行扫描最坏耗时 |
| 逐卡到期打散 | 自适应分钟桶 ZCOUNT | 在 20~40min 窗口内选负载最低分钟，峰值目标 ≤ max-per-tick |
| 自适应关闭回退 | userCardId 取模 stagger | adaptive-schedule-enabled=false 时使用 |
| 瞬时失败重试间隔 | 2 分钟 | 网络/爬虫繁忙时不立刻降级 |
所有时间窗口均按印度时间（UTC+5:30）计算。
10. 设计意图回顾
- 保护单卡日承载：默认 13 笔/天上限（可按卡调整），避免单卡过载、被风控盯上。
- 保护单卡瞬时承载：活单硬上限 3 笔，降低误匹配和失败堆积。
- 保护账户健康：连续失败立刻冷却，让卡先「喘口气」。
- 保护试探期：冷却刚结束时一次只放 1 笔，避免并行试探全失败。
- 保护到账匹配：同金额 10 分钟互斥，减少对错账。
- 保护大盘质量：接够 10 笔仍低于 20% 成功率的卡暂停派单。
- 保留公平性：冷门卡仍有抽签机会；压缩算法避免一家通吃。
- 保留快速反应：当天失败立刻扣分。
- 降低创单延迟：选卡只读 Redis，不调爬虫，商户侧响应更快。
- 降低爬虫峰值：按卡分散自扫描，替代全局批量扫描。
- 照顾新人：代付少的用户优先接代收，加快首笔出款。
- 接受可控滞后：免检窗口内 token 掉线最多滞后一个扫描周期才降级，换取性能与负载均衡。