中间件心智模型：连接、队列、分区、副本与背压

一句话模型

中间件的本质是管理“跨进程传递的状态”：连接维持会话，队列缓冲时间差，分区提供顺序和并行，副本提供容错，背压防止过载。

核心概念

1. 连接

连接是有状态且昂贵的资源。TCP 需要握手、维护序列号、处理超时和重传；TLS 还要额外握手。连接池复用已建立的连接，降低延迟，但会引入池大小、空闲超时、最大生命周期和借出等待等问题。代理和网关通常终结客户端连接，再向后端建立另一条连接，两层连接数要分别计算。连接泄漏的表现往往是“服务还活着，但新请求排队或超时”。

2. 队列

队列把生产者和消费者在时间上解耦，用来削峰、重试和异步化。消息通常需要确认机制，确认之前 broker 要保留消息；确认之后才允许删除。由此产生 at-least-once、重复消费和死信队列。队列深度和消息年龄比瞬时速率更能反映积压。队列不是无限缓冲，磁盘、内存和保留策略都会成为上限。

3. 分区

分区是并行和顺序的单位：同一分区内有序，不同分区之间没有全局顺序。Kafka 用消息 key 的哈希决定分区，消费者组把分区分配给成员，一个分区同一时刻只由一个成员消费。分区数决定消费并行度上限，也影响 rebalance 成本和元数据开销。增加分区会改变 key 到分区的映射，可能破坏同一 key 的顺序保证。

4. 副本

副本把同一份数据放在多个节点上，提供故障转移和读扩展。写入通常先到 leader，再复制到 follower；同步复制保证确认时副本已写入，异步复制延迟更低但可能丢数据。Kafka 的 ISR、Raft 的 quorum、Redis 的主从和 Elasticsearch 的分片副本，语义各不相同。副本不是备份：误删除和逻辑错误会同样复制到所有副本。

5. 一致性

一致性描述多个副本或多次读写之间，观察者能看到什么顺序。强一致要求读到的都是最新确认的写入；最终一致允许短暂滞后。分布式系统还要处理幂等、重复消息、事务边界和 schema 兼容。CAP 不是“三选二”的口号，而是在网络分区时必须在可用性和一致性之间做取舍。业务侧通常用幂等键、版本号和补偿来弥补弱一致。

6. 背压

当生产者速度持续高于消费者，积压会落到队列、内存或磁盘，最终表现为延迟上升、内存溢出或写入失败。背压是把压力反馈给上游：限制并发、阻塞生产、丢弃低优先级请求、扩容消费者或降级。没有背压的系统会在过载时一起崩溃，而不是优雅地变慢。限流、连接池上限、队列长度和消费者并发都是背压的具体形式。

概念关系

生产者 → 连接/限流 → 分区日志 → 副本复制 → 消费者组 → 确认位点
              ↑                              ↓
              └──────────── 背压 ←────────────┘

数据从生产到确认，每一段都有容量和超时；背压把下游的慢反馈到上游，避免缓冲被击穿。

常见误解

• 把 Kafka topic 当成普通队列，忽略分区顺序和消费位点。
• 认为分区越多吞吐越高，忽略 key 倾斜、rebalance 和元数据成本。
• 有副本就认为数据安全，不验证复制延迟、备份和恢复。
• 把 Redis 主从或集群当成强一致系统，忽略异步复制和故障切换窗口。
• 连接池越大越好，结果把数据库连接数打满。
• 重试能解决过载，实际会放大流量并引发雪崩。
• 认为消息中间件能保证端到端 exactly-once，忽略消费端副作用。

读完自测

合上页面，先回答，再展开对照。

1. Kafka 如何保证同一业务实体的消息顺序？增加分区会带来什么影响？
2. 副本为什么不能替代备份？
3. 消费者变慢时，背压可以通过哪些方式体现？不加背压会怎样？

相关条目

• middleware 分支 — 全部中间件条目
• middleware-learning-path — 中间件学习路径
• kafka-cheatsheet — Kafka 速查
• redis-cheatsheet — Redis 速查
• nginx-cheatsheet — Nginx 速查
• database-selection-roadmap — 数据库选型