解读

1. 场景定位：国内互联网大促、短视频上传、金融影像平台等常见 5 万并发，签名 URL 是入口流量闸门，一旦 RT 上涨或失败率飙高，全链路雪崩。
2. 瓶颈本质：签名计算（HMAC-SHA256+URLSafeBase64）CPU 密集；临时密钥、STS Token 刷新带来额外 RT；缓存穿透/雪崩导致回源放大；单机网卡小包打满；SLB/Nginx 默认 4K Header 截断。
3. 面试考点：能否把“高并发+安全+成本”三角矛盾拆成可量化指标（QPS、RT、CPU、错误率、密钥轮换周期），并给出可落地的三级防线（算法层、缓存层、架构层）。

知识点

1. 签名算法
   • 阿里云 OSS V4 签名规范：CanonicalRequest→StringToSign→Signature，三次哈希，主耗在 HMAC-SHA256。
   • 国标 SM3/SM4 在政务云必须合规，但性能低于 SHA256，需硬件加速。
2. 缓存模型
   • 本地 LRU：Caffeine 0.9 命中率 95%，单实例 2 ms 内返回，但多节点重复计算。
   • 分布式 Redis：单 key 热点 5 万 QPS 时，10 MB/s 网卡打满，需分片+本地兜底。
   • 一致性哈希：防止 STS 换钥瞬间缓存雪崩，采用“密钥版本号”作为哈希因子，而非“用户 ID”。
3. 性能指标
   • 单核 2.5 GHz 可跑 12 万次 HMAC-SHA256（256 B），5 万并发需 4 核纯计算，再留 50% 余量。
   • 签名 URL 长度≤2048 B，避免浏览器/旧版 Android 截断。
4. 国内合规
   • 等保 2.0 要求“密钥 90 天内轮换”，不能为了性能把有效期调到 7 天。
   • 若走金融云，需通过“国密局商用密码产品认证”，签名算法不可随意替换。

答案

1. 压测建模
   a. 用 PTS/JMeter 构造 5 万并发，梯度 5→20→50 k，观察 CPU 利用率>70% 即瓶颈。
   b. 监控签名服务 Pod 的 p99 RT、错误码 503 比例、Redis 网卡 In/Out。
2. 算法层优化
   • 预计算：把“bucket+object+expires+versionId”四元组做 key，有效期对齐到整 5 分钟，减少时间戳漂移带来的重复计算。
   • 批量签名：同一用户一次申请 50 个 URL，用一条 HMAC 计算多段签名，降低 40% CPU。
   • 硬件加速：在阿里云 ECS hfc7（Intel QAT）或腾讯云 SR1 实例，启用 crypto-engine，HMAC 性能提升 3 倍。
3. 缓存层设计
   • 二级缓存：本地 Caffeine 10 秒+Redis 300 秒，本地 miss 才走 Redis，Redis miss 才计算；本地命中率 90%，Redis 命中率 8%，回源 <2%。
   • 热点分片：对“bucket+dateHour”做 64 槽位，Redis 集群单槽位 QPS 降到 800，避免单 key 热点。
   • 雪崩防护：STS 换钥前 30 秒双写旧/新密钥，缓存 value 带“密钥版本”字段，平滑切换。
4. 架构层扩展
   • 无状态水平扩展：签名服务容器 CPU 限制 2 核，HPA 阈值 60%，5 万并发跑 8 Pod，单 Pod 6 k QPS。
   • 边缘计算：在 CDN 边缘节点做“URL 签名验证”改“签名下发”，把 5 万并发拆到 200 个 PoP，源站只需 500 QPS。
   • 长连接复用：客户端 HTTP/2 keep-alive 60 s，减少 TLS 握手 20% CPU。
5. 结果验证
   • 压测报告：5 万并发持续 30 min，p99 RT 从 180 ms 降到 25 ms，CPU 利用率 55%，错误率 0，Redis 网卡 480 Mb/s 未打满。
   • 合规审计：密钥轮换日志、加密机调用记录保留 180 天，通过等保测评。

拓展思考

1. 如果业务允许“私有读”，可改用“STS 临时密钥+PostObject”方式，把 5 万并发读转成 5 千并发写，签名压力下降一个量级。
2. 在 Serverless 场景（函数计算 100 ms 计费），签名算法若超过 20 ms 会显著增加费用，可考虑把预计算签名下沉到常驻容器，函数仅做缓存读取。
3. 未来 QUIC/HTTP3 0-RTT 早期数据上传，需把“签名+token”放在 QUIC Crypto Stream，避免重复签名，但国内 CDN 节点普遍未开启 QUIC，需评估回源链路。