fetch("./interview-review-2026-06-02.md")，直接本地双击打开也能看。
1. 这场面试到底在考什么
这场 KPAY 面试不是只问你会不会某个知识点，而是在看你能不能把“基础能力”和“支付项目闭环”连成一条线。面试官实际上在验证四件事：
- 你是否有扎实的 Java 后端基础，比如线程池、JVM、Redis、缓存、分库分表。
- 你是否真的做过支付链路，而不是只知道几个支付名词。
- 你是否能讲清楚设计取舍，比如为什么这么选拒绝策略、为什么要做 MQ 补偿、为什么 Redis 锁不能单独兜底。
- 你是否有“异常闭环”意识，也就是系统失败后怎么补、怎么查、怎么防止重复处理。
2. 并发、线程池、JVM 怎么讲
线程池参数怎么定
建议口径：我不会先拍一个固定线程数，而是先看任务类型、下游依赖、RT、超时阈值、峰值 QPS，再反推线程池参数。支付项目里不同任务必须拆池隔离，不能让交易主链路、查单补偿、商户通知、结算任务共用一个线程池。
- 交易主链路线程池：低延迟、小队列、尽快失败，避免慢渠道把入口线程拖死。
- 查单 / 回调补偿线程池：IO 密集，线程数可以高一些，但必须配超时和熔断。
- 通知 / 结算线程池：可以异步排队，但必须有监控、重试和补偿表。
项目结合点：在收单系统里，我会更重视“线程池隔离”而不是单纯把最大线程数调大，因为支付场景最怕少量慢请求把整个系统拖垮。
拒绝策略怎么选
建议口径：拒绝策略要跟业务语义绑定。支付主链路一般不建议用 DiscardPolicy 或 DiscardOldestPolicy，因为静默丢任务风险太高。更合理的是自定义拒绝策略，至少做到日志、监控、告警、补偿落表，再由异步任务继续兜底。
项目结合点：像 mq_send_retry 这种表，本质就是在线程池拒绝、MQ 发送失败、网络闪断时的兜底抓手。
线程堆积怎么排查
建议口径：我会按“三层排查法”来做：先看线程池指标和队列长度，再看是不是下游 RT 变慢、锁竞争、慢 SQL 或 GC 抖动，最后决定是限流、降级、拆池，还是改任务模型。
- 看监控：活跃线程、队列长度、任务 RT、P95/P99。
- 看现场：
jstack、Arthas、慢 SQL、TraceId。 - 看恢复：限流、切路由、熔断慢渠道、拆线程池、改成异步。
线上 JVM 问题怎么说
建议口径：我没有遇到特别大的 JVM 事故，但遇到过 RT 抖动、GC 频繁、线程阻塞这类线上问题。排查顺序一般是先看 CPU / 内存 / GC / 线程哪个维度异常，再用 jstat、jmap、jstack 和 Arthas 定位。
项目结合点：支付系统里常见的 JVM 问题往往不是 JVM 本身，而是下游渠道超时、MQ 积压、缓存回源风暴把 JVM 压出来的。
3. Redis、Redisson、分布式锁怎么讲
Redis Cluster、hash slots、故障转移
建议口径：Redis Cluster 是把 key 映射到 16384 个 slot，再把 slot 分配给不同 master。故障转移时不是简单换机器，而是 slot 跟着新的 master 走。所以我会重点关注热点 key、跨 slot 操作和 key 分布均衡。
Redisson 原理和优势
建议口径：Redisson 不是简单包一层 Redis，它把可重入锁、读写锁、延时队列等 Java 并发语义封装好了，底层结合了 Lua、value 绑定线程身份、可重入计数、Pub/Sub 和 watchdog 自动续期，能大幅减少自己手写分布式锁的边界问题。
watchdog 怎么工作
建议口径：watchdog 的本质是“自动续租”。如果没有显式指定 leaseTime，Redisson 会先给一个默认过期时间，然后在锁持有期间周期性续期。如果显式传了 leaseTime=10s，那通常就按固定租约走，不再依赖无限续期。
主从切换导致锁丢失怎么办
建议口径：Redis 锁只能做第一层互斥，不能单独承担资金场景的一致性保证。真正的兜底要靠“业务单号唯一 + 幂等表 + 状态机校验 + 数据库唯一约束”。如果是一致性要求更高的场景，再考虑 CP 组件或者 fencing token。
项目结合点：支付、退款、结算入账这些动作，我不会只回答“加了 Redis 锁”，而是会强调多层防重。
4. 缓存、数据库、分表怎么讲
JVM 本地缓存怎么设计
建议口径：如果要设计 JVM 本地缓存，我会考虑数据结构、过期策略、淘汰策略、并发安全、容量上限、监控、手动失效能力，以及热点 key 的防击穿策略。支付项目里更适合缓存渠道配置、商户配置、路由规则、费率模板，不适合缓存强一致余额。
多机缓存同步和一致性
建议口径：更稳妥的思路是“DB 为准，Redis 做共享缓存，JVM 做 L1，本地缓存通过 MQ / PubSub 做失效广播”。重点不是让所有缓存层绝对实时一致，而是让失效链路可靠、热点 key 不击穿。
水平分表和表分区区别
建议口径：表分区更偏单机内优化，逻辑上还是一张表；水平分表是应用层或中间件层把数据拆到多个物理表甚至多个库，扩展能力更强，但跨分片查询、排序、事务复杂度也更高。
单表太大怎么办
建议口径：没有固定条数阈值，要看查询方式、索引、冷热数据比例和硬件能力。支付订单场景里，我会优先做冷热分离、历史归档、按时间治理，再决定要不要走水平分表。
5. 支付项目题该怎么回答
你负责哪一段
建议口径：我主要负责的是支付进入平台之后，到交易状态闭环，再到异步通知和结算衔接这一段核心后端链路，具体包括交易创建、渠道路由、调用渠道、回调处理、查单补偿、MQ 通知、结算消息发送等。
渠道路由怎么做
建议口径：路由不是写死商户走哪个渠道，而是基于商户、支付方式、国家、币种、卡组、限额、费率、成功率、健康度等维度做动态选择。成熟的路由至少要有准入层、策略层和实时健康层。
一笔支付完整链路怎么讲
建议口径：我一般按“三段法”来讲：
- 交易主链路：商户发起支付，平台创建订单并做幂等、防重、风控、路由、调用渠道。
- 状态闭环：同步返回成功/失败/处理中，处理中就等回调；回调要验签、幂等、状态机校验；丢回调再用查单补偿。
- 资金闭环：交易成功后发结算 MQ，写结算流水，更新余额，从 pending 释放到 available，再生成 payout，最后做外部与内部对账。
异常交易只靠定时任务吗
建议口径：不会只靠定时任务。更合理的是“同步结果 + 异步回调 + 延时查单 + 定时兜底 + 对账修正”五层补偿。延时队列更适合处理中订单的短周期查单，定时任务更适合扫长期异常。
接一个新渠道会关注什么
建议口径：我会重点看协议和签名、状态模型、幂等和重试、超时和查单能力、对账文件能力、限流和监控字段。核心不是接口能不能调通，而是能不能形成完整闭环。
低 QPS 渠道必须接怎么办
建议口径：这种场景核心是削峰和限流。我会在路由层和渠道适配层做令牌桶限流，必要时配短队列、降级、快速失败或切备用通道，而不是等渠道报错后再补救。
成功率怎么提升
建议口径：成功率提升不是单点优化，而是参数质量、路由策略、风控命中、渠道健康度、回调补偿、对账修正一起做。前面要减少无效请求，中间要选对渠道，后面要把漏单和状态不一致补回来。
6. 这场面试暴露出来的提升方向
面试官最后给你的建议其实很明确：不仅要知道知识点，还要做 demo，把知识点变成“自己真的调过、踩过、讲得出来”的状态。你现在最值得补的是这四块：
- 线程池压测 demo：不同拒绝策略、不同队列长度、不同下游 RT 下的表现。
- Redis 锁 demo：watchdog、主从切换、幂等兜底。
- 多级缓存 demo：JVM + Redis + MQ 失效广播。
- 支付补偿 demo：同步返回、异步回调、延时查单、定时兜底、幂等入账。
7. 建议你下次怎么讲
如果面试官让你自由发挥，你可以用下面这个顺序讲，最稳：
- 先讲你负责的是支付主链路到结算衔接这段核心后端能力。
- 再讲一笔支付从创建、风控、路由、渠道调用、回调、查单补偿，到结算、余额、出款、对账的全闭环。
- 然后补充系统稳定性设计：线程池隔离、MQ 重试、幂等表、Redis 锁、对账修正。
- 最后再回答底层问题，把线程池、Redis、缓存、分库分表都落回支付项目。
这样讲出来，面试官会更容易判断你是“做过完整系统的人”，而不是只做过某个接口的人。