高可用是“挂了也能扛住”，需主动设计失败路径：对所有外部调用设 timeout 和有策略的 retry；状态存储必须用 Redis/PostgreSQL，禁用本地内存或文件；/health 端点须检查关键依赖且超时≤1s。
高可用不是“不挂”，而是“挂了也能扛住”
Python 服务本身没有内建的高可用机制，所谓高可用，全靠你主动设计失败路径。核心判断就一条：假设每个组件都会在任意时刻失效——包括你本地跑的 Flask 进程、依赖的 Redis 实例、下游的 requests.get() 调用，甚至本机的 DNS 解析。
用 retry + timeout 控制外部调用的雪崩风险
常见错误是写一个裸 requests.get("https://api.example.com")，网络抖动或下游超时直接卡死整个请求线程。这不是 Python 的锅，是你没设边界。
-
timeout必须显式传：至少拆成(connect_timeout, read_timeout)，比如(3, 8)，避免无限等待 - 重试不能无脑
while True：用tenacity或urllib3.util.Retry，限定次数（通常 2–3 次）、退避策略（如指数退避）和重试条件（只重试ConnectionError和5xx，不重试400或401） - 注意
session复用时，Retry对象要绑定到session.mount()，否则无效
状态存储别依赖单点内存或本地文件
用 dict 缓存用户登录态、用 json.dump() 写配置到 /tmp/cache.json —— 这类做法在单机开发时没问题，一上多进程/多实例就立刻失效或冲突。
- 会话、令牌、限流计数等有状态数据，必须进外部存储：
Redis（推荐）、PostgreSQL（强一致性场景），而不是memory或sqlite - 如果真要用本地缓存（如
functools.lru_cache），只允许用于纯函数、无副作用、参数可哈希的场景，且明确标注@lru_cache(maxsize=128) -
os.path.exists("/var/run/myapp.pid")这类文件锁，在容器重启或节点漂移后不会自动清理，容易误判“服务还在运行”
健康检查端点必须反映真实依赖状态
GET /health 返回 200 OK 不代表服务能干活。很多团队只检查自己进程存活，结果 Redis 断了、DB 连不上，K8s 还在把流量打过去。
立即学习“Python免费学习笔记（深入）”；
- 检查项必须包含关键依赖：尝试发一个轻量
redis.ping()、执行SELECT 1到数据库、调一次核心下游的HEAD接口 - 超时严格控制在
1s内，否则 K8s 的livenessProbe会误杀 - 不要在
/health里做耗时操作（如扫描磁盘、读大文件），也不返回敏感信息（如版本号、配置片段）
真正难的不是写几个 try/except，而是每次加一行调用前，都得问一句：它挂了，我的逻辑会不会静默错、漏、卡死？这个习惯比任何库都管用。
