First And MOST Important

Redis 的线程模型是什么？redis采用多线程会有哪些问题？Redis为什么这么快？

1. Redis为单线程工作模型。
   redis 内部使用文件事件处理器 ，它采用 IO 多路复用机制同时监听多个 socket。
   多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将 socket 产生的事件放入队列中排队，事件分派器(dispatch)每次从队列中取出一个事件，把该事件交给对应的事件处理器(handle)进行处理。

文件事件处理器的结构包含 4 个部分：

• IO多路复用程序
• 文件事件分派器
• 多个 socket
• 事件处理器(连接应答处理器、命令请求处理器、命令回复处理器)

2. Redis速度快的原因

• 纯内存操作
• 核心是基于非阻塞的 IO 多路复用机制
• 单线程避免了多线程的频繁上下文切换问题

Redis如何使用Redis实现分布式锁

一般不要使用，使用zookeeper。

Redis 的过期策略都有哪些？

redis 过期策略是：定期删除+惰性删除。
定期删除：redis 默认每隔 100ms 就随机抽取部分设置过期时间的 key，检查其是否过期，如果过期就删除。
惰性删除：获取某个 key 的时候，redis 会在获取前判断这个 key 是否设置了过期时间并已经过期了，如果过期了会触发删除。
显然，这样可能会造成大量的过期 key 在内存里，浪费了资源，此时，redis 内存淘汰机制便上场了：

• noeviction: 当内存不足以容纳新写入数据时，新写入操作会报错。
• allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 key。
• volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 key。
• volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键中，最早设置过期时间的 key 先移除。
• volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 key。
• allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（最常用）。

Redis支持哪几种数据结构？分别在哪些场景下使用比较合适？

redis 主要有以下几种数据类型：

1. string
   这是最简单的类型，就是普通的 set 和 get，做简单的 KV 缓存。
2. hash
   这个是类似 map 的一种结构，这个一般就是可以将结构化的数据，比如一个对象（前提是这个对象没嵌套其他的对象）给缓存在 redis 里，然后每次读写缓存的时候，可以就操作 hash 里的某个字段。
3. list
   list 是有序列表，比如可以通过 list 存储一些列表型的数据结构，类似粉丝列表、文章的评论列表之类的东西。
   比如可以通过 lrange 命令，读取某个闭区间内的元素，可以基于 list 实现分页查询，这个是很棒的一个功能，基于 redis 实现简单的高性能分页，可以做类似微博那种下拉不断分页的东西，性能高，就一页一页走。
4. set
   set 是无序集合，自动去重。可以基于 set 做交集、并集、差集的操作。
5. sorted set
   sorted set 是排序的 set，去重但可以排序，写进去的时候给一个分数(score)，自动根据分数排序。

Redis 的哨兵？

哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能：

• 集群监控：负责监控 redis master 和 slave 进程是否正常工作。
• 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
• 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
• 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

当哨兵集群中的大多数哨兵都认为master挂掉时，一个哨兵被选择执行主备切换任务。
选举slave为master，选举因素如下：

• 跟 master 断开连接的时长
• slave 优先级
• 主从复制的偏移量

Redis的持久化方式？优缺点？底层如何实现？

RDB：RDB 持久化机制，是对 redis 中的数据执行周期性的持久化。
AOF：AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，在 redis 重启的时候，可以通过回放 AOF 日志中的写入指令来重新构建整个数据集。

1. RDB 优缺点

• RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中 redis 的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去。
• RDB 对 redis 对外提供的读写服务，影响非常小，可以让 redis 保持高性能，因为 redis 主进程只需要 fork 一个子进程，让子进程执行磁盘 IO 操作来进行 RDB 持久化即可。
• 相对于 AOF 持久化机制来说，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速。
• RDB 间期较长，在 redis 挂掉时，数据量丢失方面RDB要比AOF多。
• RDB持久化时可能会stop the world过久。

2. AOF 优缺点

• AOF 可以更好的保护数据不丢失，一般 AOF 会每隔 1 秒，通过一个后台线程执行一次fsync操作，最多丢失 1 秒钟的数据。
• AOF 日志文件以 append-only 模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
• AOF 日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在 rewrite log 的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件即可。
• AOF 日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用 flushall 命令清空了所有数据，只要这个时候后台 rewrite 还没有发生，那么就可以立即拷贝 AOF 文件，将最后一条 flushall 命令给删了，然后再将该 AOF 文件放回去，就可以通过恢复机制，自动恢复所有数据。
• 对于同一份数据来说，AOF 日志文件通常比 RDB 数据快照文件更大。
• AOF 开启后，支持的写 QPS 会比 RDB 支持的写 QPS 低，因为 AOF 一般会配置成每秒 fsync 一次日志文件，当然，每秒一次 fsync，性能也还是很高的。（如果实时写入，那么 QPS 会大降，redis 性能会大大降低）

RDB和AOF如何选择？
可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。

Redis 的雪崩和穿透？如何解决？

雪崩：缓存机器挂掉
穿透：缓存不命中，打到关系数据库上。

缓存雪崩解决方案：

• 事前：redis集群，尽量高可用。
• 事中：JVM缓存、限流降级，部分用户可用。
• 事后：快速恢复持久化的缓存数据，并进行预热之类的操作。

缓存穿透解决方案：

• 布隆过滤
• 缓存未命中对象[提供手动缓存工具]

如何保证缓存与数据库的双写一致性？

• 先更新数据库，再更新缓存(✘)
• 先删除缓存，再更新数据库--双删延时
• 先更新数据库，再删除缓存

采用Cache-Aside pattern：

• 失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
• 命中：应用程序从cache中取数据，取到后返回。
• 更新：先把数据存到数据库中，成功后，再让缓存失效。

Redis 的并发竞争问题是什么？如何解决这个问题？

Redis为单进程单线程模式，采用队列模式将并发访问变为串行访问。Redis本身没有锁的概念，Redis对于多个客户端连接并不存在竞争，但是在客户端对Redis进行并发访问时会发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题，这些问题均是由于客户端连接异常造成。

对此有2种解决方法：

• 客户端角度，为保证每个客户端间正常有序与Redis进行通信，池化连接，同时对客户端读写Redis操作上锁。
• 服务器角度，利用setnx实现锁。

Redis 事务的 CAS 方案？

• MULTI: 开启一个事务，类比于mysql的openSession
• WATCH:监控一个key，与redis事务机制结合使用，形成原子锁
• EXEC: 提交一个事务，类比于mysql的commit
• DISCARD: 取消一个事务，类比于mysql的rollback
  WATCH指令在Redis事务中提供CAS行为。为了检测被watch的keys在是否有多个clients同时改变引起冲突，这些keys将会被监控。如果至少有一个被监控的key在执行exec命令前被修改，整个事物将会回滚，不执行任何动作，从而保证原子性操作，并且执行exec会得到null的回复。

---

参考资料
https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/redis-persistence.md
http://www.cnblogs.com/rjzheng/p/9041659.html
https://www.jianshu.com/p/0244a875aa26