阶段三讲的是 broker 内部怎么存消息，阶段四转到应用侧——客户端怎么用好 RabbitMQ。第一篇讲最基础的：连接（Connection）和信道（Channel）。
这看起来是个入门话题，但很多生产事故的根源恰恰在这里：连接泄漏导致 broker 连接数耗尽、Channel 用错导致并发受限、没分清 Connection 和 Channel 的生命周期导致资源浪费。理解这两层抽象的设计意图，是客户端性能调优和资源治理的起点。
两层抽象：Connection 和 Channel
RabbitMQ 客户端和 broker 的连接，是两层结构：
- Connection：一个真实的 TCP 连接。建立时要经过 TCP 三次握手 + AMQP 协议握手 + 鉴权，成本高。一个 Connection 对应 broker 上一个 Erlang 进程、一组收发缓冲区、一个文件描述符。
- Channel（信道）：Connection 之上的虚拟连接。多个 Channel 复用同一个 Connection 的 TCP 通道，每个 Channel 是一个独立的 AMQP 会话，有自己的 ID。
所有 AMQP 操作（声明队列、发消息、消费消息）都是在 Channel 上进行的，不是直接在 Connection 上。应用要先开 Connection，再在 Connection 上开 Channel，然后在 Channel 上操作。
为什么不直接用多个 Connection
一个自然的疑问：既然要并发，为什么不直接开多个 Connection，每个操作一个 Connection？答案在于资源成本。
Connection 是 TCP 连接，是操作系统级的重资源：
- 每个 Connection 占一个文件描述符。broker 的 fd 数量有上限（默认几千），开太多 Connection 会耗光 fd。
- 每个 Connection 在 broker 上对应一个独立的 Erlang 进程，占内存和调度开销。
- 每个 Connection 有独立的收发缓冲区（TCP 内核缓冲 + AMQP frame 缓冲）。
- 建立 Connection 要 TCP 握手 + 鉴权，耗时几十到几百毫秒。
如果每个并发操作都开一个 Connection，开几百个并发就会让 broker 承受几百个 TCP 连接的压力——fd、内存、CPU 调度全吃紧。
Channel 完全不同，它是轻量的虚拟会话：
- Channel 只是 Connection 内的一个 ID 标识，没有独立的 TCP 资源。
- 多个 Channel 共享一个 Connection 的 TCP 通道，复用缓冲区和 fd。
- 开一个 Channel 的成本极低，一个 Connection 上挂几百个 Channel 都不成问题。
所以 RabbitMQ 的并发模型是：用少量 Connection 承载大量 Channel，每个 Channel 做一件事。这就是「Channel 是并发单位」的含义——并发不是靠多开 Connection 实现，而是靠在一个 Connection 上开多个 Channel。
Connection 和 Channel 的典型用法
落到实际应用，一个推荐的连接拓扑：
- 应用开 1–2 个 Connection（生产一个、消费一个，分开避免互相阻塞）。
- 在生产 Connection 上开少量 Channel（生产通常不需要高并发 Channel）。
- 在消费 Connection 上，每个消费者一个 Channel（这样各消费者的消费互不阻塞）。
- 生产者和消费者用不同的 Connection，避免生产被消费阻塞（反之亦然）。
这种「生产消费分离 + Channel 复用」的拓扑，是性能和资源平衡的常用配置。
Channel 的几个关键约束
Channel 不是无限的，有几个约束要注意：
Channel 不是线程安全的。 一个 Channel 同时只能被一个线程使用。多线程并发用同一个 Channel 发消息，会导致 frame 交错、协议错误。正确做法：要么每个线程一个 Channel，要么用线程安全的客户端封装（如 Java 客户端的有些版本做了 Channel 的线程安全封装，但仍建议每线程独占）。
Channel 数量有上限。 broker 上 channel_max 默认 2047（每个 Connection）。虽然一般够用，但要注意不要无控制地开 Channel 导致超限。用完的 Channel 要及时关闭。
Channel 的生命周期。 Channel 可以随时开、随时关。但频繁开关 Channel 也有开销（协议握手），所以长生命周期的 Channel（比如消费者的 Channel）建议复用，不要每条消息开关一次。
Channel 错误会级联。 如果某个 Channel 上发生协议错误（比如 ack 了没收到的消息），这个 Channel 会被 broker 关闭，但 Connection 不受影响。应用要处理 Channel 关闭的回调，重新开 Channel。这是 Channel 隔离性的好处——一个 Channel 出错不影响其他 Channel 和 Connection。
一个常见的资源泄漏坑
新手最容易踩的坑：每处理一条消息就开一个 Connection（或 Channel），用完不关。结果是连接数持续增长，最终耗光 broker 的连接资源，整个应用连不上 RabbitMQ。
正确做法：
- Connection 在应用启动时建立，整个应用生命周期复用（应用关闭时才断开）。
- Channel 按需创建，但要在用完后关闭。长生命周期的消费者 Channel 可以一直开着。
- 用连接池（下一篇详谈）管理 Channel 的复用，避免手工管理泄漏。
监控上要盯着 broker 的连接数和 Channel 数（rabbitmqctl list_connections、list_channels）。如果发现连接数持续增长不下降，基本就是泄漏了。
心跳：保持连接活性
Connection 的一个相关机制是心跳（heartbeat）。TCP 连接本身是「静默」的——长时间没数据传输，连接可能已经被中间网络设备断开（比如防火墙的 idle timeout），但应用和 broker 都不知道。结果就是「连接看起来还在，实际已断」，发消息才发现失败。
心跳解决这个问题：应用和 broker 约定一个心跳间隔（默认 60 秒），定期互发心跳包。如果一方在约定时间内没收到对方的心跳或数据，就认为连接已断，主动关闭并触发重连。
心跳间隔的权衡：设太短（如 5 秒），网络稍微抖动就误判断连，频繁重连；设太长（如 5 分钟），真断连了要很久才发现。一般 30–60 秒是合理区间。如果部署环境里有防火墙/负载均衡器的 idle timeout（常见 60 秒），心跳要短于这个 timeout，否则连接会被中间设备悄悄断掉。
收束：理解连接模型才能做好客户端治理
Connection 和 Channel 是 RabbitMQ 客户端的基础设施。理解它们的两层抽象、资源成本差异、并发模型，才能正确设计客户端的连接拓扑，避免资源泄漏和性能瓶颈。
下一篇讲怎么在这套连接模型上做资源治理——连接池怎么设计、熔断怎么做、重连怎么处理。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。想跟完这套「图解 RabbitMQ」，欢迎关注公众号 「十三Tech」。
