上海逸迅信息科技有限公司-Java后端-base西安已OC

一共两轮（技术+hr）

技术面

1.先简单的自我介绍一下

2.当时你们这个项目人员配备是怎么样的？

我引出了项目的背景...

3.讲一下你这段实习经历干了什么？

4.你再介绍一下你这个项目吧？

5.说一下redis常用的数据类型吧？

6.比如我现在要实现一个场景如何保存页面的一个点击量和用户量，你会怎么设计？（场景设计题）

我回答的是，在刚刚谈到的我提取出了一个关键信息就是无论一个用户访问了多少次同一个页面，都只算一次，那这个体现的其实就是唯一性，我会想到用set的数据类型进行存储，key放的是页面url，value放的是user_id。对于像页面点计量，其实我想到一个比较简单的，用string数据类型就行，因为他不用保证唯一性，key放的是页面url，value放的是count次数。

7.你说一下你的缓存一致性怎么做的，采取的是什么策略机制？

我回答的是主动更新数据库再删除缓存

8.你刚刚只是说了一个实现的大概过程，能具体说一下实现细节吗？比如现在我有一个帖子发生了变更？

好，我这个缓存一致性主要是对像文章热点数据进行一个缓存，虽然说是帖子的热点数据，但其实他对文章的实时性要求不高，因为一个帖子发布，是不怎么会去进行更改的。所以当帖子数据发生更改，首先我会先去更新数据库，然后将帖子变更信息投到消息队列中，再异步的由监听mq的消费者去删除缓存，当帖子下一次再被读取时，再加载到缓存中，保证的是数据的最终一致性。

9.对于像点赞数这种频繁发生数据变更的，是怎么保证数据库的数据一致性，也就是如何保证不漏请求？每一次都能更新数据库成功？

我在设计其实考虑到了这个问题，因为像点赞数这种频繁发生数据变更的，如果所有请求打到数据库都去写数据的话，可能会把db瞬间压垮，所以我在设计的时候没有用mysql去存储点赞量，而是将点赞数是保存到了redis中，数据的持久性是用redis保证的（RDB和AOF）。

思考：如果我一定要保存数据到数据库中呢？你会想到什么解决方案？

一定要保存到数据库的话就有一个点赞表然后方式的话是同步和异步，但是同步的话性能就很差，我觉得用异步会好些，当有点赞请求来了之后可以把请求保存到rabbitmq，他保证了消息的可靠性，如果追求高吞吐kafka会更好，同时mq又能起到一个消峰限流的作用，把请求都存到mq中，然后再根据mysql的消费能力，让mysql批次的来拉取数据比如一次100条，然后再对这100条消息做聚合，比如10条请求都是对同一个帖子的点赞，那就合成一次，减少数据库的写入次数，提高性能，对于数据库的更新成功是保证了数据的最终一致性。

10.面试官说我现在交付给用户一个后台系统，然后用户拿到系统发现其中有一个查询列表的接口响应很慢，造成这个问题的原因可能是什么，以及如何定位这些问题。（场景设计题）

嗯~我想一下，我回答的是如果你用的是redis，因为redis指令是不能保证原子性的，每一个redis指令都会建立连接，如果涉及到多条redis指令，我会想到用lua脚本来保证redis的的原子性。其次就是如果我要查询的数据量比较大，一次查询渲染就会比较大，耗费时间，而且可能造成OOM，我联想到了是MYSQL的一个批次查询。

后续总结补充：如果是在回答一遍，我会说首先这个可能分为两个层面去考虑，一个是网络层，一个是应用层。

对于网络层可能是运维方面需要考虑，像网络延迟，带宽，路由等等，那对于一个java应用层面开发者的话，我可能首先考虑服务器的排查，像线程堆栈分析通过jstack -l <pid> > thread_dump.txt ，内存分析 jmap是不是因为由于申请的内存空间比较大，然后都需要经行GC垃圾回收，然后对于MySQL层面的话，我会开启慢查询日志去定位执行慢的SQL，然后用explain关键字进行执行计划分析，看看要不要加索引，或者是加了索引看看有没有命中，索引会不会失效，还有就是如果数据量比较大的情况，要不要考虑sql语句的优化，分批次查询，不要一次查询了等，像如果用到了缓存层，和上面说所一样，如果涉及到多条redis指令，我会想到用lua脚本来保证redis的的原子性一次连接。或者查看是不是缓存已经失效了，需不需要重建等，其实我们现在说的都是一个事后的补救过程，其实我觉得我们还需要重视事前的一个压测检查，就是在系统交付给用户前我们内部先测试，通过一些成熟的压测工具像我之前有了解过先Prometheus+Grafana去来链路追踪，去尽可能避免这种问题。

11.redis中设置了key的一个过期时间10min，假设现在过了10min了，那他还会在内存吗？是立马被删除吗?

我当时没有马上回答出来，后来结束的时候问了面试官，才回忆起来，我那时候在想面试官是想我说内存的淘汰策略还是过期策略。

答案是：过期数据肯定是会删除的，不过不是立马删除，他要看你的的数据过期策略，在redis中提供了两种数据过期删除策略。第一种是惰性删除。在设置该key过期时间后，我们不去管它。当需要该key时，我们检查其是否过期。如果过期，我们就删掉它；反之，返回该key。第二种是定期删除。定期删除策略是redis会将设置了过期时间的key放到一个单独的字典(dict 其实就是哈希表)中,然后定时的,以一定的算法去每次扫描字典中的部分数据检查，如果发现数据过期，则删除，直到遍历扫完整个字典。定期清理的两种模式是：1) SLOW模式，是定时任务，定期去删除(执行频率默认为10hz，每次不超过25ms，可以通过修改配置文件redis.conf的hz选项来调整这个次数)；2) FAST模式，执行频率不固定（每次事件循环会尝试执行，但两次间隔不低于2ms，每次耗时不超过1ms）。Redis的过期删除策略是：惰性删除 + 定期删除两种策略配合使用。