初探队列消息：普通http同步请求、基于线程池的异步请求、基于消息队列的请求三者的比较

最近忙完了手头的项目，终于有时间研究之前一直落下的消息队列了，顺带手又看了一下多线程异步请求，加上最传统的http同步请求，正好可以拉出来做个比较，废话不多说，走起！

场景设计：三个用户同时向系统发送一个请求，要求系统进行处理；

通过这个场景设计，我们来看看不同请求方式的表现：

1、普通http同步请求：系统同时接收到了这三个请求，由于是同步方式，因此需要按顺序分别处理用户1、用户2、用户3的请求；

这是一个学过java，写过接口的童鞋都会使用的操作，三个请求被分配到了一个线程中，就像三辆汽车行驶在单车道上，如果车道里车辆不多，那没问题，道路畅通，“城市”（系统服务器）通行状态良好，但如果到了车辆通行的“高峰期”（高并发），那么所有“车辆”都将堵在城市里（请求会拥塞到服务器端），造成城市交通的“拥挤”，甚至是交通“瘫痪”（服务器拥塞、死锁、直接宕机），影响整个城市的发展！

2、基于线程池的异步请求：系统同时接收到了这三个请求，此时系统内部创建了一个线程池，会为这三个请求分配三个闲置的线程，通过异步的方式去处理这三个请求，这样1、2、3的请求无需排队，都能被及时处理，不过由于三个线程要同时执行，对服务器的性能就是一个考验，在服务器性能足够支撑的情况下，这种方式无疑是最佳的；

为了避免出现1的那种情况，作为“城市规划师”的你，决定升级城市的交通（升级服务器），拓宽车道（设置线程池），将车道升级到三车道，这样城市的通行能力（系统性能）就增长到了原来的三倍！原本三辆车要挤到一条道路上，现在三辆车被分配到了三条道上（三个请求分配给了三个线程），从而解决了拥堵的问题。然而，随着城市的不断发展壮大，更多的“车辆”（请求）涌入城市，而且道路由于负载过重，也出现了损坏（服务器硬件损耗），天气不好的情况（网络状况不好）也常常出现，城市交通又再次每况愈下...

3、基于消息队列的请求：用户的三个请求先分配到一个队列消息中（通常这个队列会放到另一台服务器中，与系统服务器区分开），系统一直在监听着这个队列的请求消息，一旦系统处理完当前请求，就会从队列中取出下一条消息，以此类推。在这种模式下，及时系统所在服务器宕机，也不会影响队列中的请求，待服务器恢复后，队列中等待的消息仍可以被系统继续处理，这种方式可以代偿性的解决高并发的问题，代价就是请求的等待时间，如果是一些短时间高并发但又不需要及时响应（如秒杀）的请求，可以采用这种方式。

由于城市预算的问题（服务器性能受限），道路无法再进行拓宽，但还是有源源不断的车辆涌入，再继续这样下去，城市又将陷入瘫痪！无奈之下，你只好想了一招权宜之计：在城市入口处设立关卡，车辆在城外排队（队列消息），在保证城市安全流量的基础上，在交警的监控下（监听队列消息），放行车辆入城。这样虽说一定程度上影响了车辆入城的速度（请求速度），但是保证了城市的稳定（服务器稳定）和车辆本身的安全（请求不会丢失）！

综合看下来，多线程当然是速度最优的方式，不过它比较依赖服务器的配置，由于都是在系统内部进行，也存在这请求丢失的风险；队列消息是性价比最优的方式，不吃配置，请求不会因系统的问题而丢失，而且队列消息所在的服务器一般都比较稳定（毕竟没有什么业务操作），不过它无法提升访问速度；其实呢，每种方式都有利有弊，最重要的还是要看你面对的业务逻辑和实际情况。

这篇是纯理论，以后有时间，我也会从代码的角度来谈谈具体的实现。

最后，希望本文对你的“城市规划”，有所帮助！