昨天发布的《缓存架构，到底设计些什么？》一文，评论里问“究竟啥时候用memcache，啥时候用redis”的比较多。
评论的回复中，我提到，自己会在面试中问候选人这个问题。不少同学质疑，问这个问题有什么意义，究竟想考察的是什么。这个问题很严肃，且很重要，它脱离了mc和redis本身，涉及到技术人的自我要求。
我在面试中，会如何向候选人提问？
一般，我不会预设任何问题，更不会问我擅长的领域。
我会先看简历上写了什么，比如“在项目中使用redis作为缓存存储”，我可能就会问，使用redis存储了什么，key是什么，value是什么，为什么选择redis而不是其他缓存。
所以，是不是问redis并不是重点，重点是简历写了什么。如果在简历上写，“在项目中使用hash作为内存存储结构”，我可能就会问，使用hash存储了什么，key是什么，values是什么，为什么选择hash而不是其他数据结构。
不少听到我这么问的候选人，先是一愣，然后思索，不同的候选人给出的答案完全不一样。
有一些候选人，会说：
“架构师设计的，我只是使用”
或者
“公司要求统一使用redis作为缓存存储”
又或者
“我比较熟悉redis”
这类回答，是比较减分的，作为技术人，自己千万不能把自己当做“码农”，而要把自己当做“设计师”，日常工作中不能只是为了“完成交代下来的任务”。
还有一些候选人，他会进一步解释，例如：
“因为redis支持集群高可用，redis集群支持固化，所以选择了redis”
这类回答，说明候选人对redis进行过专门的学习，应该会非常好学。但是，ta们未必经得起后续的系列问题：
“既然缓存的是用户信息，需要高可用么？”
回复：貌似不需要。
“既然缓存的是订单信息，需要固化么？”
回复：貌似不需要。
“那为什么还要选型redis呢？
回复：额...
能看到，这里，redis的一些特性，不能充分的作为，选型redis的理由。
任何脱离业务的架构设计，方案设计，技术选型都是耍流氓。
这不是一句空话。
做技术方案，技术选型的时候，一定是针对业务需求来折衷的。
假如存储的是用户信息，key是uid，value是User实体，当缓存挂了的时候，如果不会因为流量压到数据库而导致雪崩，此时缓存未必需要redis的集群功能。
假如存储的是订单信息，key是oid，value是Order实体，只作为缓存使用，允许cache miss读取数据库，此时未必需要redis的固化功能。
选择，因为在某个场景下，ta适合。
其实，我并没有对自己的提问，预设任何答案，只要候选人的思路是清晰的，逻辑是自洽的，即使给出的未必是最优的方案，也是能让人眼前一亮。
我们，因为项目的压力，历史的包袱，做出妥协性设计方案的次数还少么？技术人，清楚用什么，清楚怎么用还不够，更重要的是明白为什么。
技术人，需要一些情怀，多问自己一句为什么，对自己有好处。
你，真的理解面试官问题的用意了么？
联系客服
