设计一个交易系统的API接口（如下单、查询订单），需考虑安全性（防DDoS、防SQL注入、防重放攻击）和性能（限流、缓存）。请说明API设计要点、安全措施及性能优化策略。

三菱日联银行Global Markets难度：困难

答案

1) 【一句话结论】：设计交易系统API时，需遵循RESTful原则，通过API密钥+HMAC签名认证、令牌桶限流、Redis缓存订单状态，结合CDN/WAF防DDoS，并采用参数化查询防SQL注入、时间戳+nonce防重放，确保安全与性能平衡，核心是“安全认证+限流缓存+防注入重放”的协同设计。

2) 【原理/概念讲解】：

RESTful API设计：采用资源路径（如/orders）+ HTTP方法（GET/POST），符合资源操作语义，如POST /orders下单，GET /orders/{id}查询。
限流（Rate Limiting）：用令牌桶算法（Token Bucket），每秒发放固定令牌，请求消耗令牌，超限返回429，避免DDoS。类比：水桶注水，水满后溢出，控制流速。
缓存（Caching）：订单查询用Redis缓存（如order:{id}），设置过期时间（如5分钟），减少数据库查询，提升性能。
防SQL注入：所有数据库操作用参数化查询（如Java的PreparedStatement），将参数与SQL语句分离，防止恶意注入。
防重放攻击：请求头加入时间戳（如Unix时间）+随机数（nonce），服务器验证时间戳是否在有效窗口（如5分钟内），nonce是否唯一，确保请求新鲜。
安全认证：API密钥+HMAC-SHA256签名，客户端计算签名并放入请求头（如Authorization: Bearer <key>.<signature>），服务器验证签名，确保请求来源可信。

3) 【对比与适用场景】：

策略/组件	定义	特性	使用场景	注意点
限流算法（令牌桶 vs 漏桶）	令牌桶：按固定速率生成令牌，请求消耗令牌；漏桶：按固定速率流出请求	令牌桶：更灵活，可处理突发流量；漏桶：平滑流量，但响应慢	令牌桶：适用于交易系统，应对突发请求；漏桶：适用于实时通信（如视频流）	令牌桶需配置令牌数、填充速率，漏桶需配置桶容量、流出速率
缓存策略（内存缓存 vs 分布式缓存）	内存缓存：如Java的ConcurrentHashMap；分布式缓存：如Redis	内存缓存：速度极快，但容量小，适合热点数据；分布式缓存：容量大，可扩展，适合高并发	订单查询：分布式缓存（Redis），减少数据库压力	内存缓存需考虑线程安全，分布式缓存需一致性（如Redis的持久化）
防重放验证	时间戳+nonce	时间戳：验证请求是否在有效时间窗口；nonce：确保请求唯一	所有需要防重放的请求（如下单、查询）	时间窗口需平衡安全与性能，过短影响用户体验，过长易被攻击

4) 【示例】（伪代码/请求示例）：

下单接口（POST /orders）：
请求头：
```
Authorization: Bearer <api-key>.<signature>
X-Rate-Limit: <remaining> <limit> <reset>
```
请求体：
```
{
  "symbol": "AAPL",
  "quantity": 100,
  "price": 150.5,
  "side": "buy"
}
```
服务器处理：
1. 验证签名（HMAC-SHA256，密钥为API密钥）；
2. 限流检查（令牌桶，剩余令牌>0）；
3. 参数验证（symbol、quantity等非空）；
4. 防重放检查（时间戳在5分钟内，nonce唯一）；
5. 数据库插入订单（参数化查询）；
6. 缓存订单（Redis，key=order:{id}，value=订单JSON）；
7. 返回201 Created，包含订单ID。
查询订单接口（GET /orders/{id}）：
请求头：
```
Authorization: Bearer <api-key>.<signature>
```
请求路径：/orders/12345
服务器处理：
1. 验证签名；
2. 缓存检查（Redis，key=order:{id}）；
3. 若缓存命中，返回缓存数据；
4. 若缓存未命中，数据库查询（参数化查询），存入缓存；
5. 返回200 OK，包含订单详情。

5) 【面试口播版答案】：
“面试官您好，设计交易系统API时，我会从安全与性能两方面入手。首先，API设计遵循RESTful原则，资源路径清晰（如/orders），HTTP方法语义明确（POST下单，GET查询）。安全方面，采用API密钥+HMAC签名认证（防止未授权访问），结合时间戳+nonce防重放攻击（确保请求新鲜），用参数化查询防SQL注入（避免数据泄露）。性能优化上，限流用令牌桶算法（控制请求速率，避免DDoS），缓存用Redis缓存订单状态（减少数据库压力，提升查询速度）。具体来说，下单接口会先验证签名和限流，再检查防重放，最后写入数据库并缓存；查询接口先查缓存，缓存未命中再查数据库并缓存。这样既能保证安全，又能提升系统性能。”

6) 【追问清单】：

问题1：如何处理API版本管理？
回答要点：用路径版本（如/v1/orders），或请求头（如X-API-Version: 1），避免兼容性问题。
问题2：缓存失效策略如何设计？
回答要点：设置TTL（如5分钟），过期后自动清理；或主动失效（如订单状态变更时，删除缓存）。
问题3：限流后如何降级？
回答要点：当限流触发时，返回429错误，提示用户稍后重试，或提供备用路径（如异步通知）。
问题4：如何处理幂等性？
回答要点：订单ID唯一，服务器检查订单ID是否已存在，若存在则返回200 OK（已处理），避免重复下单。
问题5：日志记录如何设计？
回答要点：记录请求头（签名、限流信息）、请求体、响应码、耗时，用于故障排查和安全审计。

7) 【常见坑/雷区】：

忽略认证与授权：未验证API密钥或签名，导致未授权访问。
缓存击穿/雪崩：缓存失效时大量请求同时访问数据库，导致性能崩溃。
限流策略不当：令牌桶参数配置不合理，要么限流过松（无法防DDoS），要么过严（影响正常用户）。
未考虑幂等性：重复下单导致重复交易，影响业务逻辑。
安全措施过重：过度加密或签名，增加服务器计算负担，影响性能。