说说Redis的淘汰策略
- noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
- allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。
- allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。
- volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。
- volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。
- volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。
其实我觉得用volatile-lru就好了 毕竟报错是完全没有必要的 还有就是设置一个报警装置 如果不够了 就搞主从 哈哈
聊聊redis的持久化策略
Redis为持久化提供了两种方式：
- RDB：在指定的时间间隔能对你的数据进行快照存储。
- AOF：记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据。
聊聊RDB
rdb是默认的持久化方式，打个比方，你可以设置比如 90s内 有一次写入，就持久化一次，30s内5次写入就持久化一次等等，当然如果你想要禁用RDB配置，也是非常容易的，只需要在save的最后一行写上：save ""。
在Redis中RDB持久化的触发分为两种：自己手动触发与Redis定时触发。 针对RDB方式的持久化，手动触发可以使用：
- save：会阻塞当前Redis服务器，直到持久化完成，线上应该禁止使用。
- bgsave：该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。
说说AOF
appendonly yes 首先是要开启aof。 appendfsync everysec 它其实有三种模式:
- always：把每个写命令都立即同步到aof，很慢，但是很安全
- everysec：每秒同步一次，是折中方案(默认也是这个)
- no：redis不处理交给OS来处理，非常快，但是也最不安全
AOF的整个流程大体来看可以分为两步，一步是命令的实时写入（如果是 appendfsync everysec 配置，会有1s损耗），第二步是对aof文件的重写。
对于增量追加到文件这一步主要的流程是：命令写入=》追加到aof_buf =》同步到aof磁盘。那么这里为什么要先写入buf在同步到磁盘呢？如果实时写入磁盘会带来非常高的磁盘IO，影响整体性能。
如何恢复redis的数据呢
启动时会先检查AOF文件是否存在，如果不存在就尝试加载RDB。那么为什么会优先加载AOF呢？因为AOF保存的数据更完整，通过上面的分析我们知道AOF基本上最多损失1s的数据。
说说持久化的性能实战
一些线上经验
- 如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据，可以关闭持久化，如果丢失数据可以通过其它途径补回；
- 自己制定策略定期检查Redis的情况，然后可以手动触发备份、重写数据；
- 可以加入主从机器，利用一台从机器进行备份处理，其它机器正常响应客户端的命令；
聊聊Redis中的Master-Slave模式
主从架构的特点
- 主服务器负责接收写请求
- 从服务器负责接收读请求
- 从服务器的数据由主服务器复制过去。主从服务器的数据是一致的
主从架构的好处
- 读写分离(主服务器负责写，从服务器负责读)
- 高可用(某一台从服务器挂了，其他从服务器还能继续接收请求，不影响服务)
- 处理更多的并发量(每台从服务器都可以接收读请求，读QPS就上去了)
说说主从同步呗
主从架构的特点之一：主服务器和从服务器的数据是一致的。 主从同步的2种情况
完整的同步
- 从服务器向主服务器发送PSYNC命令
- 收到PSYNC命令的主服务器执行BGSAVE命令，在后台生成一个RDB文件。并用一个缓冲区来记录从现在开始执行的所有写命令。
- 当主服务器的BGSAVE命令执行完后，将生成的RDB文件发送给从服务器，从服务器接收和载入RBD文件。将自己的数据库状态更新至与主服务器执行BGSAVE命令时的状态。
- 主服务器将所有缓冲区的写命令发送给从服务器，从服务器执行这些写命令，达到数据最终一致性。
部分重同步
- 主从服务器的复制偏移量 主服务器每次传播N个字节，就将自己的复制偏移量加上N
- 从服务器每次收到主服务器的N个字节，就将自己的复制偏移量加上N
- 通过对比主从复制的偏移量，就很容易知道主从服务器的数据是否处于一致性的状态！
那你说说redis的高可用方案呗
Redis 一般以主/从方式部署（这里讨论的应用从实例主要用于备份，主实例提供读写）该方式要实现 HA 主要有如下几种方案：
- keepalived： 通过 keepalived 的虚拟 IP，提供主从的统一访问，在主出现问题时， 通过 keepalived 运行脚本将从提升为主，待主恢复后先同步后自动变为主，该方案的好处是主从切换后，应用程序不需要知道(因为访问的虚拟 IP 不变)，坏处是引入 keepalived 增加部署复杂性，在有些情况下会导致数据丢失
- zookeeper： 通过 zookeeper 来监控主从实例， 维护最新有效的 IP， 应用通过 zookeeper 取得 IP，对 Redis 进行访问，该方案需要编写大量的监控代码
- sentinel： 通过 Sentinel 监控主从实例，自动进行故障恢复，该方案有个缺陷：因为主从实例地址( IP & PORT )是不同的，当故障发生进行主从切换后，应用程序无法知道新地址，故在 Jedis2.2.2 中新增了对 Sentinel 的支持，应用通过 redis.clients.jedis.JedisSentinelPool.getResource() 取得的 Jedis 实例会及时更新到新的主实例地址
那你说说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灵活，但实现很简单，节点增删时处理起来也很方便。
聊聊分布式锁
这个话题基本上是分布式系统开发的一个必问的题目了 问你分布式锁是怎么实现的，然后大家可能就搭用它的 set NX EX命令 然后用lua脚本做成一个原子性操作来实现分布式锁。其实这么搭也可以吧，然后我们一般在生产环境的话，可能会用一些开源框架，你不如说Redisson来实现分布式锁。
聊聊Redisson是怎么实现分布式锁的
- 第一步先尝试去加锁，返回过期时间，如果为空则可以获得锁 （返回获取锁成功）（,在lua脚本里面会判断你的key和value是不是已经持有锁了，如果是，就是给你重试次数加，然后获取锁也是失败)
- 如果第一次加锁失败之后，就会去判断你最大等待时间，如果走到这的时候已经超过最大等待时间（直接返回获取锁失败，）
- 接下来就是说我要去订阅redis解锁这个事件，一旦有人把锁释放就会继续通知所有的线程去竞争锁(减少cpu的损耗)
- 然后是一个死循环的去获取锁，当时每次执行这个循环的时候，每次去获取锁之前都要去判断当前是否已经超过最大的等待时间，如果超过了就直接释放锁。只有当获得锁，或者是最大的等待时间超过之后才会返回是否成功获取锁的标志。（里面也是需要被通知才继续循环）
- 通过 Redisson 实现分布式可重入锁，比纯自己通过set key value px milliseconds nx +lua 实现（实现一）的效果更好些，虽然基本原理都一样，因为通过分析源码可知，RedissonLock
- 是可重入的，并且考虑了失败重试，可以设置锁的最大等待时间， 在实现上也做了一些优化，减少了无效的锁申请，提升了资源的利用率。
结束
redis就这些吧，接下来复习下es吧
