错误类型
数据库并发/事务错误（死锁导致事务回滚）

错误代码
ORD-SVC-DB-DEADLOCK-500

错误描述
在测试环境的并发压测中，批量更新库存（inventory）与订单明细（order_items）时发生死锁，导致事务回滚并返回 HTTP 500。该问题出现在跨表交叉更新的场景下，锁等待超过 3 秒且慢查询显著增加。

可能原因

• 不同代码路径的更新顺序不一致（例如 T1 先更新 order_items 后更新 inventory，T2 相反），形成锁顺序反转的死锁环。
• 单次批量事务过大，持锁时间长，叠加高并发导致锁等待积压并超时。
• 索引不充分或筛选条件不够精确，导致更广范围的行锁/范围锁，放大冲突面。

解决方案（含改造建议）

• 统一锁/更新顺序（改造建议）：在所有代码路径中强制一致的更新顺序（例如统一为先 inventory 后 order_items），并在获取锁时按稳定键顺序进行（如按 sku_id、order_id 排序）。
• 拆分批量与缩短事务：将大批次更新拆为小批次（例如每批不超过 N 条），在必要的逻辑点提前提交，降低持锁时长。
• 引入幂等重试机制：捕获死锁错误码后进行有限次数重试（如 3 次，指数退避），确保操作幂等以避免重复副作用。
• 优化索引与查询过滤：确保 inventory(sku_id) 与 order_items(order_id, sku_id) 等索引有效命中，避免全表扫描或大范围锁；仅更新命中的行。
• 错误映射与可恢复性（改造建议）：将死锁导致的回滚从 500 映射为可恢复的错误（如 409/423）并在响应中明确“可重试”，提升调用方的重试可用性（测试环境先验证）。
• 监控与阈值调优（测试环境）：观察死锁计数、锁等待时长、慢查询比例；在测试环境可适度降低锁等待阈值以更快暴露问题，但不要以阈值调整替代根因修复。

技术详情

• 环境：testing
• 事务ID：{txn_id}
• 冲突资源：
  • 表：order_items、inventory
  • 锁类型：行级更新锁（UPDATE），在相同 sku_id 与关联 order_id 的记录上产生交叉等待
• 典型冲突序列（示意）：
  • T1：UPDATE order_items WHERE order_id={oid} AND sku_id={sku} → UPDATE inventory WHERE sku_id={sku}
  • T2：UPDATE inventory WHERE sku_id={sku} → UPDATE order_items WHERE order_id={oid} AND sku_id={sku}
    两事务在相同键上以相反顺序持锁，形成循环等待。
• 观测信号：数据库死锁日志触发；慢查询增加；锁等待 > 3s；接口返回 500 且事务回滚。
• 建议日志字段（不含敏感数据）：request_id、{txn_id}、死锁标识、冲突表名集合、键维度（如 sku_id、order_id 的掩码/摘要）、重试次数与耗时。

• 错误类型：网络/安全配置错误（TLS 证书过期，影响出站 mTLS 握手）

• 错误代码：PROD.NET.TLS.OUTBOUND.CERT_EXPIRED

• 错误描述： 生产环境 API 网关与外部合作方使用的出站 TLS/mTLS 证书在凌晨到期，导致与合作方的 TLS 握手一致性校验失败。站点状态页出现大量连接错误告警；客户端报“SSL 证书无效/已过期”；内部服务自检正常，但所有经网关发往合作方的出站请求失败。影响涉及与合作方相关的功能调用，用户侧表现为超时/失败重试。

• 可能原因：

  1. API 网关出站客户端证书未按计划轮换，证书已到期。
  2. 合作方服务器证书（或中间根链）到期，网关验证失败。
  3. 仅一方已更换证书但对侧信任链/指纹白名单未同步，触发验证失败（在证书到期点同时暴露）。

• 解决方案：

  1. 立即处置（两端并行，先恢复可用性）
     • 网关出站客户端证书：
       • 从证书仓库/密钥管理（如 KMS/Secrets Manager）获取已预签的新证书与私钥，替换网关出站证书与链；热加载/滚动重启网关实例使配置生效。
       • 确认新证书生效：检查序列号与到期时间，验证握手成功（见“技术详情”中的验证命令）。
     • 合作方服务器证书：
       • 协同合作方尽快部署新服务器证书与完整中间链；如更换了中间 CA，更新本方信任根/中间链。
       • 若双方启用了证书指纹/序列号白名单校验，同步更新白名单。
     • 流量与稳定性：
       • 临时开启外呼断路器/降级（避免雪崩重试）；暂停/延后非关键定时任务对合作方的调用，修复后分批回放。
       • 在状态页标注事件与影响范围，保持 15 分钟级更新。
  2. 修复验证与回归
     • 使用 openssl 等工具对两端证书进行链路校验；确认所有网关实例均已加载新证书并清理会话缓存。
     • 观察监控：TLS 握手失败率、5xx 比例、P95 时延应在 5 分钟内回落到基线；抽样请求业务验证成功。
  3. 事后防护（避免再次发生）
     • 将证书到期前 30/14/7/1 天多级告警纳入 on-call；为出站客户端证书启用自动续期与零停机轮换窗口（重叠生效期至少 7 天）。
     • 将合作方证书与中间链监控纳入外部依赖健康检查；为白名单/信任库变更建立变更单与灰度流程。
     • 在运行手册中固化“证书到期应急流程”，并纳入演练。

• 技术详情：

  • 影响范围：
    • 环境：production
    • 方向：API 网关 → 外部合作方（所有出站请求）
    • 受影响功能：涉及合作方的全部接口调用（读写均受影响）；内部服务与入站流量不受影响
    • 起始时间：[DETECTED_AT - e.g., 2025-12-01 00:02:13 +08:00]
  • 证书信息（请以监控/证管实值替换以下占位符）：
    • 网关出站客户端证书（mTLS 客户端身份）：
      • 序列号：[CLIENT_CERT_SERIAL]
      • 到期时间（Not After）：[CLIENT_CERT_NOT_AFTER - e.g., 2025-12-01 00:00:00 +08:00]
      • 指纹（SHA-256）：[CLIENT_CERT_FPR_SHA256]
      • 证书链：需包含 [INTERMEDIATE_CA_COMMON_NAME]（如适用）
    • 合作方服务器证书（对端身份）：
      • 序列号：[SERVER_CERT_SERIAL]
      • 到期时间（Not After）：[SERVER_CERT_NOT_AFTER - e.g., 2025-12-01 00:00:00 +08:00]
      • 指纹（SHA-256）：[SERVER_CERT_FPR_SHA256]
      • 中间链完整性：必须包含 [PARTNER_INTERMEDIATE_CA_COMMON_NAME]
  • 典型错误日志样例（用于关联检索）：
    • x509: certificate has expired / certificate verify failed (CERT_DATE_INVALID)
    • javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_expired
    • SSL routines: ssl3_get_server_certificate: certificate verify failed
  • 验证与排障命令（示例）：
    • 查看证书属性（本地文件或密钥管控导出）：
      • openssl x509 -in client.crt -noout -serial -enddate -fingerprint -sha256
    • 验证对端服务器证书与链（替换主机与 SNI）：
      • openssl s_client -connect partner.example.com:443 -servername partner.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -serial -enddate -fingerprint -sha256
    • 网关实例滚动并清理会话缓存（按变更流程执行）：
      • 滚动重启网关工作负载，确保新证书被所有实例加载；清理 TLS session cache/重建长连接。
  • 监控/告警校验：
    • TLSHandshakeFailureRate、UpstreamConnectError、5xx_error_rate、mTLSAuthFailure 指标在修复后应恢复到基线阈值以下
    • 相关追踪维度：cluster=apigw, direction=egress, partner=[PARTNER_NAME], error_code=certificate_expired

备注：

• 若仅一侧证书到期，先修复到期侧并同步对侧信任配置；严禁在生产环境临时关闭证书校验或放宽 TLS 版本/套件以规避验证失败。