消息队列处理高并发

用mq来将耗时比较长或者耗费资源的请求排队，异步处理，减轻服务器压力增加稳定性。
如果是高并发的实时请求，我个人觉得不适用这个方案。如果是为了高并发，我觉得应该朝解决高并发的方向考虑。集群、分布式、动静分离、数据库读写分离之类的。

web的话，只能客户端页面轮训处理结果。
因为，据我个人了解啊，现在web没有成熟的向客户端推送处理结果的技术。或者是我没弄好，如果有知道的，还望提点下。

 

把客户行为变为异步，就是提交后，只通知收到请求，需要客户再提交查询请求，查看结果

首先，我们来说一下为什么要使用MQ（消息队列）？

主要原因是由于在高并发的环境下，由于服务器来不及同步处理，请求往往会发生堵塞的现象，比如说大量的增加、修改（insert、updata）之类的请求同事到达mysql，直接导致无数的行锁，表锁、甚至最后请求堆积过多，从而触发too many connections错误。通过使用消息队列MQ，我们就可以异步处理请求，从而缓解系统的压力。

 

消息阻塞队列现在比较流行的RabbitMQ、redisMQ、activeMQ~！也就是专业的消息中间件，一般用于处理高并发的问题~！

这里面 RabbitMQ、redisMQ我没有研究过，我只了解过activeMQ~！在activeMQ中处理高并发问题时。我们首先就要知道是什么的高并发。消费者，还是生产者。

 

首先，我来说一下消费者的高并发处理，因为这个简单、好说一些~！它一般产生的原因是在activeMQ的队列中积压了数据的话，我们在spring中启动了listen，但是（读音重一点，停顿一下）我们在activeMQ的监控网页里面看到只有一个consumer（消费者）在运行，这时候就得说一说，activeMQ的运行机制了。它里面也就是activeMQ是默认将 取1000条数据交由一个consumer处理的，下一个1000才是由另一个去处理的。所以吧这个默认的值调一下就行了~！一般我们是在客户端的链接url里面，修改（tcp://ipaddr:61616?jms.prefetchPolicy.all=2），这样就公平分配了~！

 

这时候我们来谈一谈怎么去解决高并发的问题~！这里就要说到部署ActiveMQ了，其实说白了就是扩展你的应用程序，我简单的在网上查过一些资料，知道有差不多，大概有3中处理方式。垂直扩展、横向扩展、传输负载分流

 

1、垂直扩展

a) 垂直扩展简单来说就是一种用于增加单个ActiveMQ代理连接数的技术，这里还得顺便提一下，因为增加了代理链接数，所有，他的负载能力也增强了。一般默认的情况下，activeMQ是使用的阻塞IO来处理传输链接的，也就是同步io，一个链接分配一个线程，所有很明显的，我们只需要吧同步io换成异步io就行了，也就是非阻塞io（NIO）就行了，在ACtiveMQ配置文件中配置，至于具体的怎么配的，我不太记得了，网上有资料~！

b) 除了同步Io换异步io的方式。我们还可以根据每一个客户端的连接搞一个消息来分发线程，具体的好像是在系统参数(org.apache.activemq.UseDedicatedTaskRunner)设置为false来设置activeMQ使用将搞一个线程池，不过用这个方法的话，有个前提，就是需要有足够的内存来运行。这里还有隐藏的一个问题，就是cpu的负载，就是如果你在使用Open-Wire协议的格式消息。那么最好是关闭tight encoding选项（这里留个疑问给面试官。如果问，为什么会占用cpu很多，和怎么关~！就答：因为这个东西开启的话，cpu占用就太多了，至于怎么关，也是在系统参数文件里面配置）

2、横向扩展

a) 垂直扩展是一种单独的代理 ，第二个方式就是横向扩展也就是我们所说的使用代理网络来增加应用程序的代理数量，它的原理就是利用网络自动传递消息给所有互联网的具有对消息感兴趣的消费者的代理，所以，我们就可以配置客户端链接到一个代理的集群，随机的选择集群中的一个代理来链接。（这里留个疑问给面试官。如果问怎么弄？就回答：互联网嘛，我们通过url的参数配置就行了。）

3、传输负载分流

a) 而关于第三个方法，客户端的传输负载分流，就是前面两个（垂直和水平）的混合负载分流的方案，但是这里通常不适用代理网络，因为客户端程序会决定将哪个负载发送到哪个代理上、客户端程序需要维护多个jms链接，并且决定哪个jms连接应该用于哪个消息的目的地。

b) 这里有一个好处，就是由于没有直接使用网络连接，我们就降低了代理过量的消息转发，不需要进行额外的负载均衡处理。

http://blog.csdn.net/truong/article/details/73718621?readlog(详细的文章)