前言
文本已收录至我的GitHub仓库，欢迎Star：github.com/bin39232820…
种一棵树最好的时间是十年前，其次是现在
絮叨
神游玄境。静座闭关，可见千里之外的人。
Redis前面几篇的文章链接：
都已经达到了神游了，肯定要去试试深浅嘛，走去面试去，嘻嘻
面试官：
小伙子,据说你天天赋异禀，年级轻轻已经是Redis的神游玄境了，那么接下来接我十剑，如果你能接到，我就服你。
六脉神剑：
我心里想，我去十剑，这他吗怎么顶的住，还好学了从零开始学Redis。然后轻描淡写的说"来吧!".
面试官：
小伙子接我第一剑：无忧
在你的项目中，有没有用过redis,为什么要用redis,redis为什么那么快
六脉神剑：
我靠，一来就三式，接吧。
是的面试官，我们的项目中redis用的太多了，可以说到处都有用到，比如 用来存token ,首页的缓存，搞活动时的排行榜。。。等等，我们用他的原因是因为在我们业务量越来越大的情况下 单机的数据库的性能达到了我们的瓶颈，所以引入了缓存中间件，redis为什么那么快
第一个 redis纯内存操作,
第二个 核心是基于非阻塞的IO多路复用机制，
第三个 单线程避免了多线程的频繁上下文切换问题
所以特别快，单机读的并发的能达到10W+，
还有我们的项目是分布式项目，我们用redis来做分布式锁。
面试官:
不错哦 接我第二剑：霜雪
既然你说你用了redis,那么有没有遇到 缓存穿透，缓存雪崩，缓存击穿呢？
六脉神剑：
我招太容易接了 各位读者不会的请点开下面的链接，这里就不一一说了。 大家可以先自己试着回答一下啊
面试官:
我去竟然用了别人的招式挡住了，再接我第三剑 昊阙
说说redis 的基本数据类型 还有什么高级的用法你了解的
六脉神剑：
我招也容易接了 各位读者不会的请点开下面的链接，这里就不一一说了。 大家可以先自己试着回答一下啊
面试官:
再来第四剑 动千山
说说redis的内存淘汰策略，和 redis的持久化机制
六脉神剑：
这招也简单呀 各位可以思考一下，最主要结合自己的项目来说 来谈谈你们自己的看法，或者理解
面试官:
第五剑 青霞
说说你对redis原子性的理解
六脉神剑：
这个得靠自己了，首先 一个事务是一个不可分割的最小工作单位,要么都成功要么都失败。
redis能保证原子性的原因：对Redis来说，执行get、set以及eval等API，都是一个一个的任务，这些任务都会由Redis的线程去负责执行，任务要么执行成功，要么执行失败，这就是Redis的命令是原子性的原因。 对于多个 api要实现redis的原子性也有2种办法 第一种就是 用redis原生的方法Transition 但是这种方式的话 效率不那么高 我们也可以用Lua脚本，把多个api 做成一个脚本里面 实现redis的原子性。
面试官:
我去，对redis的理解蛮深的嘛，看我第六剑 破军
Redis集群方案应该怎么做？都有哪些方案？
六脉神剑：
这个再从零学redis中讲的很清楚了，从主从 到哨兵 都带大家玩了一遍 ，大家可以想想怎么组织语言 ，不知道的可以看我下面的链接
面试官:
咦！这都难不倒你，看我第七剑 心剑
Redis如何做内存优化？
六脉神剑：
哈哈，这个简单。尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。
比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面。
面试官:
可以啊！小伙子，接这第八剑 铁马冰河
谈谈Redis线程模型
六脉神剑：
我去，这个真的有点难了，得了解很多东西了 文件事件处理器 Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。
消息处理流程
- 文件事件处理器使用I/O多路复用(multiplexing)程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
- 当被监听的套接字准备好执行连接应答(accept)、读取(read)、写入(write)、关闭(close)等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。
- 尽管多个文件事件可能会并发地出现，但I/O多路复用程序总是会将所有产生事件的套接字都推到一个队列里面，然后通过这个队列，以有序（sequentially）、同步（synchronously）、每次一个套接字的方式向文件事件分派器传送套接字：当上一个套接字产生的事件被处理完毕之后（该套接字为事件所关联的事件处理器执行完毕）， I/O多路复用程序才会继续向文件事件分派器传送下一个套接字。
其实这个用自己的话来总结 就是开始他们是可以并发的进来 用了IO多路复用 ，但是这些套接字会从队列过去到文件事件分派器 最后变成了 有序 同步的 概念了。
面试官:
倒数第二剑 大明朱雀
说说Redis哈希槽的概念？ 一致性hash和哈希槽的概念和区别
六脉神剑：
真的是一个比一个难 我去 不愧是大明朱雀呀
这个问题其实就是问 再集群环境下, redis 不同的key 存储到哪个节点的问题 ,
Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value
时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数， 这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大 致均等的将哈希槽映射到不同的节点。
用了哈希槽的概念，而没有用一致性哈希算法，不都是哈希么？这样做的原因是为什么呢？"
Redis Cluster是自己做的crc16的简单hash算法，没有用一致性hash。Redis的作者认为
它的crc16(key) mod 16384的效果已经不错了，虽然没有一致性hash灵活，但实现很简单，节点增删时处理起来也很方便。
面试官:
说说你用Redis是怎么实现分布式事务的 如果你的redis是集群的
面试官:
我靠牛逼，到这一步了，不会是天选之人吧，来接我最后一剑 天斩
其实也没啥好问题的 最后那几题算比较难的 还有很多简单的就不问你了，恭喜你被录用了 哈哈
六脉神剑：
好的，谢谢面试官，感觉国家。感谢从零开始学Redis 哈哈 拿到Offer了
其实还有很多面试题没讲的 redis也有很多知识点要学的，所以我们要再工作学习中继续努力，至少我们现在不是redis小白了 哈哈
借人家总结的图：
结尾
Redis系列完结了，感谢大家的支持，下期打算把 canal 学习一下 ，阿里开源的一个中间件，用于数据同步。因为canal 也用的比较多，大家一起进步，一起学习吧
因为博主也是一个开发萌新 我也是一边学一边写 我有个目标就是一周 二到三篇 希望能坚持个一年吧 希望各位大佬多提意见，让我多学习，一起进步。
