设计一个交易系统（商城、充值），如何保证交易的安全性和一致性？请说明关键技术点和实现细节。
游卡客户端主程难度：中等
答案
1) 【一句话结论】
交易系统需通过分层架构（安全防护、业务处理、数据存储）结合分布式事务（Saga模式保障高并发最终一致性，2PC保障强一致性）及支付渠道风控，确保“安全防护抵御攻击，分布式事务保障数据一致性”。
2) 【原理/概念讲解】
交易系统的安全性与一致性需从技术架构和核心机制入手，以下是关键点讲解：
- 安全防护机制：
- 加密与签名：对称加密（如AES）用于数据传输加密（速度快，适合传输加密），非对称加密（如RSA）用于签名/验证（公私钥分离，保证身份可信）。签名采用
HMAC-SHA256(参数+密钥)结合时间戳，防止请求篡改和重放攻击。 - 防重放攻击：请求中包含时间戳（如当前时间）和签名，服务端验证时间戳（如≤5分钟）和签名有效性，确保请求唯一性。
- 加密与签名：对称加密（如AES）用于数据传输加密（速度快，适合传输加密），非对称加密（如RSA）用于签名/验证（公私钥分离，保证身份可信）。签名采用
- 一致性模型：
- Saga模式（异步补偿）：将分布式事务拆分为多个本地事务步骤，通过消息队列传递状态，每个步骤成功则提交，失败则执行补偿步骤回滚。核心是“补偿步骤需与原步骤相反（如扣款失败则加钱）”，且通过唯一标识（订单ID）保证幂等性。
- 两阶段提交（2PC）：协调者-参与者模型，协调者决定提交/回滚，适用于强一致性场景（如金融级充值），但存在阻塞问题（协调者等待所有参与者响应）。
（类比：Saga模式像“流水线生产，每个环节独立，失败则回退；2PC像“集中指挥，所有节点同步操作，保证数据立即一致”。）
3) 【对比与适用场景】
| 方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| Saga模式 | 分步骤本地事务，通过消息队列传递状态，失败则补偿 | 最终一致性，异步处理，高并发 | 商城下单、高并发充值（允许短暂不一致，通过补偿恢复） | 补偿逻辑复杂，需保证正确性 |
| 两阶段提交（2PC） | 领导者-从者模式，协调者决定提交/回滚 | 强一致性，数据立即一致 | 需强一致性（如充值、提现），低并发场景 | 阻塞问题（协调者等待参与者），协调者故障导致数据不一致 |
4) 【示例】
用户充值流程（伪代码）：
- 前端请求：
POST /api/recharge，参数：userId=1001, amount=50, timestamp=1678888888, signature=HMAC-SHA256(参数+密钥) - 网关验证：检查签名有效性、时间戳（≤5分钟）、参数有效性（userId存在）。
- 核心服务处理：
- 检查用户余额（数据库查询，本地事务）。
- 扣款：执行数据库事务（
UPDATE user SET balance=balance-50 WHERE id=1001）。 - 发送支付网关请求：
POST /gateway/pay，参数：userId=1001, amount=50。
- 支付网关处理：扣款（银行接口，本地事务），回调成功：
POST /api/recharge/callback，参数：status=success。 - 核心服务收到回调：更新用户余额（数据库事务，确认扣款成功），发送消息到消息队列：“recharge_success_1001_50”。
- 支付网关回调失败：核心服务从消息队列获取失败消息，执行补偿：
UPDATE user SET balance=balance+50 WHERE id=1001（恢复余额）。
5) 【面试口播版答案】
“面试官您好，针对交易系统（商城充值）的安全性和一致性，我的设计思路是构建分层架构并组合关键技术。安全性方面，采用加密+签名机制：前端请求包含时间戳和HMAC签名，服务端验证签名和时效性（如5分钟内），防止重放和篡改；支付环节用非对称加密传输敏感数据。一致性方面，高并发场景用Saga模式，将充值拆分为‘检查余额-扣款-通知支付-回调确认’四个本地事务步骤，通过消息队列传递状态，失败则补偿回滚，保证最终一致性；强一致性场景（如充值）用2PC保证数据立即一致。整体架构分层：前端（请求验证）、网关（安全防护）、核心服务（业务逻辑）、数据库（事务管理），职责清晰，便于扩展。”
6) 【追问清单】
- 问题1：Saga模式补偿逻辑如何保证幂等性？
回答要点：补偿步骤需设计为“与原步骤相反”（如扣款失败则加钱），且通过唯一标识（订单ID）确保重复补偿不重复执行。 - 问题2：支付网关延迟回调导致的一致性问题如何处理？
回答要点：核心服务设置超时（如30秒），超时则主动发起补偿（回滚余额）。 - 问题3：如何防止刷单攻击？
回答要点：结合用户行为分析（IP、设备、下单频率）、支付渠道风控（银行卡交易记录）、订单状态监控（短时间内重复下单）。 - 问题4：数据库事务隔离级别如何选择？
回答要点：选择REPEATABLE READ（避免脏读），通过读写分离优化性能。 - 问题5：高并发下如何优化？
回答要点：消息队列削峰填谷，数据库读写分离，缓存（Redis）存储热点数据（如用户余额）。
7) 【常见坑/雷区】
- 补偿逻辑错误：Saga模式中补偿步骤遗漏或顺序错误，导致数据不一致。
- 一致性模型混淆：强一致性场景用最终一致性，导致业务错误。
- 安全措施不足：只加密不验证签名，导致重放攻击；未考虑支付渠道风控。
- 分布式事务选型不当：2PC阻塞或Saga补偿逻辑错误。
- 数据库隔离级别选择不当：如READ COMMITTED导致不可重复读，影响业务准确性。