AI Knowledge

外观

Python Web 网络、安全、部署与可靠性专项面试题 ​

目录 ​

1. 使用说明 ​

单一事实源为正式主题。回答始终区分协议语义、业务保证和实际部署证据。

2. 递进路线 ​

图：Python Web 生产能力 L1～L7 路线

替代文本： 从 HTTP 幂等进入身份授权、缓存消息、部署实现、生产排障、可靠架构与项目复盘。

图表加载中…

读图结论： 框架返回成功只是链路起点，生产面试最终要证明身份、状态、任务与发布能在故障后收敛。

2.1 主题专属状态图 ​

图：副作用请求结果未知的收敛路径

替代文本： 请求带幂等键进入处理中；明确成功或失败分别结束，网络超时进入结果未知，必须查询业务状态，已执行则返回原结果，未执行才在预算内重试。

图表加载中…

读图结论： 超时不是失败；不可逆副作用在结果未知时必须查状态或人工收敛，不能盲目重试。

3. L1～L7 压力面试 ​

第 1 题｜L1｜HTTP 幂等和业务幂等有什么区别？ ​

核心考察点｜ 方法语义与分布式结果未知。

面试官提问

POST 是否一定不幂等，DELETE 是否可以放心无限重试？

30 秒专业短答

RFC 中 idempotent 指多次相同请求的预期服务端效果与一次相同；PUT、DELETE 和 safe 方法具有幂等语义，但业务实现仍可能有非幂等副作用。POST 可通过稳定幂等键、唯一约束和结果记录变成业务幂等。超时表示结果未知，有副作用操作应先查状态，再在总 Deadline 和次数预算内决定重试。

深入展开

响应和日志可以不同；代理不能替业务猜测 POST 可重试。幂等记录要绑定主体、操作指纹和返回结果，防止同键异参。

小白解释

支付页面没返回不代表没扣款；同一订单号先查流水，而不是连续点击。

事实与证据边界

方法语义来自 RFC 9110，具体业务保证由代码、约束和故障测试证明。

  • 合格线｜ 超时结果未知、协议与业务分层；
  • 加分项｜ 同键异参、Deadline；
  • 工程证据｜ 幂等表、唯一约束、响应丢失测试；
  • 高频误区｜ “DELETE 永远可安全重试”；
  • 下一问｜ 认证和授权怎样避免越权？

第 2 题｜L2｜Session、JWT、CORS、CSRF 和权限怎样回答？ ​

核心考察点｜ 安全机制不混淆。

面试官提问

登录后为什么仍可能读取其他用户订单？CORS 能防吗？

30 秒专业短答

登录只完成认证，还要做功能、对象和字段级授权；查询 order_id 时必须把 tenant/user 数据范围加入受控策略，不能只信前端。CORS 是浏览器跨源读取策略，不是服务端权限；CSRF 利用浏览器自动携带 Cookie 发起非预期请求。Session 与 JWT 按撤销、共享状态、跨服务和密钥轮换权衡。

深入展开

JWT 验证签名、alg、issuer、audience、expiry；Payload 不存敏感明文。对象授权测试覆盖横向和纵向越权。

小白解释

验票证明是谁，航班权限决定能上哪班，座位权限决定能碰哪件行李；跨门规则不能代替安检。

事实与证据边界

具体身份协议按 IdP 和威胁模型核验。

  • 合格线｜ AuthN/AuthZ、CORS/CSRF 分开；
  • 加分项｜ 对象/字段授权和 JWT claims；
  • 工程证据｜ 策略、审计、越权测试；
  • 高频误区｜ “有 JWT 就安全”；
  • 下一问｜ 缓存和消息如何保持业务正确？

第 3 题｜L3｜缓存一致性和 MQ 重复消费怎么处理？ ​

核心考察点｜ 真值、最终一致与幂等。

面试官提问

先删缓存还是先写数据库？MQ 能否做到业务恰好一次？

30 秒专业短答

Cache Aside 常以数据库为真值，写事务提交后删除缓存，删除失败通过重试/Outbox/CDC 补偿，TTL 只是兜底；并发旧值回填还需版本或单飞策略。MQ 的 at-least-once 会重复，消费者用业务键、唯一约束和状态条件幂等，业务提交后 ACK。不能把 Broker 的投递语义说成外部副作用恰好一次。

深入展开

DB 与消息双写使用 Outbox；缓存是否允许陈旧由业务定义，余额等强一致路径不应依赖普通缓存判断。

小白解释

公告栏是缓存、账本是数据库；快递单可能重复送达，收件人按订单号只入账一次。

事实与证据边界

一致性保证必须由并发/重启/重复消息测试验证。

  • 合格线｜ DB 真值、补偿、消费幂等；
  • 加分项｜ Outbox 和旧值回填；
  • 工程证据｜ 版本、消息 ID、重复测试；
  • 高频误区｜ “ACK 后就绝不重复”；
  • 下一问｜ Nginx、应用 Server 和健康检查如何配合？

第 4 题｜L4｜Python Web 如何容器化并优雅发布？ ​

核心考察点｜ 生产请求链和生命周期。

面试官提问

liveness、readiness、startup 和 graceful shutdown 分别是什么？

30 秒专业短答

liveness 判断进程是否需要重启，readiness 判断是否接新流量，startup 保护慢启动阶段。终止时先标记 not ready、停止新请求，再等待 in-flight 和消费者到 Deadline，收敛任务并关闭池。镜像固定依赖、非 root、配置密钥外置；数据库变更用兼容迁移和可回滚发布。

深入展开

Nginx/LB 管入口连接与 TLS，Gunicorn/Uvicorn 管 Worker，框架管请求；探针不能固定 200，也不应因短暂下游故障形成重启风暴。

小白解释

航班停运先停止售票，再处理已登机旅客和行李，最后关闭柜台，而不是直接断电。

事实与证据边界

超时和信号行为按真实 Server、平台与配置演练。

  • 合格线｜ 三类 probe、摘流、收敛、关池；
  • 加分项｜ 兼容迁移与非 root；
  • 工程证据｜ 部署配置、滚动发布、kill 测试；
  • 高频误区｜ “接口能 200 就 ready”；
  • 下一问｜ 发布后 502/504 如何排查？

第 5 题｜L5｜502、504 和重试风暴如何排查？ ​

核心考察点｜ 端到端故障证据。

面试官提问

发布后间歇 502，随后大量 504，你按什么顺序处理？

30 秒专业短答

我先按时间窗口冻结发布和自动重试，必要时回滚/摘除异常实例；用代理 error log、upstream 地址、Worker 退出/启动、端口和 Trace 区分 502 的连接拒绝/无效响应。504 再分入口排队、应用、DB、上游和线程/连接池等待，并检查多层重试是否放大。修复后做滚动发布、慢下游和进程退出故障回归。

深入展开

状态码不是根因；超时预算要逐层递减，代理超时不应只机械调大。

小白解释

502 像转机柜台找不到下一班，504 像找到了但等太久；都要查实际航班记录。

事实与证据边界

不同代理定义和日志字段需按当前环境核验。

  • 合格线｜ 止损、代理、Worker、Trace、重试；
  • 加分项｜ 多层预算和故障回归；
  • 工程证据｜ error log、process、span、deploy revision；
  • 高频误区｜ “把 proxy timeout 调大”；
  • 下一问｜ 如何设计完整可靠的业务架构？

第 6 题｜L6｜如何设计可靠的 Python 订单/AI 任务服务？ ​

核心考察点｜ 安全、状态、任务和部署组合。

面试官提问

服务包含创建任务、流式查询、Redis、MQ 和外部供应商，怎么设计？

30 秒专业短答

API 统一认证、对象授权、幂等键和 Deadline；数据库保存任务真值与 Outbox，Redis 只做短期缓存/限流，Broker 与幂等 Worker 执行长任务。供应商超时进入结果未知并按外部任务 ID 对账；流式断开取消可取消等待，但不盲目撤销已提交副作用。入口、Worker、连接池和供应商都有容量、Trace、降级和优雅发布。

深入展开

状态机明确 accepted/running/succeeded/failed/unknown；敏感工具使用 SSRF、权限和审计门禁。

小白解释

行李系统用唯一单号、中央账本、中转队列和外部航司对账，旅客离开页面不等于销毁行李。

事实与证据边界

这是参考架构，具体组件和容量由目标项目证据决定。

  • 合格线｜ 身份、状态、Outbox、幂等、结果未知；
  • 加分项｜ 流式取消、SSRF、容量；
  • 工程证据｜ 状态图、Trace、kill/timeout 测试；
  • 高频误区｜ “Redis 锁保证全链一致”；
  • 下一问｜ 如何讲一次可靠性项目而不夸大？

第 7 题｜L7｜生产可靠性项目怎样复盘？ ​

核心考察点｜ 故障与改进证据。

面试官提问

请讲一次超时、重复任务或发布事故。

30 秒专业短答

我会按现象和影响、request_id/版本/日志/Trace 证据、临时止损、根因、长期修复、故障回归和防复发回答。亮点不是“加了 Redis/MQ”，而是结果未知能收敛、重复副作用被幂等约束、发布能摘流回滚。没有真实事故时明确说是风险演练，不虚构线上结果。

深入展开

明确个人修改的代码、配置、告警或 Runbook，以及当前仍未覆盖的灾备/容量边界。

小白解释

复盘要展示哪件行李在哪站丢失、如何找回，以及以后哪道扫码能提前阻止。

事实与证据边界

200/ACK/缓存命中都不是端到端业务成功的充分证据。

  • 合格线｜ 完整故障闭环与证据；
  • 加分项｜ 个人贡献、残余风险、切换条件；
  • 工程证据｜ Trace、状态、测试、告警、Runbook；
  • 高频误区｜ 工具名代替问题和证据；
  • 下一问｜ 如果外部供应商无法提供幂等键和状态查询，你如何降低风险？

4. 自测与评分 ​

五维各 0～5 分，总分 20 且准确性至少 4。必须演练超时结果未知、重复消息、缓存删除失败、对象越权、SSRF、Worker kill 和滚动发布。

5. 事实边界 ​

HTTP 语义依据 RFC 9110，安全风险依据 OWASP；代理、身份、Redis/MQ 和部署能力按实际版本配置核验。所有故障均为训练演练，除非有项目证据。

6. 总结 ​

一句话记忆： 生产可靠性要让身份、请求、缓存、消息和发布在超时、重复、重启和越权条件下仍能收敛。

  • HTTP 幂等不自动等于业务幂等；
  • 认证后仍需功能、对象和字段授权；
  • 缓存与 MQ 以数据库状态和幂等约束收敛；
  • Probe、摘流、关池和兼容迁移组成优雅发布；
  • 故障复盘必须有版本、Trace、状态和防复发资产。