目录
鸣谢：https://mp.weixin.qq.com/s/z2_whw-zlK8wNyNkRM5klg
memcached 与 redis 的区别？
1、存储方式不同：memcached 把数据全部存在内存之中，断电之后会挂掉，而 redis 虽然也用到了内存，但是可以将内存数据保存到磁盘中，保证数据持久性。
2、数据支持类型不同：memcached 对数据支持比较简单（基于内存的key-value存储），而 redis 支持数据类型较丰富，如 string、list、set、sorted set、hash。
3、底层实现不同：一般调用系统函数，会消耗比较多的时间去请求，redis 自己构建了 vm，速度会更快。
redis 数据淘汰策略？
1.volatile-lru：从已经设置过期时间的数据集中，挑选最近最少使用的数据淘汰。
2.volatile-ttl：从已经设置过期时间的数据集中，挑选即将要过期的数据淘汰。
3.volatile-random：从已经设置过期时间的数据集中，随机挑选数据淘汰。
4.allkeys-lru：从所有的数据集中，挑选最近最少使用的数据淘汰。
5.allkeys-random：从所有的数据集中，随机挑选数据淘汰。
6。no-enviction：禁止淘汰数据。
为什么redis把所有数据都放到内存中？
1、redis 为了达到最快的读写速度，将数据都读到内存中，并通过异步的方式将数据写入磁盘。如果不将数据放在内存中，磁盘IO 速度会严重影响 redis 的性能。
redis的并发竞争问题如何解决？
1、首先 redis 为单进程单线程模式，采用队列模式将并发访问变为串行访问。
2、redis 本身没有锁的概念，redis 对多个客户端连接并不存在竞争，但是在 Jedis 客户端对 redis 进行并发访问时会产生一系列问题，这些问题时由于客户端连接混乱造成的。有两种方案解决。
1、在客户端，对连接进行池化，同时对客户端读写 redis 操作采用内部锁 synchronized。
2、在服务器角度，利用 setnx 实现锁。
Java 使用 Redis（菜鸟教程）：http://www.runoob.com/redis/redis-java.html
redis过期键的删除策略？
1、定时删除：
1）在设置键的过期时间的同时，创建一个 timer，让定时器在键的过期时间到达时，立即执行对键的删除操作（主动删除）。
2）对内存友好，但是对 cpu 时间不友好，有较多过期键的情况下，删除过期键会占用相当一部分 cpu 时间。
2、惰性删除：
1）放任过期键不管，但是每次从键空间中获取键时，都检查取到的键是否过期，如果过期就删除，如果没过期就返回该键（被动删除）。
2）对 cpu 时间友好，程序只会在取出键的时候才会对键进行过期检查，这不会在删除其他无关过期键上花费任何 cpu 时间，但是如果一个键已经过期，而这个键又保留在数据库中，那么只要这个过期键不被删除，他所占用的内存就不会释放，对内存不友好。
3.定期删除：
1）每隔一段时间就对数据库进行一次检查，删除里面的过期键（主动删除）。
2）采用对内存和 cpu 时间折中的方法，每过一段时间执行一次删除过期键操作，并通过限制操作执行的时长和频率来减少对 cpu 时间的影响。难点在于选择一个好的策略来设置删除操作的时长和执行频率。
redis与一般db的同步过程？
1、对应数据查询：先去 redis 中判断数据是否存在，如果存在，则直接返回缓存好的数据，如果不存在，去 db 中读取数据，并把数据缓存一份到 redis 中。适用于数据里比较大，但是不经常更新的情况，如用户排行。
2、对于数据更新：先去 redis 中判断数据是否存在，如果存在，则直接更新对应数据（这一步会记录下更新的 key），并把更新后的数据返回给页面，如果不存在，先去数据库中更新内容，然后把数据保存一份到redis中。再往后，后台会进行一系列操作，把redis中更新的key读取出来，找到数据库中对应的数据，并更新数据库。这种方式是把redis当作数据库使用，适合大数据的频繁变动。但是对redis的依赖很大，要做好挂掉之后的数据备份。
简述redis哨兵模式？
1、哨兵是对 redis 进行实时的监控，主要有两个功能：
1）监测主数据库和从数据库是否正常运行。
2）当主数据库出现故障的时候，可以自动将一个从数据库转换为主数据库，实现自动切换。
redis哨兵监控机制？
1、哨兵监控也是有集群的，会有多个哨兵进行监控，当判断发生故障的哨兵达到一定数量的时候才进行修复。一个健壮的部署至少需要三个哨兵实例。
2、每个Sentinel（哨兵）以每秒钟一次的频率向它所知的 Master（主人），Slave（奴隶）以及其他 Sentinel 实例发送一个 PING 命令
3、如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel （哨兵）标记为主观下线。
4、如果一个 Master （主人）被标记为主观下线，则正在监视这个 Master 的所有 Sentinel（哨兵） 要以每秒一次的频率确认Master 的确进入了主观下线状态。
5、当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认 Master 的确进入了主观下线状态， 则Master 会被标记为客观下线 。
6、在一般情况下， 每个 Sentinel （哨兵）会以每 10 秒一次的频率向它已知的所有Master，Slave 发送 INFO 命令。
7、当 Master 被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
8、若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。