在这里，对AMQP协议“底层”功能的良好概念理解是有用的。我想说的是，AMQP 0.9.1选择部署的文档和API使这个问题特别令人困惑，所以这个问题本身是许多人不得不努力解决的问题。
博士TL;
连接是与AMQP服务器协商的物理TCP套接字。正确实现的客户端每个应用程序都有一个这样的线程安全的、可在线程间共享的客户机。
通道是连接上的单个应用程序会话。一个线程将有一个或多个这样的会话。AMQP架构0.9.1的特点是，这些线程不能在线程之间共享，并且应该在创建它的线程结束时关闭/销毁。当发生各种违反协议的情况时，服务器也会关闭它们。
使用者是一种虚拟构造，表示特定通道上存在“邮箱”。使用者的使用告诉代理将消息从特定队列推送到该通道端点。
连接的事实
首先，正如其他人正确指出的那样，连接是表示到服务器的实际TCP连接的对象。在AMQP中，连接是在协议级别指定的，与代理的所有通信都是通过一个或多个连接进行的。
Since it's an actual TCP connection, it has an IP Address and Port #.
Protocol parameters are negotiated on a per-client basis as part of setting up the connection (a process known as the handshake.
It is designed to be long-lived; there are few cases where connection closure is part of the protocol design.
From an OSI perspective, it probably resides somewhere around Layer 6
Heartbeats can be set up to monitor the connection status, as TCP does not contain anything in and of itself to do this.
It is best to have a dedicated thread manage reads and writes to the underlying TCP socket. Most, if not all, RabbitMQ clients do this. In that regard, they are generally thread-safe.
Relatively speaking, connections are "expensive" to create (due to the handshake), but practically speaking, this really doesn't matter. Most processes really will only need one connection object. But, you can maintain connections in a pool, if you find you need more throughput than a single thread/socket can provide (unlikely with current computing technology).
通道的事实
Channel是应用程序会话，为应用程序的每个部分打开，用于与RabbitMQ代理通信。它在单个连接上操作，并表示与代理的会话。
As it represents a logical part of application logic, each channel usually exists on its own thread.
Typically, all channels opened by your app will share a single connection (they are lightweight sessions that operate on top of the connection). Connections are thread-safe, so this is OK.
Most AMQP operations take place over channels.
From an OSI Layer perspective, channels are probably around Layer 7.
Channels are designed to be transient; part of the design of AMQP is that the channel is typically closed in response to an error (e.g. re-declaring a queue with different parameters before deleting the existing queue).
Since they are transient, channels should not be pooled by your app.
The server uses an integer to identify a channel. When the thread managing the connection receives a packet for a particular channel, it uses this number to tell the broker which channel/session the packet belongs to.
Channels are not generally thread-safe as it would make no sense to share them among threads. If you have another thread that needs to use the broker, a new channel is needed.
消费者的事实
消费者是AMQP协议定义的对象。它既不是通道也不是连接，而是您的特定应用程序用作发送消息的某种“邮箱”。
"Creating a consumer" means that you tell the broker (using a channel via a connection) that you would like messages pushed to you over that channel. In response, the broker will register that you have a consumer on the channel and begin pushing messages to you.
Each message pushed over the connection will reference both a channel number and a consumer number. In that way, the connection-managing thread (in this case, within the Java API) knows what to do with the message; then, the channel-handling thread also knows what to do with the message.
Consumer implementation has the widest amount of variation, because it's literally application-specific. In my implementation, I chose to spin off a task each time a message arrived via the consumer; thus, I had a thread managing the connection, a thread managing the channel (and by extension, the consumer), and one or more task threads for each message delivered via the consumer.
Closing a connection closes all channels on the connection. Closing a channel closes all consumers on the channel. It is also possible to cancel a consumer (without closing the channel). There are various cases when it makes sense to do any of the three things.
Typically, the implementation of a consumer in an AMQP client will allocate one dedicated channel to the consumer to avoid conflicts with the activities of other threads or code (including publishing).
就你所说的消费者线程池而言，我怀疑Java客户端所做的事情与我编写的客户端所做的事情类似(我的客户端基于. net客户端，但经过了大量修改)。
