最近项目上线，一直在压测，关于mq的并发优化问题

  1. 首先是链接模式的区分，这里的链接模式我们默认选用的是channel，但是在压测时候出现了tps波动很大的情况，所以必须要对此进行优化操作
    channel模式：
    使用springboot链接rabbitmq的默认链接模式，此模式的特点是在链接时一个应用与rabbitmq链接只开辟一个connection，在connection中使用connectionFactory链接池开启多个channel链接，这样多个请求可以服用channel链接，节约了传输资源并且提高了效率，但是，在有限的connectionFactory中的链接池中的channel不够用的使用，生产者的主动请求是会被rabbit直接拒绝的，这块需要注意，在高并发的情况下我们需要考虑是否需要这种模式
    connection模式：故名思意，这种模式的特点在于当应用与rabbitmq进行链接时，是可以开启多个connection通道的，这样每个connection通道中又可以缓存多个channel链路复用，可以大大提高我们整个mq的并发量，但是不好的地方在于我们在使用的时候开启多个connnection需要大量的资源消耗，以及当程序中的并发量达不到时，多出来的channel开启也会导致资源的浪费，所以具体使用的规划，是需要我们依据业务的规划来决定的
    我们可以使用一个单例的Connection对象创建多个Channel来实现数据传输，但是在channel信息比较大的情况下，Connection带宽会限制消息的传输。那么需要设计Connection池，将流量分摊到不同的connection上。
  2. 下面来介绍一下我们使用的connectionFactory是个什么呢
    顾名思义，作为Connection的链接工厂，负责应用程序与MQ之间创建Connection链接，表示一个TCP链接，但是实际数据的传输是建立在Connection中的channel通道，Connection中的多个channel共用一个TCP的连接
    频繁建立TCP连接和channel连接是消耗性能的，于是我们希望可以共享connection或者channel。达到连接的复用。
  3. rabbitmq的请求处理线程池的缓存大小设置
缓存模式为Channel时：
connectionFactory.setChannelCacheSize(10);

表示设置的单个Connection中的channel的大小为10，要先获取到一个Channel，获取Channel时会先从缓存中找闲置的Channel，如果没有则创建新的Channel，当Channel数量大于缓存数量时，多出来没法放进缓存的会被关闭。

connectionFactory.setChannelCheckoutTimeout(600);

单位毫秒，当这个值大于0时，ChannelCacheSize代表的是缓存的数量上限，当缓存获取不到可用的channel时，不会创建新的channel会等待指定的时间，若到时间后还获取不到可用的channel，直接抛出AmqpTimeoutException。

缓存模式为Connectionl时：
connectionFactory.setConnectionCacheSize(10);

仅在CONNECTION模式下使用，指定connection缓存数量

connectionFactory.setConnectionLimit(600);

仅在CONNECTION模式下使用，指定connection数量上限。。

  1. 此外,除了MQ自身的参数设置之外，外界的物理条件同样也影响这MQ的并发
    如服务器网络带宽，内存，磁盘等等