Architecture Patterns
Message Queues
Message Queue 的场景
Message queue 是一种 service-to-service 的通信方式，支持 async communication。它异步接收 producer 的消息，再投递给 consumer，让系统在高峰期也能保持稳定。
Queues 常用于大规模分布式系统的请求管理：写入 latency 在小系统里可预测，但在复杂系统里更不稳定；queue 就是 buffer + decouple 的组合。
核心概念
- Producer/Publisher：发送消息的一方
- Consumer/Subscriber：读取消息的一方
- Queue：存消息的结构（FIFO / priority / delay）
- Broker/Queue Manager：负责路由、存储、投递、ack
- Message：payload + metadata（headers、timestamp、priority）
How it works
消息会在 queue 中保存，直到被处理并删除。一个典型流程：
- Producer 生成 message（payload + metadata）
- Producer enqueue 到 broker
- Broker 存储（memory / disk / replicated）
- Consumer dequeue 并处理
- Consumer 发 ack，broker 删除 message
常见机制：
- Visibility timeout：consumer 领取后在时间窗口内完成，超时则重新投递
- Ack / Nack：成功 ack，失败可 nack 进入 retry
- Retry + DLQ：多次失败进入 dead-letter queue 便于排查
Queue types / patterns
- Point-to-point (Work Queue)：一条消息只被一个 consumer 处理
- Pub/Sub：一条消息被多个 subscriber 消费
- FIFO：严格顺序，通常带去重
- Priority Queue：按优先级处理
- Delay/Scheduled Queue：定时投递（比如 10 分钟后）
- Competing Consumers：多个 consumer 并行拉取，提升吞吐
Delivery semantics
投递语义决定了可靠性与复杂度：
- At-most-once：可能丢，但不重复
- At-least-once：不丢但可能重复（需要 idempotency）
- Exactly-once：最贵，通常依赖 transaction / dedupe
- Ordering：best-effort 或分区内顺序
Advantages
- Scalability：高峰期 write 入 queue，消费端可横向扩展
- Decoupling：producer/consumer 彼此不依赖，降低耦合
- Performance：async processing 提升吞吐
- Reliability：消息持久化 + retry + DLQ
- Load leveling：削峰填谷，避免瞬时 overload
Trade-offs
- Latency vs Reliability：持久化 + retry 带来更高 latency
- Complexity：需要监控 lag、幂等、重试策略
- Eventual Consistency：UI/数据状态会有 delay
- Operational cost：需要维护 broker、partition、retention
When to use
常见场景：
- Microservices：异步服务间通信，降低同步依赖
- Background jobs：image/video processing、email/SMS
- Event-driven：事件分发到多个系统
- Load spikes：请求排队，稳住 backend
- 可靠通信：服务短暂不可用仍能投递
UI/UX 设计建议（MQ 参与时）
- Pattern A：前台只安排任务 → 告知用户稍后完成（配合 polling / notification）
- Pattern B：前台先做“看起来完成”的部分 → 后台异步补齐（比如 fanout timeline）
Best practices
- Idempotency：consumer 必须可重复执行
- Retry policy：指数退避 + 最大重试次数
- DLQ：隔离坏消息，避免卡主主队列
- Backpressure：限制写入或动态扩容 consumer
- Observability：queue length、consumer lag、error rate
- Security：TLS、ACL、encryption at rest
RabbitMQ vs Kafka（快速对比）
- RabbitMQ：传统 broker，routing 灵活（exchange/queue），适合任务型消息
- Kafka：分区日志（distributed log），高吞吐、streaming/event 为主
- 选型：任务型 + routing 用 RabbitMQ；大量 event/stream 用 Kafka
Backpressure
当 queue 过大，可能超过 memory 或增加磁盘 IO，导致整体性能下降。Backpressure 通过限制 queue size 或 request rate 来保持吞吐和响应时间。队列满时，client 可收到 server busy 或 HTTP 503，再配合 exponential backoff 重试。