⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处网络「网络」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

说说这两种的区别，各自适合什么场景？

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

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

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

1.使用JDK提供的异步框架ExecutorService。

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

2.将消息发送到消息队列，如使用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感兴趣的应用都可以订阅，比如送积分的服务，送优惠券的服务，开辟云盘空间的服务等等

java领域有很多这种类比， ehcache 和 redis对比做缓存啊， java并发库和redis锁对比并发啊等等，都可以提出你这类型的问题

最初设计时，建议用ExecutorService，但最好用定时器把队列数量打出来，这样就能对阻塞情况有所了解。

当服务器负荷升高、线程池阻塞到危及程序正常运行时，可以考虑升级为中间件。（其实，很少有网站的访问量能达到这种负荷的，要么是程序本身有Bug。）

尽量用ExecuteService，如果不是涉及到：

跨服务业务。比如订单、支付
业务去耦合。比如有些情况上级业务不用知道下级执行是否成功，比如log日志等

使用Mq会带来设计上的复杂性：网络抖动怎么办？最大队列长度怎么设置？超时时间又设置多少？Qos又设置为多少？消费者多少个比较合适？channel cache size又该设置为多少？业务线可能都是用同一个Mq，你占资源太多，或者设计不当导致整个Mq故障（比如你不确认消息），开发同志们难道不来撕你么？

为什么非要多加个组件呢？能不用尽量不用

芋道源码 —— 纯源码解析博客

【393期】面试官：使用消息队列还是直接使用线程池异步处理？各自适合什么场景？

1.使用JDK提供的异步框架ExecutorService。

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