《Redis设计与实现》

学习目标：

《Redis设计与实现》

---

学习内容：

1.Redis支持的value类型及底层实现

注：跳表主要实现范围型操作

2.Redis设置过期时间以及过期键删除策略

redis服务器使用惰性删除和定期删除两种策略
惰性删除：数据到达过期时间，不做处理。等下次访问该数据时，如果未过期，返回数据 ；发现已过期，删除，返回不存在。
定期删除：周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度 。

3.RDB和AOF避免数据丢失

RDB持久化： SAVE或BGSAVE
SAVE会阻塞Redis服务器进程。
BGSAVE命令会派生一个子进程，不会阻塞Redis服务器。
AOF持久化： 以命令追加的方式持久化
AOF重写机制让可以让命令“多变一”。

4.Redis的多路复用

一个线程处理多个套接字（IO流）。

5.多机数据库的实现

（1）复制

存在单点故障问题

（2）Sentinel

主观下线
每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复，Sentinel节点会对该节点做失败判定，这个行为就叫做主观下线.
客观下线
当Sentinel主观下线的节点为主节点时，该Sentinel节点可以通过命令sentinel is_master_down_by_addr来获得其他Sentinel节点对于该主节点的判断，当超过quorum个数，Sentinel节点任务该主节点确实有问题，这时该Sentinel节点会做出客观下线的决定，也就是大部分Sentinel节点对主节点的下线做出来同意的判定，那么这个判定就是客观的。
Sentinel领导者选举
当Sentinel节点对于主节点已经做了客观下线，并不是马上就可以开始故障转移，而是先从Sentinel节点中选举出一个领导者，让领导者去完成故障转移的工作。Redis使用Raft算法实现领导者选举：
(1) 每个Sentinel节点都有资格成为领导者，当它确认主节点主观下线时，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令，要求将自己设置为领导者；
(2) 收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令，将同意该请求，否则拒绝；
(3) 如果该Sentinel节点发现自己的票数已经大于等于max(quorum, num(sentinels)/2+1)，那么它将成为领导者；
(4) 如果此过程没有选举出领导者，将进入下一次选举。
故障转移
Sentinel领导者负责故障转移，具体步骤：
在从节点中选出一个节点作为新的主节点。选择方法如下：
Sentinel领导者对1中选举出来的从节点执行slaveof no one命令，让其成为主节点。
Sentinel领导者向剩余的从节点发送命令，让它们成为新主节点的从节点。
Sentinel节点集合会将原来的主节点更新为从节点，并保持对其关注，当其恢复后命令它去复制新的主节点。

（3）集群Cluster（去中心化）

数据自动在多个Redis节点间分片。
Redis Cluster相当于是把Redis的主从架构和Sentinel集成到了一起，从Redis Cluster的高可用机制、判断故障转移以及执行故障转移的过程，都和主从、Sentinel相关，这也是为什么我在之前的文章里说，主从是Redis高可用架构的基石。

6.缓存和数据库一致性问题

在数据库和缓存的操作过程中，可能存在”先写数据库，后删缓存”、”先写数据库，后更新缓存”、”先删缓存库，后写数据库”以及”先更新缓存库，后写数据库”这四种。
更新缓存的动作，相比于直接删除缓存，操作过程比较的复杂，而且也容易出错。应该优先选择删除缓存而不是更新缓存。
在确定了优先选择删除缓存而不是更新缓存之后，留给我们的数据库+缓存更新的可选方案就剩下：”先写数据库后删除缓存”和”先删除缓存后写数据库了”。
先写数据库
因为数据库和缓存的操作是两步的，没办法做到保证原子性，所以就有可能第一步成功而第二步失败。
而一般情况下，如果把缓存的删除动作放到第二步，有一个好处，那就是缓存删除失败的概率还是比较低的，除非是网络问题或者缓存服务器宕机的问题，否则大部分情况都是可以成功的。
还有就是，先写数据库后删除缓存虽然不存在”写写并发”导致的数据一致性问题，但是会存在”读写并发”情况下的数据一致性问题。
我们知道，当我们使用了缓存之后，一个读的线程在查询数据的过程是这样的：
1、查询缓存，如果缓存中有值，则直接返回 2、查询数据库 3、把数据库的查询结果更新到缓存中
所以，对于一个读线程来说，虽然不会写数据库，但是是会更新缓存的，所以，在一些特殊的并发场景中，就会导致数据不一致的情况。
读写并发的时序如下：

也就是说，假如一个读线程，在读缓存的时候没查到值，他就会去数据库中查询，但是如果自查询到结果之后，更新缓存之前，数据库被更新了，但是这个读线程是完全不知道的，那么就导致最终缓存会被重新用一个”旧值”覆盖掉。
这也就导致了缓存和数据库的不一致的现象。
但是这种现象其实发生的概率比较低，因为一般一个读操作是很快的，数据库+缓存的读操作基本在十几毫秒左右就可以完成了。
而在这期间，更好另一个线程执行了一个比较耗时的写操作的概率确实比较低。
先删缓存
那么，如果是先删除缓存后操作数据库的话，会不会方案更完美一点呢？
首先，如果是选择先删除缓存后写数据库的这种方案，那么第二步的失败是可以接受的，因为这样不会有脏数据，也没什么影响，只需要重试就好了。
但是，先删除缓存后写数据库的这种方式，会无形中放大前面我们提到的”读写并发”导致的数据不一致的问题。
因为这种”读写并发”问题发生的前提是读线程读缓存没读到值，而先删缓存的动作一旦发生，刚好可以让读线程就从缓存中读不到值。
所以，本来一个小概率会发生的”读写并发”问题，在先删缓存的过程中，问题发生的概率会被放大。
而且这种问题的后果也比较严重，那就是缓存中的值一直是错的，就会导致后续的所以命中缓存的查询结果都是错的！
延迟双删
那么，虽然先写数据后删除缓存的这种情况，可以大大的降低并发问题的概率，但是，根据墨菲定律，只要有可能发生的坏事，那就基本上会发生。越是庞大的系统发生的概率越高。
那么，有没有什么办法可以来解决一下这种情况带来的不一致的问题呢？
其实是有一个比较常见的方案的，在很多公司内用的也比较多，那就是延迟双删。
因为”读写并发”的问题会导致并发发生后，缓存中的数被读线程写进去脏数据，那么就只需要在写线程在写数据库、删缓存之后，延迟一段时间，在执行一把删除动作就行了。
这样就能保证缓存中的脏数据被清理掉，避免后续的读操作都读到脏数据。当然，这个延迟的时长也很久讲究，到底多久来删除呢？一般建议设置1-2s就可以了。
当然，这种方案也是有一个弊端的，那就是可能会导致缓存中准确的数据被删除掉。当然这也问题不大，就像我们前面说过的，只是增加一次cache miss罢了。
如何选择
前面介绍了几种情况的具体问题和解决方案，那么实际工作中应该如何选择呢？
我觉得主要还是根据实际的业务情况来分析。
比如，如果业务量不大，并发不高的情况，可以选择先删除缓存，后更新数据库的方式，因为这种方案更加简单。
但是，如果是业务量比较大，并发度很高的话，那么建议选择先更新数据库，后删除缓存的方式，因为这种方式并发问题更少一些。但是可能会引入加锁、延迟双删等更多机制，使得整个方案会更加复杂。

其实，先操作数据库，后操作缓存，是一种比较典型的设计模式——Cache Aside Pattern。
这种模式的主要方案就是先写数据库，后删缓存，而且缓存的删除是可以在旁路异步执行的。
这种模式的优点就是我们说的，他可以解决”写写并发”导致的数据不一致问题，并且可以大大降低”读写并发”的问题，所以这也是Facebook比较推崇的一种模式。
优化方案
Cache Aside Pattern 这种模式中，我们可以异步的在旁路处理缓存。其实这种方案在大厂中确实有的还蛮多的。
主要的方式就是借助数据库的binlog或者基于异步消息订阅的方式。
也就是说，在代码的主要逻辑中，先操作数据库就行了，然后数据库操作完，可以发一个异步消息出来。
然后再由一个监听者在接到消息之后，异步的把缓存中的数据删除掉。
或者干脆借助数据库的binlog，订阅到数据库变更之后，异步的清除缓存。
这两种方式都会有一定的延时，通常在毫秒级别，一般用于在可接受秒级延迟的业务场景中。
缓存更新的设计模式
前面介绍过了Cache Aside Pattern这种关于缓存操作的设计模式，那么其实还有几种其他的设计模式，也一起展开介绍一下：
Read/Write Through Pattern
在这两种模式中，应用程序将缓存作为主要的数据源，不需要感知数据库，更新数据库和从数据库的读取的任务都交给缓存来代理。
Read Through模式下，是由缓存配置一个读模块，它知道如何将数据库中的数据写入缓存。在数据被请求的时候，如果未命中，则将数据从数据库载入缓存。
Write Through模式下，缓存配置一个写模块，它知道如何将数据写入数据库。当应用要写入数据时，缓存会先存储数据，并调用写模块将数据写入数据库。
也就是说，这两种模式下，不需要应用自己去操作数据库，缓存自己就把活干完了。
Write Behind Caching Pattern
这种模式就是在更新数据的时候，只更新缓存，而不更新数据库，然后再异步的定时把缓存中的数据持久化到数据库中。
这种模式的优缺点比较明显，那就是读写速度都很快，但是会造成一定的数据丢失。
这种比较适合用在比如统计文章的访问量、点赞等场景中，允许数据少量丢失，但是速度要快。

7.缓存雪崩、击穿、穿透

缓存雪崩
缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
解决方案：
缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
设置热点数据永远不过期。
缓存击穿
缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力
解决方案：
设置热点数据永远不过期。
加互斥锁。
缓存穿透
缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。
解决方案：
接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击。

8.为什么Redis6.0引入多线程

加入多线程IO来解决网络IO的性能瓶颈。
此时IO读写是多线程的，执行命令依旧是单线程的。

9.Redis实现分布式锁

基于多个 Redis 节点实现高可靠的分布式锁
当我们要实现高可靠的分布式锁时，就不能只依赖单个的命令操作了，我们需要按照一定的步骤和规则进行加解锁操作，否则，就可能会出现锁无法工作的情况。“一定的步骤和规则”是指啥呢？其实就是分布式锁的算法。
为了避免 Redis 实例故障而导致的锁无法工作的问题，Redis 的开发者 Antirez 提出了分布式锁算法 Redlock。
Redlock 算法
基本思路是让客户端和多个独立的 Redis 实例依次请求加锁，如果客户端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布式锁了，否则加锁失败。这样一来，即使有单个 Redis 实例发生故障，因为锁变量在其它实例上也有保存，所以，客户端仍然可以正常地进行锁操作，锁变量并不会丢失。
我们来具体看下 Redlock 算法的执行步骤。Redlock 算法的实现需要有 N 个独立的 Redis 实例。接下来，我们可以分成 3 步来完成加锁操作。
第一步是，客户端获取当前时间。
第二步是，客户端按顺序依次向 N 个 Redis 实例执行加锁操作。
这里的加锁操作和在单实例上执行的加锁操作一样，使用 SET 命令，带上 NX，EX/PX 选项，以及带上客户端的唯一标识。当然，如果某个 Redis 实例发生故障了，为了保证在这种情况下，Redlock 算法能够继续运行，我们需要给加锁操作设置一个超时时间。
如果客户端在和一个 Redis 实例请求加锁时，一直到超时都没有成功，那么此时，客户端会和下一个 Redis 实例继续请求加锁。加锁操作的超时时间需要远远地小于锁的有效时间，一般也就是设置为几十毫秒。
第三步是，一旦客户端完成了和所有 Redis 实例的加锁操作，客户端就要计算整个加锁过程的总耗时。
客户端只有在满足下面的这两个条件时，才能认为是加锁成功。
条件一：客户端从超过半数（大于等于 N/2+1）的 Redis 实例上成功获取到了锁；
条件二：客户端获取锁的总耗时没有超过锁的有效时间。
在满足了这两个条件后，我们需要重新计算这把锁的有效时间，计算的结果是锁的最初有效时间减去客户端为获取锁的总耗时。如果锁的有效时间已经来不及完成共享数据的操作了，我们可以释放锁，以免出现还没完成数据操作，锁就过期了的情况。
当然，如果客户端在和所有实例执行完加锁操作后，没能同时满足这两个条件，那么，客户端向所有 Redis 节点发起释放锁的操作。
在 Redlock 算法中，释放锁的操作和在单实例上释放锁的操作一样，只要执行释放锁的 Lua 脚本就可以了。这样一来，只要 N 个 Redis 实例中的半数以上实例能正常工作，就能保证分布式锁的正常工作了。
所以，在实际的业务应用中，如果你想要提升分布式锁的可靠性，就可以通过 Redlock 算法来实现。

10.Redis独立功能的实现

（1）发布与订阅
（2）事物
保证原子性、一致性、隔离性，当服务器在AOF持久化模式下，并且appendfsync选项的值为always时，事物也具有持久性。
（3）Lua脚本
减少网络开销。可以将多个请求通过脚本的形式一次发送，减少网络时延。
原子操作。Redis会将整个脚本作为一个整体执行，中间不会被其他请求插入。因此在脚本运行过程中无需担心会出现竞态条件，无需使用事务。
（4）排序
（5）二进制位数组
（6）慢查询日志
（7）监视器