什么情况下异步操作使用消息队列而不是多线程

Redis提供了两种方式来作消息队列。 
一个是使用生产者消费模式模式， 另一个就是发布订阅者模式。 
前者会让一个或者多个客户端监听消息队列，一旦消息到达，消费者马上消费，谁先抢到算谁的，如果队列里没有消息，则消费者继续监听；’后者也是一个或多个客户端订阅消息频道，只要发布者发布消息，所有订阅者都能收到消息，订阅者都是平等的。

一、异步处理选择

1.消息队列和多线程两者并不冲突，多线程可以作为队列的生产者和消费者。
使用外部的消息队列时，第一是可以提高应用的稳定性，当程序fail后，写入外部消息队列的数据依旧是保存的，如果使用两步commit的队列的话，可以更加提高这个项目。

2.用线程的话，会占用主服务器资源，消息队列的话，可以放到其他机器上运行，让主服务器尽量多的服务其他请求。

3.解耦更充分，架构更合理
多线程是在编程语言层面解决问题
消息队列是在架构层面解决问题
我认为架构层面解决问题是“觉悟比较高的方式“，理想情况下应该限制语言层面滥用多线程，能不用就不用。

4.用线程池ExecutorService异步处理：我理解ExecutorService其实也是内部使用了队列（如LinkedBlockingQueue），所以从设计上，其实和使用中间件的消息队列是