@(目录)
背景
为什么使用消息队列
都说学以致用，不少候选人为了丰富自己的简历，会说自己精通XXX语言，项目中使用了Redis、MQ，知道已经使用，但如果为为何使用，就回答不出什么道道来。
这种情况下，面试官会以为，你只是一个普通干活的，平时可能只是CURD操作，修补bug，只是了解项目一些细枝末节，对于项目的整体设计架构，没有自己的独立思考，这样人想达到中级工程师的水平也有点难啊，面试官会在心里对你的整体印象大大打折。
消息队列的为什么使用必须结合项目的场景来说。项目场景有高并发，低延迟的需求，可能需要引入消息队列，但引入消息队列同时也会带来一些问题，这是下一个需要考虑的问题。
消息队列引入的主要原因有三个：解耦、异步和削峰。
解耦
一般公司的项目，在构建初期，一个服务里面就揉进去很多功能，敏捷开发嘛，快速迭代上线。举个例子，S1系统产生的用户数据源，可能会被S2、S3系统调用，后来又新增了S4系统，每次有系统的增删，负责S1系统的开发人员都需要修改代码，测试，上线，简直烦不胜烦。
如果改为S1系统将数据打入消息队列，哪个系统想要使用数据，直接消费消息队列就ok了，世界真清净。谁来接入我谁来负责，我只用管打入消息队列是ok的就行。S1系统的开发人员可以悠闲喝茶知道别人怎么接入了！
异步
一般的服务，肯定会与存储打交道，涉及到存储一般有MySQL、MongoDB、Hbase或其他存储。如下图，假设，S1系统只是一些本地内存操作，耗时5ms，S2、S3写库为MySQL和Hbase，耗时分别是50ms和80ms，那系统的总耗时就是5+50+80=135ms。
虽然当前用户访问延时为135ms，速度也还可以了，但如果又增加了S4、S5系统呢，访问延迟是逐渐增加的啊，到时候就会有人抱怨你的系统做的太烂了。如果改为消息队列呢，S1将数据打入MQ，耗时5ms，总的系统延迟就是5+5=10ms，而且解耦了，再增加其他服务访问延迟还是10ms，网站做的666啊，速度飞快。削峰
任何公司的任何业务，都会有流量的高峰和低谷，每天00:00-6:00，系统访问低谷，请求并发量可能就几十个，一切很美好。但到了12:30-13:00，访问流量竟然能达到10000/s，也是佩服公司的运营人员和公司的产品啊，产品访问量大好啊，说明业务蒸蒸日上，但开发哥哥就没这么好过了，并发量大，对数据持久层的访问时个考验。
假设当前S1系统访问的MySQL还没有做分库分表的优化，那能抗住的QPS的上线就是2000左右。
高峰达到了10000/s啊，去做分库分表，申请资源又有些浪费，因为在流量低谷时，只有几十的qps，这时候使用消息队列就比较合适了。这里只是举简单的例子，实际的系统处理起来肯定没这么简单了。延迟太多用户可要被抢走了！
消息队列有什么优缺点
假如你说了这些，面试官心里应该默默赞许，小伙子不错嘛，优点基本都答出来了，那再问问你缺点。
万事都有两面性，有好就有坏。缺点大致有以下几个：
可用性降低
服务中引入的依赖越多，引入的外部组件越多，维护的成本就越高，本来你只是S1调用S2、S3服务即可。引入了消息队列，消息队列打入失败怎么办？消息队列挂了怎么办？怎么保证消息队列的稳定性？这些就需要后面再说了！
复杂度变高
消息重复消费怎么办？消息丢失怎么办？如果要求消费的消息有序又怎么搞？本来在一个S1里，这些问题都好解决，加了一个MQ，这下麻烦大了！
一致性
用户请求S1返回成功，是真的成功了吗？当然不是，这只是代表打入MQ成功了啊。但这是如果消费MQ的某个服务挂了怎么办？你怎么监控，怎么处理数据一致性问题，真是搞的头都大了。
引入消息队列，有很多优点，但同时也带来了很多缺点，但是为了提高系统的响应速度，高并发情况下还是要用的。
消息队列的选型
缺点说的也头头是道嘛，面试官已经悄悄的在背后竖起了大拇指，小伙子不错，有一定的架构思维，之道引入一个组件的优缺点。并不是只知其一不知其二，只知道干活的人！
那你们关于消息队列是怎么选型的呢？
这就要从各个消息队列的一些特性说起了。
对比之后：
一般来说，现在选择RocketMQ，阿里出品，也已经捐献给Apache，社区还算活跃。单机吞吐量及可用性也都可以满足需求，后续分布式扩展功能支持也较好。
如果数据量非常大，偏向于大数据领域的实时计算及日志采集处理，且要求高可用，Kafka绝对是不二选择！
重复消费你们是怎么解决的？
面试官又丢给你一个问题，重复消费，其实也就是消息幂等处理的问题？
首先什么情况会造成重复消费呢？
Kafka的consumer消费有个offset的概念，consumer消费数据之后，定期提交offset，如果提交过程中，系统无故宕机或重启或网络原因，提交失败，那consumer就还会从上一个offset开始消费数据，这就是重复消费。
重复消费是消息队列中非常常见的问题，只要保证幂等处理就可以，比如你可以用Redis或MySQL记录下以处理消息的唯一id，碰到重复处理的消息，直接忽略即可！
小伙子，你知道的太多了，我都想让你明天直接来上班了，但是不行，还是得让下一位面试官来做做面试的样子！😝！敬请期待下一期小灶！
程序员的小伙伴们，觉得自己孤单么，那就加入公众号[程序员之道]，一起交流沟通，走出我们的程序员之道！