Connections and channels - ApsaraMQ for RabbitMQ - Alibaba Cloud Documentation Center

A connection is a physical TCP link between your application and ApsaraMQ for RabbitMQ. A channel is a lightweight virtual connection multiplexed over that TCP link. All Advanced Message Queuing Protocol (AMQP) operations -- declaring queues, publishing messages, consuming messages -- happen on channels, not directly on the connection.

Connections

A connection handles underlying network tasks such as IP address resolution, TCP handshake, AMQP protocol negotiation, authentication, and routing. Establishing a connection requires approximately 15 TCP packets. Because of this overhead, connections are expensive to create and should be long-lived.

A large number of short-lived connections consumes significant network and server resources. At high rates, frequent connection creation can trigger SYN flood protection, causing the ApsaraMQ for RabbitMQ instance to stop responding.

dg_connection

Channels

A channel is a virtual connection established on top of a physical TCP connection. Each connection can carry multiple channels. When a connection closes, all its channels close with it.

To connect a large number of applications to ApsaraMQ for RabbitMQ for sending and receiving messages, establish a reasonable number of connections and reuse multiple channels within each connection. This approach reduces system resource usage compared to opening a new TCP connection for each operation.

dg_channel

Usage notes

Use persistent connections

Open connections at application startup and keep them for the entire application lifecycle. Do not open and close connections for each publish or consume operation.

If your workload requires frequent channel creation, reuse a stable set of connections and create multiple channels within them. For limits on connection and channel open rates, see Limits.

Separate producer and consumer connections

Use at least one connection for producing messages and a separate connection for consuming. ApsaraMQ for RabbitMQ applies flow control (back pressure) to connections that publish faster than the instance can process. If producers and consumers share a connection, flow control on the publishing side can delay consumer acknowledgments, degrading consume throughput.

Use one channel per thread

Multiple threads can share a connection. However, channels are not thread-safe in most client libraries. Give each thread its own channel instead of sharing a channel across threads.

// Anti-pattern: sharing a channel across threads
Channel shared = connection.createChannel(); // Not thread-safe

// Recommended: one channel per thread
ExecutorService executor = Executors.newFixedThreadPool(4);
for (int i = 0; i < 4; i++) {
    executor.submit(() -> {
        Channel ch = connection.createChannel();
        // Use ch for this thread's publish/consume operations
    });
}

When multiple processes share a connection, avoid frequently opening and closing it. Otherwise, a ChannelNotFind error may occur.

Prevent consumption skew

When only a few connections handle a large volume of messages, consumption can become unevenly distributed across consumers. To prevent this:

Increase the number of connections per consumer, or add more consumers.
Make sure each consumer establishes the same number of connections.
Maintain at least 30 total consumer connections as a guideline.

Quick reference

Guideline	Details
Connection lifecycle	Persistent. Open at startup, close at shutdown.
Channel lifecycle	Open per thread or per operation batch. Close when no longer needed.
Producer vs. consumer	Separate connections to isolate flow control.
Thread safety	Share connections across threads. Do not share channels.
Minimum consumer connections	30+ total to avoid consumption skew.
Rate limits	See Limits.