如果你的简历中有写到mq，那么面试官一般会问到如下几个问题，至少我在面试中经常常被问到，所以今天总结一下，有不对的地方还望多多包涵：
首先第一个问题，为什么要用mq？
如果这个问题你都没考虑过，那么说明你只是一个单纯会用mq技术的一个coder，而不是一个会独立思考的程序员，如果被面试官问到这个问题，你都没有回答上来，那么你的第一印象肯定会很差。
一、为什么要用mq？
（1）解耦：如果多个模块或者系统中，互相调用很复杂，维护起来比较麻烦，但是这个调用又不是同步调用，就可以运用mq到这个业务中。
（2）异步：这个很好理解，比如用户的操作日志的维护，可以不用同步处理，节约响应时间。
（3）削峰：在高峰期的时候，系统每秒的请求量达到 5000，那么调用 mysql 的请求也是 5000，一般情况下 mysql 的请求大概在 2000 左右，那么在高峰期的时候，数据库就被打垮了，那系统就不可用了。此时引入mq，在系统 a 前面加个 mq，用户请求先到 mq，系统 a 从 mq 中每秒消费 2000 条数据，这样就把本来 5000 的请求变为 mysql 可以接受的请求数量了，可以保证系统不挂掉，可以继续提供服务。mq 里的数据可以慢慢的把它消费掉。
二、使用了mq会有什么问题？
这个问题记住一个降低一个增加即可。
（1）降低了系统可用性 （2）增加了系统的复杂性
三、怎样选型mq？
如果你被问及这个问题，面试官主要是想看你选型的时候是否会比较架构的区别，是否满足业务需求。
| 特性 | activemq | rabbitmq | rocketmq | kafka |
| 单机吞吐量 | 万级 | 万级 | 十万级 | 十万级 |
| topic 数量对吞吐量的影响 | - | - | topic 可以达到几百，几千个的级别，吞吐量会有较小幅度的下降 | topic 从几十个到几百个的时候，吞吐量会大幅度下降 |
| 时效性 | 毫秒级 | 微妙级 | 毫秒级 | 毫秒级 |
| 可用性 | 高 | 高 | 非常高，分布式架构 | 非常高，分布式架构 |
| 消息可靠性 | 有较低的概率丢失数据 | - | 经过参数优化配置，可以做到 0 丢失 | 经过参数优化配置，消息可以做到 0 丢失 |
| 功能支持 | 完善 | 并发能力很强，性能极其好，延时很低 | mq 功能较为完善，还是分布式的，扩展性好 | 功能较为简单，主要支持简单的 mq 功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准 |
| 优劣势总结 | 非常成熟，功能强大；偶尔会有较低概率丢失消息；社区不活跃了 | 性能极其好，延时很低；功能完善；提供管理界面；社区比较活跃；吞吐量较低；使用 erlang 开发源码阅读不方便； | 接口简单易用；吞吐量高；分布式扩展方便；社区还算活跃；经过双 11 的考验 | mq 功能比较少；吞吐量高；分布式架构；可能存在消息重复消费问题；主要适用大数据实时计算以及日志收集； |
个人建议：
中小型公司，技术一般，可以考虑用 rabbitmq；
大型公司，基础架构研发实力较强，用 rocketmq 是很好的选择
实时计算、日志采集：使用 kafka；
四、怎样保证mq的高可用？
rabbitmq是比较有代表性的，因为是基于主从做高可用性的。以他为例，自行查阅以下模式。
rabbitmq有三种模式：单机模式、普通集群模式、镜像集群模式。
五、如何保证不被重复消费？
不通的消费队列都会有一个消费通知的机制，如：
rabbitmq提供了一个ack确认消息机制，
rocketmq返回一个consume_success成功标志
(1)比如，你拿到这个消息做数据库的insert操作。那就容易了，给这个消息做一个唯一主键，那么就算出现重复消费的情况，就会导致主键冲突，避免数据库出现脏数据。
(2)再比如，你拿到这个消息做redis的set的操作，那就容易了，不用解决，因为你无论set几次结果都是一样的，set操作本来就算幂等操作。
(3)如果上面两种情况还不行，上大招。准备一个第三方介质,来做消费记录。以redis为例，给消息分配一个全局id，只要消费过该消息，将<id,message>以k-v形式写入redis。那消费者开始消费前，先去redis中查询有没消费记录即可。
六、如何保证消费的可靠传输性？
每个mq都要从生产者丢失数据、消费队列丢失数据、消费丢失数据三个层面回答
(1) 生产者丢失数据
以rabbitmq为例，rabbitmq提供了transaction和confirm模式来确保生产者不丢失数据，事务机制，发送消息前，开启事务（channel.txselect()）,发送消息后出现异常，事务回滚（channel.txrollback()）,发送成功提交事务（channel.txcommit()）。
上面这种方式吞吐量会下降，因此生产上应该使用confirm模式居多。
一旦channel进入confirm模式，所有在该通道发布上的消息都会被指派一个唯一的id（从1开始），消息进来如队列后，rabbitmq会立即发送一个ack给生产者，其中包含了消息的唯一id，这就使得生产者知道消息已经到达了消息队列里。如果消息队列没能处理该消息，则会发送一个nack给生产者进行重试操作。
我要评论channel.addconfirmlistener(new confirmlistener() {
@override
public void handlenack(long deliverytag, boolean multiple) throws ioexception {
system.out.println("nack: deliverytag = "+deliverytag+" multiple: "+multiple);
}
@override
public void handleack(long deliverytag, boolean multiple) throws ioexception {
system.out.println("ack: deliverytag = "+deliverytag+" multiple: "+multiple);
}
});
(2) 消息队列丢失数据
消息队列丢失的情况一般是开启持久化硬盘配置，这个持久化配置可以和confirm机制配合使用，可以在持久化硬盘之后，发送一个ack给生产者，如果生产者收不到ack信息，会重发信息。
如何持久化硬盘：
①将queue的持久化标识durable设置为true，
②发送消息的时候将deliverymode=2
这样设置就算rabbitmq挂了，重启后也能恢复数据
(3) 消费者丢失数据
消费者丢失数据一般都是以为采用了自动确认消息模式。消费者收到消息后，rabbitmq会立即从队列里面删除该消息，这是情况如果消费者出现异常而没有及时处理该消息就会丢失数据。
解决方案：采用手动确认消息。
七、如何保证消息的时序性？
先进先出队列，比如linkedblockingqueue。
如对本文有疑问， 点击进行留言回复！！
利用python将Mysql信息以Excel文件并作为邮件附件发送
springmvc+mybaits+mysql上传表情Incorrect string value: ‘\xF0\x9F\xA4\xB4\xF0\x9F...‘ for
SpringCloud Greenwich集成Seata1.2.0详解说明(原创by ulwfcyvi)
mybatis generator生成代码库 与指定的库不一致 为其他库的同名表
网友评论