请分享一个你参与过的金融交易系统项目经验，重点说明在系统稳定性、高并发处理或合规性方面的挑战及解决方案。

1) 【一句话结论】在参与证券交易所交易撮合系统项目中，针对高并发下的订单处理稳定性挑战，通过“分布式ID+双缓存+异步消息队列+令牌桶限流”方案，成功将系统TPS提升至百万级，保障99.9%订单处理成功率。

2) 【原理/概念讲解】金融交易系统对“稳定性”“高并发”“合规性”要求极高：

• 高并发处理：指系统在短时间内处理海量请求的能力，类比“交通枢纽”，需通过“流量调度”（如限流、异步处理）避免“拥堵”（系统崩溃）；
• 系统稳定性：要求系统在异常（如网络波动、硬件故障）下仍能正常工作，类似“飞机冗余设计”，多套系统备份确保单点故障不导致全系统停摆；
• 合规性：金融业务需遵守法规（如反洗钱、数据安全），好比“法律红线”，任何操作都不能触碰，否则面临处罚。

3) 【对比与适用场景】以“限流策略”为例，三种常见方式对比：

方案	定义	特性	使用场景	注意点
固定窗口	每个时间窗口固定计数	简单易实现	低并发场景	容易产生“突刺”（窗口末尾瞬间流量激增）
滑动窗口	时间窗口动态调整	更精准	高并发场景	实现复杂，需精确计算
令牌桶	持续生成令牌，请求消耗令牌	流量平滑	需要流量平滑的场景	令牌生成速率需合理配置

4) 【示例】假设项目是“证券交易所交易撮合系统”，挑战是“每秒百万级订单请求下，保证订单处理的唯一性与低延迟”。解决方案：

• 订单ID生成：使用Twitter Snowflake算法（分布式ID生成器），确保全局唯一；
• 缓存层：订单状态读写分离，使用Redis缓存订单状态，读取请求优先从缓存获取，减少数据库压力；
• 异步处理：撮合后的交易结果通过Kafka消息队列异步发送给交易对手方，避免阻塞主流程；
• 限流策略：API网关层采用令牌桶算法，限制每秒请求量，防止系统过载。

5) 【面试口播版答案】面试官好，我分享一个参与过的金融交易系统项目经验。项目是证券交易所的交易撮合系统，核心挑战是在每秒百万级订单请求下，保障系统稳定性和高并发处理能力。当时我们遇到的难点是：订单撮合逻辑是核心业务，若处理延迟过高会导致交易失败；同时，高并发下订单ID冲突和缓存雪崩风险很大。解决方案上，我们做了三方面优化：一是订单ID采用分布式Snowflake算法，确保全局唯一；二是订单状态读写分离，使用Redis缓存订单状态，读取请求优先从缓存获取，减少数据库压力；三是引入消息队列异步处理交易结果，将撮合后的结果异步发送给交易对手方，避免阻塞主流程。通过这些方案，系统TPS提升至百万级，订单处理延迟控制在50ms以内，系统稳定性达到99.9%，成功应对了交易高峰期的压力。

6) 【追问清单】

• 问题1：你提到的分布式ID生成器具体是如何实现的？是否考虑过单点故障？
  回答要点：使用多节点部署，每个节点独立生成，通过一致性哈希负载均衡，避免单点故障。
• 问题2：在高并发场景下，如何处理缓存雪崩问题？是否有过应对经验？
  回答要点：通过设置合理的缓存过期时间，并引入分布式锁保证缓存更新时的原子性，同时使用限流策略控制雪崩影响。
• 问题3：项目中如何确保合规性？比如数据安全和交易记录的完整性？
  回答要点：采用加密传输（TLS），交易记录存储在不可篡改的数据库（如时序数据库），并定期进行合规审计。
• 问题4：如果系统出现单点故障，你的容灾方案是怎样的？如何快速恢复？
  回答要点：采用主从集群架构，主节点故障时自动切换到从节点，同时定期进行压力测试和故障演练。

7) 【常见坑/雷区】

• 夸大技术能力：比如声称自己独立设计过复杂的分布式系统，但实际经验有限；
• 方案不具体：只说“用了消息队列”，但没说明具体如何配置和使用；
• 忽略业务场景：比如只关注技术方案，而没结合金融交易的业务特点（如实时性要求）；
• 回答过于笼统：比如“解决了高并发问题”，但没给出具体的数据或指标；
• 忽略合规性：金融项目必须强调合规性，若没提及会被扣分。