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

昨天发布的《 缓存架构，到底设计些什么？ 》一文，评论里问“究竟啥时候用 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适合。

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

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

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

你，真的理解面试官问题的用意了么？