想更进一步和我一起玩耍，欢迎「搜索微信公号：跨界架构师」。

多说一句，任何方案都不是“银弹”。当每个 Channel 的流量不是很大时，复用单一的 Connection 可以在产生性能瓶颈的情况下有效地节省 TCP 连接资源。但是 Channel 本身的流量很大时，这时候多个 Channel 复用一个 Connection 就会产生性能瓶颈，进而使整体的流量被限制了。此时就需要开辟多个 Connection，将这些 Channel 均摊到这些 Connection 中，至于哪些 Channel 使用那个 Connection 以及Connection 与 Channel 之间的数量关系是多少，需要根据业务自身的实际情况进行调节。

Channel 在 AMQP 中是一个很重要的概念，大多数操作都是在信道这个层面展开的。比如, channel.exchangeDeclare、channel.queueDeclare、channel.basicPublish、channel.basicConsume 等方法。RabbitMQ 相关的 API 与 AMQP 紧密相连，比如 channel.basicPublish 对应 AMQP 的 Basic.Publish 命令。

可能你要问了，Channel 是不是也能像 Connection 一样被复用？这是个好问题，也是我们这次遇到问题的关键点。

结论是：可以，但是需要自己保证客户端对 Channel 访问的线程安全问题，因为在 Channel 的另一端，在 RabbitMQ 的服务端，每个 Channel 由一个单独的“进程”所管理，如果由于多线程复用Channel 导致数据帧乱序了，RabbitMQ 的服务端会主动关闭整个 Connection 。

因此，我们这次犯的错误就是多线程复用了同一个 Channel 导致的问题。所以，如果你也用到 streadway/amqp 这个库的话，需要特别注意这点。

不过，不同语言的SDK内部实现不同，我们分别使用 Golang 的 AMQP 库 streadway/amqp，和 RabbitMQ 官方提供的 C# 版本的库分别模拟过同样的场景，前者出现问题，后者却没有问题。

受限于时间原因，没有具体去核实 C# 库的源码，主观猜测是 C# 库内部多做了一些对于单个 Channel 的线程安全处理。

最后，我整理了三点使用 streadway/amqp 库的最佳实践，你可以看看：

golang 中使用 streadway/amqp 时，需要保证每一个线程单独一个 Channel。

streadway/amqp 库中的获取一个 Channel 的方法「Connection.channel()」是线程安全的。但是内部有一个 defaultChannelMax 的参数对 Channel 的数量进行了限制，默认是 (2 << 10) - 1，2047。这个需要注意：

我们可以通过调用 amqp.DialConfig(url string, config Config) 来调整个限制。

但是，并不是你调整了多少就是多少，还需要和 RabbitMQ 服务端的配置进行 min() 函数的处理，最终为两者的最小值。

Tips：特别是用云厂商的 MQ 产品，因为阶梯收费的原因会对很多性能参数做限制，需要格外关注这点，比如某版本的阿里云 RabbitMQ 实例限制是单个 Connection 最多 64 个 Channel）

正如前面对 Erlang 的简单介绍，Erlang 是一个天然支持多“进程”设计的语言，所以在 RabbitMQ 的服务端设计中，每一个 Queue，每一个 Connection 都是单独的一个“进程”。因此如果你想尽可能地压榨 RabbitMQ 性能，可以通过建立更多的 Connection 或者创建更多的 Queue 来实现，当然需要注意到 Connection 的创建和销毁的性能开销问题。