Python

让 FastAPI 异步真正“不卡”：asyncio.create_task + to_thread 并发实践（含 MySQL 写入） 副标题 / 摘要 把同步重活丢给线程、把可并行的子流程拆出来并发执行，让你的 FastAPI WebSocket/HTTP 服务在高并发文件处理场景下保持流畅与可靠。适合需要在事件循环中混合 CPU 计算与阻塞 I/O 的工程团队。 目标读者 中级后端工程师、服务端架构师 正在用 FastAPI/asyncio 落地异步工作流、混合 I/O/CPU 任务的开发者 背景 / 动机 常见痛点： 在异步服务里不小心执行了同步 CPU/数据库操作，单个请求“卡住”事件循环，导致同一 worker 上的其它请求/WebSocket 心跳/进度推送都被拖慢。 CPU/数据库步骤彼此本无强依赖，却被串行放到一条链上，整体时延被“关键路径”拖长。 目标： 不改变外部行为的前提下，消除事件循环阻塞。 让独立步骤并发执行，缩短关键路径。 核心概念 线程（Thread）：同一进程内共享内存，切换开销低；CPython 受 GIL 限制，纯 Python CPU 计算难并行，但适合并发等待阻塞 I/O。 进程（Process）：独立内存、无 GIL 约束，CPU 计算可多核并行；切换/通信成本更高，参数/结果需可序列化。 异步（async/await）：单线程事件循环的协作式调度；只有在 await 时让出控制权，同步阻塞会“卡死”循环。 asyncio.to_thread：把同步函数放到后台线程，释放事件循环；不等于多核加速，但对阻塞 I/O 有实效。 asyncio.create_task：并发启动一个协程，让它和当前协程重叠运行；用于编排并发，而非解除阻塞。 实践指南 / 步骤 识别阻塞点（示例项目） CPU 构树/展平/序列化：HeaderTree.from_documents、flatten_dfs、FlatHeaderTree.to_dict 同步 MySQL 写入：file_tree_table.upsert_tree 用 to_thread 包裹同步重活（释放事件循环） 在 build_file_tree 中，将 CPU/DB 步骤放入 await asyncio.to_thread(...)。 并发编排，缩短关键路径 在 full_pipeline_async：在 split 后立即 create_task(build_file_tree(...))，并发执行图片/表格处理、重组、存储；返回前再 await 构树结果。 可选：事件屏障与互斥 如需“保证某步骤不早于构树完成”，用 asyncio.Event。 多协程修改共享状态，用 asyncio.Lock 保护原子更新。 观测与参数 MySQL 连接池每进程默认较小（示例为 2），必要时调大。 Uvicorn workers 控制进程数，提升隔离与吞吐。 可运行示例 非阻塞构树与持久化（替换 build_file_tree 内部）： ...

现代加密替代方案：AES‑GCM 与 ChaCha20‑Poly1305 实战指南（附 Python 示例） 副标题 / 摘要 这篇延伸读聚焦现代 AEAD 算法，解释为什么 AES‑GCM 与 ChaCha20‑Poly1305 是 RC4 的安全替代，并提供可运行的 Python 示例、常见陷阱与最佳实践。 建议先阅读配套文章《用 Python 还原 RC4 + JWT + 自定义 SSO Token 加解密》，理解遗留方案，再迁移到本篇的现代实践。 目标读者 后端/安全工程师（中级以上） 需要在服务间或 Web 客户端安全传输数据的工程团队 计划从自研/过时算法迁移到现代 AEAD 的项目负责人 背景 / 动机 RC4 等过时算法存在结构性弱点，且难以正确、安全地使用。现代 AEAD（Authenticated Encryption with Associated Data）算法在保证“机密性”的同时还能“认证完整性”，有效防止篡改与重放，API 更易用，错误空间更小——因此成为主流推荐。 核心概念 AEAD：同时提供加密（Confidentiality）与认证（Integrity/Authenticity）的模式。 Nonce/IV（随机数）：每次加密必须唯一（对同一密钥）。常用长度：12 字节。 AAD（Associated Data）：不加密但要认证的额外上下文（例如请求头、资源标识）。 Tag（认证标签）：解密时必须验证；任何修改都会导致校验失败。 Key Derivation（密钥派生）：通过 HKDF/Argon2/Scrypt 将口令或主密钥派生为会话密钥，避免直接使用弱口令。 实践指南 / 步骤 安装依赖 pip install cryptography 生成或派生密钥 服务到服务：使用随机 16/32 字节密钥（AES‑128/256），KMS 管理与轮换。 口令到密钥：使用 HKDF（或 Argon2/Scrypt）派生固定长度密钥，避免直接使用口令。 选择算法 AES‑GCM：硬件加速广泛（x86 AES‑NI），在服务端通用、高性能。 ChaCha20‑Poly1305：对移动/无 AES 加速的设备更友好，性能稳定。 Nonce 策略 每条消息使用唯一 Nonce（12 字节），推荐 os.urandom(12)，将 Nonce 与密文一起存储/传输（前缀写入）。 AAD 的使用 将上下文信息（版本、用户ID、消息类型等）作为 AAD 提供，增强完整性绑定。 密钥轮换 引入 kid（Key ID），支持多活密钥与平滑迁移。 可运行示例 以下示例仅演示用法。请结合 KMS、密钥轮换、权限隔离与 TLS，构建完整的生产级方案。 ...

用 Python 还原 RC4 + JWT + 自定义 SSO Token 加解密（含可运行示例） 副标题 / 摘要 这篇文章带你从 0 拆解 RC4 流加密、Base64/Hex 编码，以及基于 JWT 与自定义 SSO 的鉴权设计，并给出可以复制运行的 Python 示例。示例中的密钥与发行方均为占位值，切勿用于生产。 目标读者 Python 后端/测试工程师（中级） 对鉴权、令牌与基础加密流程感兴趣的开发者 想理解 RC4 工作方式与替代方案的安全入门读者 背景 / 动机 在实际项目中，我们常需要为 HTTP 或 WebSocket 请求附带令牌进行身份校验。常见做法包括使用 JWT（对称/非对称签名）或自定义的 SSO Token（例如对某段明文进行对称加密后再以 Hex/Base64 编码）。本文整理并复现一种组合方案：RC4+Base64/Hex 与 JWT/SSO 的加解密与校验流程，帮助你在测试或 PoC 中快速上手，同时理解其安全取舍。 核心概念 RC4：经典流加密（已不再安全）。通过密钥调度（KSA）与伪随机序列（PRGA）生成密钥流，与明文字节按位异或得到密文。解密过程与加密一致（同一函数）。 Base64 与 Hex：两种将二进制数据编码为可传输文本的方式。Base64 更紧凑；Hex 可读、调试直观。 JWT：JSON Web Token。Header.Payload.Signature。常包含 iss（发行方）、aud（受众/自定义）、iat/exp（签发/过期）。 自定义 SSO Token：一种自定义明文格式（示例采用 issuer_expire_ts_userSeqId_userId），经对称加密后再编码为 Hex，便于在 HTTP 头中传输。 限制与风险：RC4 已过时且不建议用于生产；如需兼容遗留系统，应仅在测试/过渡场景，且搭配 TLS、短周期、签名与回放防护。 实践指南 / 步骤 安装依赖 pip install pyjwt 设定占位常量（不要使用真实密钥/发行方） ISSUER = "demo-issuer" SECRET = "demo-secret-change-me" RC4KEY = "demo-rc4-key-change-me" UTE_ISSUER = "ute-demo" 实现 RC4 与常用编码包装 encrypt_string/decrypt_string：RC4 后 Base64 encrypt_hex_string/decrypt_hex_string：RC4 后 Hex 构造与校验 JWT（x-auth-token） aud = [Base64(RC4(user_id)), Base64(RC4(user_seq_id))] iss/iat/exp 等标准字段 构造与校验 SSO Token（x-sso-token） 明文 UTE_ISSUER_expire_ts_userSeqId_userId → RC4 → Hex 校验发行方与过期时间 运行演示，观察生成与校验结果 可运行示例（完整代码） 仅用于学习与测试，切勿将 RC4 用于生产环境。请优先使用现代 AEAD（AES‑GCM/ChaCha20‑Poly1305）。 ...