Caching & Async
异步处理模式
Message Queue、Task Queue 与 Back Pressure
Async workflow 可以把原本顺序执行的流程拆开，降低请求的同步 latency，也适合做定期 aggregation 等重任务。
Synchronous vs Asynchronous
Synchronous：一步完成后才能进入下一步，用户要等待结果返回。
Asynchronous：任务在后台执行，用户不需要等待完成就能继续操作。
示例：
- 支付流程通常是 synchronous，需要即时确认
- 上传图片/视频常用 async，让用户继续浏览或离开页面
Message Queue
Message queue 接收、保存并传递消息。适用于同步执行太慢的场景，常见 workflow：
- 应用把 job publish 到 queue，并通知用户任务状态
- worker 从 queue 拉取 job，处理完成后回写结果
不会阻塞用户操作，job 在后台处理。例如发一条 tweet 时，客户端可能先看到内容，但真正推送到所有 followers 需要时间。
Redis 是简单易用的 broker，但消息有丢失风险。
RabbitMQ 很流行，但需要适配 AMQP 协议并管理集群。
Amazon SQS 是托管服务，但可能有较高 latency，且消息可能会被投递两次。
Task Queue
Task queue 接收任务及数据，执行并返回结果。支持 scheduling，适合后台计算密集型 jobs。
Celery 支持 scheduling，常用于 Python 生态。
Back Pressure（背压）
如果队列开始持续增长，queue size 可能超过 memory，导致 cache miss、磁盘 IO 增加，performance 变差。Back pressure 通过限制队列长度保持高 throughput 与稳定 response time。
当队列满时，客户端会收到 “server busy” 或 HTTP 503，稍后重试。常用 exponential backoff 做重试策略。
异步的缺点
- 对于简单计算或强实时场景，同步执行反而更简单；引入 queue 会增加 latency 与复杂度。