使用消息队列还是直接使用线程池异步处理？各自适合什么场景？

Redis提供了两种方式来作消息队列。 

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

一、异步处理选择

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

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

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

4.用线程池ExecutorService异步处理：我理解ExecutorService其实也是内部使用了队列（如LinkedBlockingQueue），所以从设计上，其实和使用中间件的消息队列是差不多一致的。只是这里应用服务器既充当生产者又充当消费者，也是消息队列中间件的实现者。这种应该适合非分布式的架构，比如简单的只有一台服务器。

使用消息队列：消息队列（指activeMQ，rabbitMQ，kafaKa，Redis等）因为一般都是中间件，部署在其他机器，需要一定的网络消耗。

本着解耦的目的，使用后者更合理，因为应用服务器一般内存也不会太多，队列长度不易太长。让应用服务器只处理逻辑比较合理。适合分布式架构。

使用JDK提供的异步框架ExecutorService

threadPool.execute(new Runnable() {
    @Override
    public void run() {
        // 这里是异步处理的，比较耗时的逻辑，比如数据库操作
        userService.setDefaultAddressId(user.getUserId(), bookingForm.getAddressId());
    }
});

将消息发送到消息队列，如使用redis的List简单实现，然后后台线程消费消息

// 生产消息
redisTemplate.opsForList().leftPush(LOG_MQ_KEY, JsonUtil.beanToJson(httpRequestLog));
 
// 后台线程异步消费消息
String popValue = redisTemplate.opsForList().rightPopAndLeftPush(LOG_MQ_KEY, TEMP_LOG_MQ_KEY);

MQ可以更加有扩展性，支持的场景更多，而且支持消息自动的持久化，建议你看看 RabbitMQ 和 AMQP 协议，JMS 可以学但是没 AMQP 更加通用，redis的MQ还是不要用了，那只是一个附带的功能，kafka 是大数据领域的不适合做核心业务功能，只适合数据统计类应用的发送数据，因为他不确保消息100%不丢失，如此大的数据量丢一条无所谓的，不会对统计结果造成影响，但速度和吞吐量高很多。

线程池就不一样了，目前执行状态你无法知道，msg的消费率是多少都不知道，消息转发啊，消息拒绝啊，都的自己实现， 而且是单机版的，我目前用他来做一级转发，就是用他来将 event 异步发送出去，而不是让他异步做一些很繁重的工作，举例:

注册用户service方法，当事务结束后， 发送 RegisterUserEvent，这个发送就是用java线程池(如spring的)，然后 RegisterUserListener 监听到了这个 event 就发送 msg 到 Rabbit MQ，之后对注册用户这个Topic感兴趣的应用都可以订阅，比如送积分的服务，送优惠券的服务，开辟云盘空间的服务等等。

二、将redis发布订阅模式用做消息队列和rabbitmq的区别

1、可靠性

redis ：没有相应的机制保证消息的可靠消费，如果发布者发布一条消息，而没有对应的订阅者的话，这条消息将丢失，不会存在内存中；

rabbitmq：具有消息消费确认机制，如果发布一条消息，还没有消费者消费该队列，那么这条消息将一直存放在队列中，直到有消费者消费了该条消息，以此可以保证消息的可靠消费.

 2、实时性

redis:实时性高，redis作为高效的缓存服务器，所有数据都存在在服务器中，所以它具有更高的实时性。

3、消费者负载均衡：

rabbitmq队列可以被多个消费者同时监控消费，但是每一条消息只能被消费一次，由于rabbitmq的消费确认机制，因此它能够根据消费者的消费能力而调整它的负载；

redis发布订阅模式，一个队列可以被多个消费者同时订阅，当有消息到达时，会将该消息依次发送给每个订阅者；

4、持久性

redis：redis的持久化是针对于整个redis缓存的内容，它有RDB和AOF两种持久化方式（redis持久化方式，后续更新），可以将整个redis实例持久化到磁盘，以此来做数据备份，防止异常情况下导致数据丢失。

rabbitmq：队列，消息都可以选择性持久化，持久化粒度更小，更灵活；

 5、队列监控

rabbitmq实现了后台监控平台，可以在该平台上看到所有创建的队列的详细情况，良好的后台管理平台可以方便我们使用；

redis没有所谓的监控平台。

6、出入队性能

对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。
测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。
实验数据表明：
入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；
出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

三、总结

redis：      轻量级，低延迟，高并发，低可靠性；

rabbitmq：重量级，高可靠，异步，不保证实时；

rabbitmq是一个专门的AMQP协议队列，他的优势就在于提供可靠的队列服务，并且可做到异步，而redis主要是用于缓存的，redis的发布订阅模块，可用于实现及时性，且可靠性低的功能。

所以项目中所采用的Redis可能只是用于一个轻量级的应用，只是用于简单的发短信，邮件等通知，如果业务要进一步的扩展，如果需要消息队列的话，可能还需要用到专用的那些重量级的消息中间件比如rabbitmq等，他们的高可靠，负载均衡这些特性都是Redis所没有的。