1. redis 为什么快？
在底层上， redis 使用了 IO 多路复用技术，像 select、epoll 等。能较好的保障吞吐量。而且 redis 采用了单线程处理请求，避免了线程切换和锁竞争锁带来的额外消耗。
加上 redis 本身也对一些数据结构进行了优化设计，所以 redis 的性能非常好，官方给出的测试报告是单机可以支持约 10w/s 的 QPS。
2. Redis 有哪些使用场景？应用是怎么样的？
Redis 的使用场景有很多，最常用的莫过于数据缓存了。但由于它提供了多种数据类型，因此我们还可以进行其他场景的开发，比如：
- 排行榜：有序集合（sorted set）每次写入都会进行排序，而且不含重复值，所以我们可以将用户的唯一标识，比如 userId 作为 key，分数作为 score，然后就可以进行
ZADD操作，以得到排行榜。 - 签到：签到往往只有 2 种状态，已签到和未签到。这就跟 0 和 1 一样，所以 redis 的
setbit、getbit这种对位的操作就适合签到场景。 - 计数：redis 是单线程操作，这种计数功能，比如点赞数、粉丝数的操作可以交给 redis 以避免并发竞争问题。当然，也得考虑持久化问题。
3. Redis 通信协议 是怎么样的？
redis 采用文本序列化协议，和 http 协议一样，一个请求一个响应，客户端接到响应后再继续请求。也可以发起多次请求，然后一次响应回所有执行结果，即所谓的 pipeline 管道技术。
redis 的文本序列化协议比较简单，通过一些规范格式去解析文本，大概如下：
- \r\n 表示解析结束
- 简单字符串，以“+”开头
- 错误 Errors，以“-”开头
- 整数类型，以“:”开头
- 大字符串类型，以“$”开头
- 数组类型，以“*”开头
例如，客户端向服务器发送命令：
SET key value
将被解析为：
*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n
上面的命令可以看成：
*<参数数量> CR LF
$<参数 1 的字节数量> CR LF
<参数 1 的数据> CR LF
...
$<参数 N 的字节数量> CR LF
<参数 N 的数据> CR LF
而服务器的回复则有很多类型，一般由响应数据的第一个字节决定：
状态回复（status reply）的第一个字节是 "+"
错误回复（error reply）的第一个字节是 "-"
整数回复（integer reply）的第一个字节是 ":"
批量回复（bulk reply）的第一个字节是 "$"
多条批量回复（multi bulk reply）的第一个字节是 "*"
例如，响应回来的状态回复如下：
+OK
4. redis 对外提供了哪些数据类型，它们的底层数据结构又是怎么样的？
为了让开发者能更好的使用缓存，redis 支持了 5 种数据类型。底层是由 6 种数据结构组成的。
5 种数据类型
字符串：字符串类型是 redis 里最基础的数据类型，像 set name "hello" 操作后，在 get name 时返回的就是字符串，而且还支持了对位的操作。一般一个键能存储 512MB 的值。
hash：哈希类型主要是用来存储对象的，一般我们如果有一整个对象要存储，里面包含了多个字段，则可以使用 hash 来存储，因为 redis 提供了对这些字段的提取和设置，减少了开发者对它的二次处理，比如序列化反序列化操作。
list：一个简单的字符串列表，它允许我们从两端进行 push，pop 操作,还支持一定范围的列表元素。可以看成是双向列表。
set：集合是一个不重复值的组合，为我们提供了交集、并集、差集等操作，像找出共同好友这种需求就可以使用集合操作了。
sorted set：有序集合，在上面集合的基础上提供了排序功能，通过一个 score 属性来进行排序。
6 种底层数据结构
上面的数据类型实际上在 redis 底层是有对应的数据结构来实现的，都是 redis 经过精心设计的，能很好的提高处理效率。
简单动态字符串：redis 是使用 C 语言写的，而 C 语言里的字符串类型比较原始，比如使用 \0 作为字符结束符。所以 redis 实现了属于自己的字符串类型，比如字符串长度，预先分配内存，动态拓展等特点，也保证了处理安全性。
链表：一个双端链表，有 prev，next 指针去获取前后节点，带有 len 属性，能保存多种类型的值。
字典：通过哈希算法来实现 key-value 的映射操作，采用链地址法解决了 hash 冲突，一般时间复杂度能达到 O(1)。
跳跃表：一个多层有序链表，每一层都是对下面一层的有序提取，能降低搜索次数，有点像有序二叉树的搜索一样。
整数集合：一个有序的整数集合，不会有重复元素。
压缩列表(ziplist)：经过特殊编码的一块连续内存，能有效的节省内存。
快速列表：将 ziplist 组织为了一个双向链表，由于 ziplist 的内部连续性，能降低链表的内存碎片问题，提高内存利用率。
5. redis 淘汰策略有哪些？
redis 的淘汰策略主要是 LRU 淘汰、TTL 淘汰和随机淘汰这三种机制。
- LRU 淘汰：最近最少使用的淘汰掉
- TTL 淘汰：越早过期的越先淘汰掉。
- 随机淘汰：采用随机算法淘汰掉。
由于 redis 可以对键设置过期时间，也可以不设置，所以淘汰策略还得再细分：
- volatile-lru：针对设置了过期时间的 key 执行 LRU 淘汰策略，没有设置过期时间的不会被淘汰。
- volatile-ttl：只针对设置了过期时间的 key 执行 TTL 淘汰。
- volatile-random：只针对设置了过期时间的 key 执行随机淘汰。
- allkeys-lru：针对所有键进行 LRU 淘汰策略
- allkeys-random：针对所有键进行随机淘汰策略
- no-enviction：不执行淘汰策略，如果有写入操作，则报错；读请求可以继续进行。
在 Redis 的配置文件 redis.conf 里我们可以进行淘汰策略的设置：
# 数据达到多大后执行淘汰策略
maxmemory 300mb
# 淘汰策略的设置
maxmemory-policy volatile-lru
6. redis 的持久化机制有哪些？
RDB
在指定的时间间隔里将 Redis 内存里的数据镜像下来，保存到文件里。它会先 fork 一个子进程，将数据的写入交给子进程，而父进程不会涉及到磁盘的 IO 操作，所以 RDB 的性能非常好。如果是在 Unix 系统上，还能充分利用写时复制机制，节省对物理内存的使用。
由于 RDB 文件只存储了某个时刻的内存数据，并没有什么逻辑命令，所以在进行重启恢复时，能很快的加载进来。
虽然 RDB 的 fork 能使得 Redis 的持久化独立进行，但是一旦数据量比较大的，就会一直占用 CPU，可能会影响到父进程的进行。
AOF
将服务器对数据的写操作追加到文件里，相当于将所有的逻辑操作都记录了下来。AOF允许我们以每秒的速度进行持久化，这样的话可以很大程度的减少数据的丢失。同时它采用追加的方式进行写文件，这样即使持久化失败，影响较少，而且能够使用 redis-check-aof 进行修复。
不过日志可能会越来越大，需要靠重写来减少对磁盘的占用。
RDB + AOF
将 RDB 和 AOF 结合起来，组合它们各自的优点。4.0 版本以上才支持。其文件时前半部分时 RDB 格式，后半部分是 AOF 格式。
7. redis 的分布式锁： RedLock 原理是什么？有哪些缺点？
RedLock 原理
客户端依次向各个 redis 节点获取锁，一旦超过一半的机器上锁了，并且没有超过规定的时间，则客户端认为是上锁成功了。同时开始计算锁的过期时间，过期则通知所有服务器解锁，如果这次获取锁失败，也通知所有服务器解锁。 并且解锁时会根据当时带过来的一个 token 一致才解锁，防止误解锁。
RedLock 缺点
- 受限于 redis 的持久化机制，当某个 redis 节点重启时丢失了锁记录，则有可能导致新的请求又获取到了超过一半的响应，则此时将有两个操作者同时拥有锁资源。官方针对此建议： 延迟重启，等待超时
- 上面的流程涉及到了时间的判断，如果不同机器的时间差相差太远，则会出现超时解锁，提前释放资源的问题。
8. redis 的高可用方案设计？
主从模式
在不同的机器上部署着同一 Redis 程序。在这多台机器里，我们会选择一个节点作为主节点，它负责数据的写入。其他节点作为从节点，定时的和主节点同步数据。一旦主节点不能使用了，那么就可以在从节点中挑选一个作为主节点，重新上岗服务。
哨兵模式
上面的主从模式需要人工的进行故障节点切换，这种方式对于追求完美的程序员来说，肯定是不够的。所以有了自动切换的哨兵模式。
哨兵模式主要实现了下面几个功能：
- 监控：不断的检测主从节点是否能正常工作。
- 自动转移故障：当某个 master 不能正常工作时，Sentinel 会启动一个故障转移过程，将其中的一个副本提升为 master，并通知其他从节点对应新的 master 相关信息。
- 通知：当某个节点出问题时，会告知所有节点。如果是新的主节点被选举出来，还会告知已连接过来的客户端程序关于主节点新的地址。
集群
Redis 的集群采用了哈希槽的概念，总共会有 16384 个哈希槽。这些哈希槽会被分配到各个节点上，比如：
- 节点 1 分配了 0 至 5500 的哈希槽。
- 节点 2 分配了 5501 至 11000 的哈希槽。
- 节点 3 分配了 11001 至 16384 的哈希槽。
当有 key 过来时，Redis 会对其进行 CRC16(key) % 16384 的运算，看当前的 key 要分散到哪个哈希槽上，再根据当前的哈希槽定位到对应的节点上。这样就完成了一次 key-value 的存储了。
读取也是按这规则来，不同的是，如果运算结果所对应的节点不在当前节点上，则会转发给对应的节点去处理。
当有节点进行新增或删除时，会重新划分这些哈希槽，当然，影响的只会是周围节点，不会造成整个集群不可用。
在这些节点背后还有属于它们的从节点，一旦主节点不可用，那么这些从节点就会被启用，以保证系统的正常运行。
9. 缓存雪崩和穿透该怎么处理？
当缓存失效，就会有大量的请求打到后端服务，压垮系统，这就是缓存雪崩。
除了缓存雪崩，还有缓存穿透的可能。比如每次访问不一样的数据，则请求还是会落到后方。
为了防止缓存雪崩，我们可以对请求做控制，比如加入到消息队列，慢慢消化它；又或者直接开启限流功能，将流量控制在合理的范围内。
而针对缓存穿透，我们可以建立黑白名单，将一些恶意请求拎出来，然后直接拒绝掉。如果是正常的请求，那可以将筛选出来的结果也暂时缓存起来，即使得到的值是 NULL 值。
10. 使用 Redis 在数据并发处理上有哪些需要考虑？
由于 Redis 是以组件形式存在，所以实际上我们的程序通信可以认为是分布式的了，也就是会有缓存和后端数据一致性的问题。
常见的做法是在有新数据到来时，将缓存 key 删除掉，等待下次的查询重新填补上缓存。
之所以在更新数据时不让 Redis 也做更新动作，是为了防止多个更新动作一起发生，可能由于网络原因，导致后更新的比前面更新的先一步达到 Redis， 这样就会跟原来的流程不一样了。所以只采取了删除动作，不做其他。
不过，就算是删除 key 这种方案也有一定概率跟上面的情况一样，真的要严谨的话，一般会设置定时过期时间，让数据最多在这段时间不一致。
11. redis 如何实现延迟队列？
利用有序集合的 score 属性，将时间戳设置到该属性上，然后定时的对其排序，查看最近要执行的记录，如果时间到了，则取出来消费后删除，即可达到延迟队列的目的。
12. redis 的事务和 db 的事务有什么不一样？
Redis 的事务保证了 ACID 中的一致性（C）和隔离性（I），但并不保证原子性（A）和持久性（D）。
对于原子性而言，要么都成功，要么都不成功，而 redis 的事务中途某个语句出错了, 比如 key 类型 出错了, 还会继续执行其他语句；
对于持久性而言，redis 即使开启了最严格的数据落地，由于保存是由后台线程进行的，主线程不会阻塞直到保存成功，所以从命令执行成功到数据保存到硬盘之间，还是有一段非常小的间隔，所以这种模式下的事务也是不持久的。
感兴趣的朋友可以搜一搜公众号「 阅新技术 」，关注更多的推送文章。
可以的话，就顺便点个赞、留个言、分享下，感谢各位支持！
阅新技术，阅读更多的新知识。
