“选redis还是memcache”，面试官究竟想考察啥？

昨天发布的《缓存架构&＃xff0c;到底设计些什么&＃xff1f;》一文&＃xff0c;评论里问“究竟啥时候用memcache&＃xff0c;啥时候用redis”的比较多。

评论的回复中&＃xff0c;我提到&＃xff0c;自己会在面试中问候选人这个问题。不少同学质疑&＃xff0c;问这个问题有什么意义&＃xff0c;究竟想考察的是什么。这个问题很严肃&＃xff0c;且很重要&＃xff0c;它脱离了mc和redis本身&＃xff0c;涉及到技术人的自我要求。

我在面试中&＃xff0c;会如何向候选人提问&＃xff1f;

一般&＃xff0c;我不会预设任何问题&＃xff0c;更不会问我擅长的领域。

我会先看简历上写了什么&＃xff0c;比如“在项目中使用redis作为缓存存储”&＃xff0c;我可能就会问&＃xff0c;使用redis存储了什么&＃xff0c;key是什么&＃xff0c;value是什么&＃xff0c;为什么选择redis而不是其他缓存。

所以&＃xff0c;是不是问redis并不是重点&＃xff0c;重点是简历写了什么。如果在简历上写&＃xff0c;“在项目中使用hash作为内存存储结构”&＃xff0c;我可能就会问&＃xff0c;使用hash存储了什么&＃xff0c;key是什么&＃xff0c;values是什么&＃xff0c;为什么选择hash而不是其他数据结构。

不少听到我这么问的候选人&＃xff0c;先是一愣&＃xff0c;然后思索&＃xff0c;不同的候选人给出的答案完全不一样。

有一些候选人&＃xff0c;会说&＃xff1a;

• “架构师设计的&＃xff0c;我只是使用”

或者

• “公司要求统一使用redis作为缓存存储”

又或者

• “我比较熟悉redis”

这类回答&＃xff0c;是比较减分的&＃xff0c;作为技术人&＃xff0c;自己千万不能把自己当做“码农”&＃xff0c;而要把自己当做“设计师”&＃xff0c;日常工作中不能只是为了“完成交代下来的任务”。

还有一些候选人&＃xff0c;他会进一步解释&＃xff0c;例如&＃xff1a;

• “因为redis支持集群高可用&＃xff0c;redis集群支持固化&＃xff0c;所以选择了redis”

这类回答&＃xff0c;说明候选人对redis进行过专门的学习&＃xff0c;应该会非常好学。但是&＃xff0c;ta们未必经得起后续的系列问题&＃xff1a;

“既然缓存的是用户信息&＃xff0c;需要高可用么&＃xff1f;”

回复&＃xff1a;貌似不需要。

“既然缓存的是订单信息&＃xff0c;需要固化么&＃xff1f;”

回复&＃xff1a;貌似不需要。

“那为什么还要选型redis呢&＃xff1f;

回复&＃xff1a;额...

能看到&＃xff0c;这里&＃xff0c;redis的一些特性&＃xff0c;不能充分的作为&＃xff0c;选型redis的理由。

任何脱离业务的架构设计&＃xff0c;方案设计&＃xff0c;技术选型都是耍流氓。

这不是一句空话。

做技术方案&＃xff0c;技术选型的时候&＃xff0c;一定是针对业务需求来折衷的。

假如存储的是用户信息&＃xff0c;key是uid&＃xff0c;value是User实体&＃xff0c;当缓存挂了的时候&＃xff0c;如果不会因为流量压到数据库而导致雪崩&＃xff0c;此时缓存未必需要redis的集群功能。

假如存储的是订单信息&＃xff0c;key是oid&＃xff0c;value是Order实体&＃xff0c;只作为缓存使用&＃xff0c;允许cache miss读取数据库&＃xff0c;此时未必需要redis的固化功能。

选择&＃xff0c;因为在某个场景下&＃xff0c;ta适合。

其实&＃xff0c;我并没有对自己的提问&＃xff0c;预设任何答案&＃xff0c;只要候选人的思路是清晰的&＃xff0c;逻辑是自洽的&＃xff0c;即使给出的未必是最优的方案&＃xff0c;也是能让人眼前一亮。

我们&＃xff0c;因为项目的压力&＃xff0c;历史的包袱&＃xff0c;做出妥协性设计方案的次数还少么&＃xff1f;技术人&＃xff0c;清楚用什么&＃xff0c;清楚怎么用还不够&＃xff0c;更重要的是明白为什么。

技术人&＃xff0c;需要一些情怀&＃xff0c;多问自己一句为什么&＃xff0c;对自己有好处。

你&＃xff0c;真的理解面试官问题的用意了么&＃xff1f;