一、前言
作为一名Java程序员，Redis底层的一些原理是我们不必学会就可以搬砖工作的一种技能点，但是小奇为什么还要讲一下呢？难道就是为了浪费大家1分钟的宝贵时间，一个人1分钟，50万人就是1年，5000万人就是100年，赚了，小奇以一己之力成功搞挂一个人（血赚）。
二、面试
在一个晴朗的周日，我来到了一个陌生的园区（别问为什么是周日，问就是997，不过为了填饱肚子的打工人，只能明知山有虎、偏向虎山行），坐在陌生的会议室，等待HR小姐姐去叫面试官，此时我的心情和各位小伙伴一样五味杂陈，担心面试官问的会不会很难？问到我的知识盲区我该怎么办？一会自我介绍的时候要不要吹一下我和小奇的关系？
一位英俊潇洒，眼神犀利的面试官走了进来，看到他那犀利、仿佛能看穿一切的眼神 ，我在想要不然一会就不要20k了，要8k得了，这个面试官一看就不好糊弄啊，但是我想起来我来之前刚看了小奇的趣学编程系列，我已经完全学会了小奇的精髓，我顿时就来了底气，决定一会要30k，不给就学小奇赖着不走（哈哈）
面试官：小奇是吧，带简历了吗？
我：没带，现在彩印两块一张，我简历五张，每次面试都要花费十块，我朋友说了还没工作就先让你掏钱的工作不要去。
面试官：。。。那你靠什么来征服我，让我录用你
我：气质？
我只好从我的双肩包中拿出了我上午从其他公司面试官手中要回的简历，上午的情形是这样的。
上午的面试官：今天的面试就到这吧，回去等通知吧！
我：面试官你好，如果贵公司不打算录取我的话，能不能把我的纸质简历还给我，我下午还有一家面试。
上午的面试官：我说你的简历怎么皱皱巴巴，原来你一直在循环利用啊！这个症状出现多久了？
我：半拉月了。。。
（当我把皱皱巴巴的简历交给面试官后，这场面试才得以继续进行。。。）
三、Redis如何实现持久化
面试官：我看你简历上写的精通Redis？（哼，面试官轻蔑的一笑）
（看着面试官轻蔑的笑容，我忍不住拿出了我的Redis书籍推给了他）
我：这本书我倒背如流，你随便提问，答不上来算我输，答上来你就要为你的轻蔑向我道歉。
（此时面试官看着书若有所思，我怀疑他肯定在想他对这本书的了解程度吧）
面试官：好吧，那你先说一下Redis如何实现持久化的
我：Redis主要有两种持久化方式，一种是RDB（快照）方式，另一种是AOF格式。
面试官：可以说一说两者的区别和如何配置使用吗
我们可以想象一下我现在要记录一个人的姿势是什么样子的，那么我只能通过拍照，或者描述来记录
RDB（快照）方式可以理解我想知道目前一个人的姿势是什么样子的，那么我就给他拍一张照片，那么照片上就是他这个人的姿势。
AOF可以理解为动作的描述，我通过对这个人每一个动作的描述来知道这个人的姿势是什么样子的，比如这个人左手六、右手七、左脚画圆、右脚踢，那么我通过这些动作就知道这个人目前的姿势。
所以RDB快照就相当于将Redis中的数据保存了下来，恢复的时候只需要将照片拿出来，人根据姿势恢复就行了。
而AOF相当于将Redis中的每一条执行命令记录了下来，恢复的时候需要根据命令一条一条的来，先左手六、再右手七、再左脚画圆、再右脚踢。。。（如果想不明白可以按照姿势试一下就明白了）
RDB在redis.conf目录中进行配置，命令格式为 save [时间] [次数]
那save 60 10000来举例，含义是如果在60秒内有至少10000条改动，那么就自动保存一次，也就是拍一张照片，那么中间如果改动到500条的时候Redis挂了，那么这500条改动就找不到了。
如果执行save命令会造成Redis正常读写收到影响，我们可以用bgsave（写时复制）命令来生成RDB快照，bgsave是用一个子线程来实现快照功能，主线程继续他的读写任务
使用AOF来保存数据就不会有RDB快照中Redis宕机所产生的风险了，因为AOF保存的是每一条命令，但是AOF也并不是只能每一条命令就保存一次，这样会耗费性能，我们可以设置为每1秒执行一次保存，这样就算丢失也只会丢失1秒的数据
可以通过配置文件中的appendonly设置为yes来开启AOF功能
AOF有三个保存策略
appendfsync always：每次有新命令就保存下来，性能最慢，但是最安全
appendsync everysec：每秒保存一次命令，足够快，故障时只会丢失1秒钟的数据
appendfsync no：从不保存，将数据交给操作系统来处理。更快，也更不安全
推荐使用每秒保存一次命令的方式
1、AOF重写
面试官：AOF中那么多命令恢复起来太麻烦，有没有什么优化的方式
AOF文件中有太多没用的指令，所以AOF会定期根据内存的最新数据生成AOF文件
例如我们记录一个人的动作，发现他先抬手，再放下手、然后再抬手，那我我们可以将动作合并为一个动作就是抬手，因为执行抬手，放手，抬手三个动作和只执行一个抬手的动作是一样的
我们可以配置AOF重写的频率，有两个配置项
auto-aof-rewrite-percentage 100 （aof文件自上一次重写后文件大小增长了100%则再次触发重写）
auto-aof-rewrite-min-size 64mb （aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大）
aof可以手动重写，命令为：bgrewriteaof，此时也会使用一个子进程来重写，不会对redis的正常命令有影响
2、RDB和AOF混合使用
面试官：RDB和AOF各有优缺点，我们该怎么选择
在redis启动的时候如果即配置RDB又配置AOF，则优先使用AOF，因为AOF更加安全，但是性能不太好，但是我们可以混合使用，达到更好的效果
将RDB和AOF混合使用，例如恢复的时候先根据照片恢复最后一次拍照记录的样子，然后再恢复拍照后记录的动作
配置开启混合使用：aof‐use‐rdb‐preamble yes
四、Redis主从架构
面试官：可以聊一聊redis的主从架构模式，以及怎样搭建吗
我：可以，redis的主从架构模式其实是用一个redis节点来做写操作（主节点），多个redis节点来做读操作（从节点），主节点会将写入的数据同步给从节点，以保证从从节点读取的数据是最新的数据
搭建方式：主节点不用修改任何配置，从节点修改redis.conf配置文件
配置主节点的ip端口：replicaof （代表从节点从哪个主节点同步数据）
配置好从节点后启动从节点，这个时候启动从节点，从节点会从主节点去初次获取数据
五、Redis哨兵架构
面试官：可以聊一聊redis的哨兵架构模式，以及怎样搭建吗
我：好的，哨兵架构是在主从架构上衍生出来的，因为主从架构中如果主节点挂了，那么我们就不能够写入数据了，只能从从节点中读取数据，这样是很不方便的。
那么我们弄一个哨兵集群来监视这些节点，当主节点挂了以后我们哨兵选举一个从节点成为主节点，并让写数据的命令得以继续执行（我们用比较有名的村庄来举例。。。）。
搭建：复制一份sentinel.conf文件进行修改，redis中默认有这个文件
修改端口号，以及sentinel命令，格式为：sentinel monitor <主节点名称> <端口>
quorum是一个数字类型，意思是有多少个sentinel认为这个主节点失效时才算真正的失效，比如我配置了三个sentinel，那么我这里2的含义就是有两个sentinel认为当前主节点失效就算失效了。
面试官：小伙子真厉害啊，我这边没有什么要问的了，你还有什么问题要问（面试官两眼放光）
我：额。。。面试官这个我的纸质简历可以给我吗，可以不往我的简历上写写画画吗，我明天的面试还要用。
面试官：还面啥别的公司啊，就来我这吧，条件随便开
我：那就100k吧（此时面试官又拿起了他准备好的棍子）
面试官：你要是不来就给我推荐一下，让别人来我这面试一下
我：你先好好学习一下Redis吧，今天幸亏只是我来了，如果是小奇的忠实读者来了，你将会被虐的很惨的。（我将我的《Redis设计与实现》留给了面试官，转身留下了帅气的背影，而面试官落寞无神的呆呆的坐在那里，仿佛一个亿离他而去。。。）
六、总结
这里关于Redis还没有整理完毕，文章后面持续更新，建议收藏。
文章中涉及到的命令大家一定要像我一样每个都敲几遍，只有在敲的过程中才能发现自己对命令是否真正的掌握了。
