基础题，高频题。一般可以看做是深入讨论 Redis 的前奏。
回答这个问题的关键要看你平时准备了 Redis 哪些案例。而后你在整个回答的过程中你就可以稍微提及这些案例，但是不需要阐述细节，等待面试官进一步追问。而且还要注意的是，你选择的案例不能太大众化，要比你当前求职的岗位稍微高级那么一点点。
简单题。
这个问题其实稍微有点考验你的反应能力。因为正常我们会认为使用 Redis 是一件不言自明的事情——也就是大家都这么用，我也用。所以要是突然问一下你为什么用，你就会懵逼了。
回答这个问题的要点是要举几个例子证明没有别的中间件能做得比 Redis 更好了，而且最好是选择你项目中的、有特色的案例，从而引导话题并且刷出亮点。
简单题，在校招和初中级岗位面试中非常常见。
回答这个问题，你一边要把 Redis 有的数据结构都列举一边，一边要指出这些数据结构对应的底层实现。而后，你要进一步举几个例子，论述不同的数据结构可以用于不同的场景，最好就是用你项目经历中有特色的 Redis 案例。
最后你通过总结一般的选择数据结构的原则来刷出最后一个亮点。
略难的题，在 Redis 面试中比较常见，各个层级的程序员面试中都很常见。
你在这个问题之下，只需要回答到 Redis Sentinel 和 Redis Cluster 就可以了，细节可以等进一步追问。而后你可以通过总结 Redis 这种对等集群和主从集群混合的模式，在 Kafka 等中间件中也很常见，从而展示你对系统设计有深刻理解。
略难的题，高频题，在各个层级的面试里面都是高频题目。
回答这个问题，要把重点放在渐进式 rehash 上，这也是一个难点，并且你可以结合自己了解的别的类似结构进一步讨论，比如说语言层面上的哈希表。
简单题，所有的主从复制都差不多是一个样，你会一个就会全部了。
在回答这个问题的时候，你也不太需要把所有的细节都回答出来，可以等着面试官追问。
简单题，在各层级的面试中都有可能遇到，一般来说你面试的公司规模越大越有可能问到。
Redis Cluster 实际上也没啥特殊的，就是一个对等结构和主从结构的混合架构，唯一稍微特殊一点的就是引入了槽和槽分配的概念，你只要把这部分捋清楚就好了。而后，在面试中可以从跨槽问题、混合架构两个角度刷亮点。如果你在实践中有使用类似的技术，那么更加能给面试官留下深刻的印象。
简单题，一般如果要是聊到了 Redis Cluster，那么就会有极大的概率问这个问题。
回答这个问题，你可以谈及你借助类似的思想解决过什么问题，这样能够证明你对槽分配及对应的思想有深刻理解和丰富经验。
略难的题，因为绝大多数人都知道 Redis 的槽和槽分配，不少人也能记住 Redis 有 16384 个槽，但是基本没几个人会去琢磨为啥是 16384 个槽。
你在回答这个问题的时候，可以考虑使用我提供的类似槽分配思路的案例，深入讨论总结一般的槽个数的设计原则。
简单题，在校招、初中级岗位面试中常见。如果目标公司强调了可用性，也会比较常见。
要在这个问题下刷亮点，可以深入讨论 Redis 的主从选举机制的特色，即是借助 Sentinel 来选举的，并且选举的从节点是按照优先级来选的，而不是选拥有最新数据的从节点。
简单题，只有在深入讨论 Redis Sentinel 过程的时候才会提问。
你要是知道 Redis Sentinel 主从选举的过程，很容易就知道必然不是。但是你要刷亮点，就要系统分析数据延迟的各种可能。
略难的题，面试大厂的时候常见，尤其是聊到了 Redis Cluster 的时候。
在这个问题之下，你先回答槽迁移的基本过程，而后回答在迁移过程中如何处理读写请求，最后总结槽迁移这种渐进式的思想，刷出一波亮点。
略难的题。一般在大厂的中高级职级面试里面会比较常见，校招和初级岗位比较少考察，
这个问题很容易回答出来，但是不容易刷出亮点。因为基本的做法如槽迁移这种很容易想到，但是你需要有一些特别的骚操作，才能赢得竞争优势。
略难的题，在中高级岗位比较常见，校招和初级不太常见。
这个题目本质上就是问热点问题，你可以结合数据倾斜的内容来回答。实际上，你能答出重新设计 key 结构、手动哈希、拆分大 key 就能赢得竞争优势了。
略难的题，在中高级岗位面试中会遇到，校招和初级不太可能遇到。
这个问题的难点在于特别强调了槽上的 QPS 很高，而不是常见的多个槽合在一起 QPS 很高的热点问题。解决这种问题的思路就四个字：分而治之。
略难的题，在中高级工程师面试中比较常见，校招和初级工程师比较少见。
这其实就是一个典型的热点问题，你可以在回答的时候总结一般的热点问题解决思路、原则来刷出亮点。
略难的题，难点在你可能很难理解连锁更新的问题，一般不太常问。
注意在这个问题底下，你要先解释 ziplist 的基本结构，而后进一步解释连锁更新。目前来看，能够清晰解释连锁更新的原因、后果就差不多能赢得竞争优势了。
简单题，相比 ziplist 的连锁更新，quicklist 还是很好理解的。
如果你是校招生，那么你可以在考察数据结构中的 List 结构的时候将话题延伸到这里，这样能够凸显你的知识积累。
在回答这个问题的时候，你可以通过解释 quicklist 为什么要设计成结合了 ziplist 来刷亮点。
略难的题，难在你可能比较难理解连锁更新的过程，这个问题在问到了 ziplist 之后差不多可以说是必面了。
回答这个问题，你只需要清晰解释出来连锁更新就可以，并且提及 Redis 在后面引入了 listpack 来规避 ziplist 的连锁更新问题。
略难的题，难在你看一般的八股文，它们可能根本没有相关的内容，以至于你是在这里第一次听说到。
回答这个问题，只需要重点强调 listpack 和 ziplist 比起来，改进点在哪里。当然，如果你要是胆子大，就可以顺便喷一下 ziplist 的垃圾设计。
略难的题，从 listpack 中衍生出来的，一般来说只有你和面试官深入讨论 Redis 的数据结构，并且这个面试官还对 Redis 比较了解，才会遇到这个问题。
listpack 中唯一的理解难点就是这个从后往前遍历，你能回答出来就可以赢得竞争优势了。
简单题，高频题目，不管在什么层次的面试里面，如何解决数据一致性都是一个热点问题，长盛不衰。
你在回答这个问题的时候，可以先说标准答案先更新 DB，而后就要批判这个方案，从而引出其它解决方案，最终则是总结这些所有方案，都只是追求最终一致性而已。
简单题，这个应该说是最基础的数据一致性的问题了。
回答这个问题，不能仅仅回答先更新数据库这种，而是详尽分析各种可行的策略，最终可以引出结论——不管怎么做，都没有办法做到强一致性，只能追求最终一致性。
简单题，在校招和初中级岗位中比较常见。
本来 Redis 的过期删除其实没啥好说的，但是因为 Redis 有过一个 BUG 导致后面面试题就经常问了。你在回答的时候可以通过抽象总结一般的缓存如何解决过期问题来赢得竞争优势。
简单题，不太常问。
回答这个问题比较容易出现的误区就是只回答了扩容，而实际上扩容和缩容都会出现。要想在这里刷出亮点，就要仔细回答触发扩容和缩容的条件，并且进一步讨论总结缩容和扩容因子选择要注意的问题。
不管是扩容还是缩容，新的容量都是 2 的幂，你可以从两个角度来刷亮点。第一个是为什么使用 2 的幂，第二是一直使用 2 的幂来扩容有什么缺点。
简单题，在讨论了 rehash 的时候，就会深入讨论。在校招和初级工程师中比较常见。
略难的题，Redis 面试一般比较少考察持久化机制，因为在实践中就不推荐开启持久化，只有在一些很罕见的情况下才会考虑开启持久化功能。
你在这个问题下，可以深入阐述讨论 AOF 的刷盘机制，以及 COW 机制来赢得竞争优势。
简单题，但是是一个陷阱题。在校招、初中级岗位面试中非常常见。
回答这个问题的关键点就是指出 Redis 的线程模型的演进，而后强调一下多线程的模式不到逼不得已不要使用。
所有问到中间件 IO 模型的，你不要怀疑就直接答 IO 多路复用，这个话题很有可能将问题导向 IO 多路复用，你要有一个心理准备。
略难的题，之所以略难是因为这个题目很容易错，在校招和初中级岗位中比较常见。
Redis 之所以那么快，最关键就是两个：纯内存操作和IO多路复用，剩下的都不值一提。很容易犯的错误就是说 Redis 那么快是因为用了单线程模型，这个有点扯淡，要是单线程是原因，那么你的 Kafka 干嘛不用单线程？
虽然大部分情况下你可能都是凭借经验值随便搞一个过期时间，但是在面试中你就要说自己是认真思考过的，不是随便设置的。而后提供一两个案例证明自己确实很会搞过期时间。
略难的题。在社招中常见，校招基本不会这么问，毕竟你没什么工作经验。
这个题目如果你随便回答当然可以，但是最好是精心设计一个回答，引导过去你准备的复杂案例上。这里我会列举一些案例，你根据实际情况来挑选。
略难的题，主要是很多人没机会接触到监控 Redis 的事情，所以不知道怎么做。一般在社招里面有可能遇到，校招不常见。
在这个回答之下，如果你是在中小型公司里面工作的，那么你就可以装逼自己在公司内部接入了非常多的监控工具，改善了对 Redis 的监控情况。并且还可以进一步将这个东西纳入到你的可观测性面试方案中。
简单题，你要是听过就是简单题，你要是没听过就是难题。一般在社招里面会有，校招不常见。
回答这个问题，你在指出了 Redis 慢查询监控的方法之后，可以深入讨论慢查询的阈值应该是多少，从而赢得竞争优势。
略难的题，在社招中会遇到，一般在中高级岗位中考察较多。
这个问题是包含两层意思：怎么知道有大 key，知道了怎么解决。
回答这个问题，最好就是能引出一个具体的案例，然后借助这个案例来刷亮点。
