4. 信贷核心系统技术栈面试要点
信贷核心系统的技术栈面试，考察的不是“你会不会用某个框架”，而是“你能不能用这套技术组合扛住资金安全、数据一致与高并发”。面试官通常围绕一条主线追问：一笔放款请求从进入系统到落库、记账、发消息、更新缓存，中间每一层你如何保证正确与可恢复。本章帮你把零散的技术点串成一条可表达、可追问、可加分的回答路径。
核心心法：信贷系统里，技术选型的唯一标准是“一致性优先、可追溯、可补偿”。任何回答都要落到“钱不能错、账不能乱、状态可回滚”。
一、核心原理：每一层技术在信贷场景中的“职责边界”
面试时不要孤立背技术，而要讲清每层在信贷链路中的职责。Java 层负责业务编排与状态机流转；Spring 负责事务边界与依赖治理；分布式负责服务拆分后的一致性；数据库是最终真相来源；缓存负责读性能但不能作为真相；消息队列负责异步解耦与最终一致。
| 技术层 | 信贷场景职责 | 面试高频追问 |
|---|---|---|
| Java | 状态机、金额计算、并发控制 | BigDecimal 精度、线程安全 |
| Spring | 事务边界、AOP、异常回滚 | 事务失效场景、传播行为 |
| 分布式 | 服务拆分、一致性、幂等 | 分布式事务方案选型 |
| 数据库 | 账务落库、行锁、唯一索引 | 隔离级别、死锁、分库分表 |
| 缓存 | 热点产品、额度查询加速 | 穿透、击穿、雪崩、一致性 |
| 消息队列 | 异步记账、通知、对账 | 顺序、重复、积压、丢失 |
二、方法流程：一笔放款请求的标准技术回答路径
- 接入校验：参数校验、防重放、业务唯一号生成，保证幂等入口。
- Spring 事务：用
@Transactional包裹核心落库，明确回滚异常类型，避免事务中做远程调用。 - 数据库落库：账务流水、借据、额度变更在同一事务内完成，靠唯一索引兜底幂等。
- 本地消息表：与业务同事务写入消息表，再由定时任务投递到 MQ，实现最终一致。
- 缓存更新：采用“先落库、后删缓存”，并设置过期时间兜底。
- 补偿与监控：对账任务扫描不一致，告警驱动人工介入。
// 事务内写业务 + 本地消息表，保证原子性
@Transactional(rollbackFor = Exception.class)
public void loan(LoanCmd cmd) {
loanMapper.insert(loan);
accountMapper.updateBalance(cmd);
msgMapper.insert(new LocalMsg(cmd.getBizNo(), "LOAN_SUCCESS"));
}
// 定时任务扫描未投递消息，投递成功后更新状态
三、案例/场景：高并发抢额度下的缓存与数据库配合
场景：某信贷产品秒杀式放款，额度查询 QPS 极高。面试官会问“缓存和数据库如何保持一致”。推荐回答：额度查询走 Redis，扣减走数据库行锁或乐观锁，扣减成功后删除缓存；对超卖用唯一约束或版本号兜底。若缓存与库不一致，以库为准，通过延迟双删与对账修复。
加分表达：主动区分“强一致场景（账务落库）”与“最终一致场景（通知、对账）”，并说明为什么不能一刀切用分布式事务。
四、误区与复盘：面试中最容易踩的坑
- 误区一：在事务中发送 MQ 消息。若消息发送成功但事务回滚，会造成脏消息。应改为本地消息表或事务消息。
- 误区二：先更新缓存再落库。并发下缓存可能写入旧值，应“先库后删缓存”。
- 误区三：只讲技术名词不讲业务后果。面试官更想听“钱会不会错、账会不会乱”。
- 误区四：忽略幂等。信贷所有写接口都必须有业务唯一号与唯一索引。
复盘建议：每讲一个技术点，都补一句“如果这里失败，我的补偿动作是什么”。这句话能显著提升面试官对你工程成熟度的评价。
把 Java、Spring、分布式、数据库、缓存、消息队列串成一条“一致性链路”来表达，你就从“会背八股”升级为“能扛信贷核心系统”的候选人。面试中始终围绕资金安全、幂等、补偿、监控四个关键词展开，技术栈自然成为你表达能力的支撑，而不是负担。