好家伙，某不知名大厂直接问我明天能不能来上班

前言

好家伙，我直接好家伙，面试官直接问我明天能不能来上班。事情的经过是安酱在面试广州某一大型（真的挺大的）政务相关公司，在跟面试官简单的聊了一些业务场景和功能实现之后（可能是真的缺人，也可能是安酱太优秀，直接吊打面试官），就问我明天能不能来上班。

当然了上面的是二面，主要考察的是安酱对整个项目的理解能力和对于解决某个实现难点能力。毫无疑问，这两个还是有点自信的。

最后，安酱在二面快结束时还是婉拒了。好哥哥们要说了，你是不是傻，这么快就拒绝了，是钱没给够吗（是的，没给够）。 我当然没那么肤浅，这点钱就想让我来上班，再见。哈哈哈哈，这都是我臆想的。主要是因为这个公司的项目是政务项目，好哥哥们懂了吧。

最恐怖的的不是这个，在一面的时候面试官问我有什么想问他的，我弱弱的问了一句: 您那边的技术体系是怎么样的？好哥哥们猜猜面试官是怎么说的。直接给我来了一句老系统的话已经运行快十年了，技术的话你能想到有多老那就是多老。细思恐极呀，好哥哥们。

下面的问题主要是一面问的，总的来说没有问一些太难的问题，也没有太多原理性的东西，安酱挑了一些比较有代表性的问题，然后答案的话有一些是我的原回答，有一些是结合了一些资料整理出来的。

MQ 如何确保消息的幂等性消费

这个问题的话是因为安酱简历上写了精通(熟悉)各大MQ引出来的一个问题。那要回答这个问题先要理解什么是幂等性。

幂等性指的是多次操作，结果是一致的。也就是说用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。那在MQ这一块的话，因为网络会发生抖动，MQ消费端和生产端都可能会出现超时，这样MQ就会出现重复发送和重复消费的情况。

那解决幂等性消费的关键就在于要解决消息重复消费的问题，那安酱是怎么说的呢？不会！！！

咳咳咳，回归正题。首先生产端需要在消息中添加一个唯一标识的字段。消费者这里可以分两种情况，第一种就是针对于业务或者数据上没有严格要求一致性的情况下，使用Redis来解决。也就是说在消息消费时先读Redis判断是否消息过，消费过则不处理，反之则消费，消费成功后往Redis添加一个标记。这种方式的话有概率会出现消息消费过了，但是Redis标记没有加上的情况。

第二种的话就是使用Mysql获取其他数据库的事务。在消费消息时，先往消息消费记录插入一条记录(这个表甚至可以就一个字段，就是上面提到的唯一标识(主键)字段)，然后在去做对应的业务逻辑操作。这里需要注意点第一就是需要在方法上添加事务。第二的话需要捕捉DuplicateKeyException，因为正常来说消费者都是要开启ACK机制的，如果不捕捉这个异常那这个消息是不会ACK的。这种方式的会就性能上来讲是没有第一种好的。

好哥哥们可以根据自己业务的实际情况来讲，最好的话把这两种方式都说一下。

MQ 在大数据量的情况下怎么处理

原场景是这样的。面试官问完RabbitMQ 如何确保消息的幂等性消费后，说如果有百万级的并发量你会怎么处理。

emmmmm，实话说，我现在还不知道面试官为什么会这么问，他究竟是出于什么考虑呢？

没想到的是，我竟然硬答了。首先的话RabbitMQ和RocketMQ单机的QPS大概是 10 万左右，但是由于我们的消费消息的业务逻辑肯定会涉及到数据库数据的修改，正常消息消费都是同步的，这就会存在在高并发量的情况下出现消息堆积的情况。

所以问题点就是消费者的速度与生产者发送消息的速度是不一致的。这个时候首先需要定位消费慢的原因，正常BUG排除后，RabbitMQ是可以支持并发消费的。比如一开始是一条一条消费，可以优化成一次性消费 10 条，这里需要注意的一点是一定要把ACK机制开起来，不然是会丢消息的。另外一块就是上面的幂等性消费也要处理，因为这种情况肯定会出现消息重复消费的。

如果说消费者的速度还是不够，那我们可以横向扩展。比如多加一些消费者实例，这里也有一点需要注意就是由于数据库是同一台，所以当消费过多的时候数据库是不一定能撑住的。别忘了使用MQ的初衷，异步、解耦、削峰。

如果说在非常紧急的情况下，消息一直堆积，快爆了怎么整。emmmm，快别问了好吗，我扛不住了。

如果在紧急情况下，我们可以做一个临时的方案，先弄多几个消费者，这几个消费者没有任何消息处理逻辑，就是消费消息，然后入库。入库完成后在跑定时任务或者其他的方式把消息处理了。

Redis 性能吞吐量瓶颈在哪里

这个问题安酱是简单的回答了一下，主要两点。

首先的话由于Redis是基于内存的，所以机器内存大小也决定了存放数据量的多少。

但是的但是，这里一定要说明一个点那就是实际上 Redis 有一种集群模式在某种程度上解决了这个问题。那就Cluster 集群模式，前提是好哥哥们知道这个东西。有的好哥哥会说了，这东西我不会呀，没听过也没有玩过。没关系，看我这篇你竟然还不知道 hash slot应付个面试那不是手到擒来吗

第二个瓶颈的话那就是网络带宽咯，这个没什么好说的。

Mysql 慢查询怎么优化

这个的话真的是仁者见仁智者见智了，看好哥哥们怎么吹，往自己熟悉的方向去吹就可以了。安酱这里就大概列一些点给好哥哥们参考一下。

1. 首先看SQL 的长度、关联表数量。如果一条SQL写的跟贪吃蛇一样，那么就要考虑SQL的拆分了。

2. 检查表索引设计是否合理，这个话要根据实际的业务场景来说，或者频繁查询的条件。当然咯，像状态类型这种只有 0 或者 1 的这种字段就不要加了，加了也没啥意义。

3. 检查SQL是否查询了一些业务场景中不需要的字段，比如说SELECT * FROM XXX。这里需要说明一下问什么不能这么写，把索引覆盖和回表大概说出来就差不多了。安酱这里就不弄得那么深了，好哥哥们自行百度一下。

4. 如果 1 和 2 都是没问题的，那就使用explain关键字。这里有一个坑点，就是面试官听到这个关键字的时候，会问这么一个问题。使用explain关键字你会关注那几个指标（实际上就是explain关键字的一些字段），这个好哥哥们最好能记得几个。

5. 通过explain 正常都能确认问题出现在哪里，正常都是使用了比如说OR、LIKE %xx%、条件字段函数操作 等等一些原因导致了索引失效。

安酱一般都是讲这几个，如果面试官在细问的话基本就入到了我们的套里面了。因为上面的这几个都是我们比较熟悉的，比如说第三个肯定是会细问的，好哥哥们自行研究一下问题就不大。嘻嘻嘻嘻

Feign 怎么解决跨域问题

emmmmm，到现在我还是不懂这是个啥问题，安酱是真的没遇到过。如果是请求头的传递那就简单，通过实现RequestInterceptor这个拦截器就可以了。但是面试官说不是这个，我搜了一圈也是没有找到答案。有好哥哥知道的吗，评论区教一下安酱，么么哒！！！

总结

以上就是安酱在面试的时候一些常见的问题或者回答的不是那么好的问题（没回答上的），还有一些问题忘记了。

当然，安酱上面的答案只是单纯的为了应付面试，好哥哥们在平时还是多多研究一下，最好有一个东西是自己不说精通，但是最起码很熟悉，毕竟底蕴的厚度决定了人生的高度。

扯远了，希望好哥哥们看了之后能成为面试一霸，把面试官按在地上摩擦！！！

好哥哥们点赞关注是我更新动力的源泉，最后日常求点赞、求关注

标签：哥哥,面试官,消费,安酱,上班,MQ,大厂,好家伙,消息
来源： https://blog.csdn.net/qq_34090008/article/details/115125071