Redis

一、简介

​ Redis 是一种基于内存的数据库，对数据的读写操作都是在内存中完成，因此读写速度非常快，常用于缓存，消息队列、分布式锁等场景。Redis 提供了多种数据类型来支持不同的业务场景，比如 String(字符串)、Hash(哈希)、 List (列表)、Set(集合)、Zset(有序集合)、Bitmaps（位图）、HyperLogLog（基数统计）、GEO（地理信息）、Stream（流），并且对数据类型的操作都是原子性的，因为执行命令由单线程负责的，不存在并发竞争的问题。

​ Redis 还支持事务 、持久化、Lua 脚本、多种集群方案（主从复制模式、哨兵模式、切片机群模式）、发布/订阅模式，内存淘汰机制、过期删除机制等等。

二、安装

Ubuntu安装

使用apt-get install redis安装

使用netstat -nlt|grep 6379命令可以看到redis服务器状态

ubuntu中的配置文件在 /etc/redis 中

设置密码

bind 127.0.0.1  # 注释掉绑定的ip
protected-mode yes # 保护模式设置为no(无需密码)
requirepass 123456789 #设置密码
redis-cli 进入redis客户端
ping不通
auth "密码" 后进行操作，否则ping不通
输入密码后可以ping通

Mac安装

1. 使用brew安装

brew install redis
brew services start redis（启动）
brew services stop redis（停止）
brew services restart redis（重启）
#退出客户端
quit

• Homebrew安装的软件会默认在/usr/local/Cellar/路径下
• redis的配置文件redis.conf存放在/usr/local/etc路径下

查看版本

redis-server -v

2. 设置密码

   cd /usr/local/etc
   vim redis.conf
   protected-mode yes  //保护模式，默认就是yess
   daemonize yes //设置后台启动，默认前台启动(设置了这个后不能用brew方式进行关闭redis)
   requirepass 123456789 //设置密码

三、使用

启动

#ubuntu中使用
启动服务: service-server redis start
停止服务: service-server redis stop
重启服务: service-server redis restart
#mac中(参考https://blog.csdn.net/realize_dream/article/details/106227622)
启动 brew services start redis 或者是 redis-server
停止 brew services stop redis 或者是 在redis-cli客户端中执行shutdown
重启 brew services restart redis 

命令

默认有16个数据库  第一个数据库为0（数组一样）   默认使用第一个数据库
select 3  切换到第四个数据库
DESIZE    查看当前数据库的大小
keys *      查看当前数据库所有的key
flushdb    清除当前数据库
flushall     清除全部数据库的内容
exists  key   判断这个key是否存在      
move key 1   删除key   1为当前数据库
expire  key  10  设置这个key的过期时间  10秒后这个key就自动删除  可以用ttl key检测
用户ip实时控制
type key     查看key的类型

• 当key不存在时，设置新的key/value。

  NX命令: 仅当key不存在时，set才会生效

  127.0.0.1:6379> set hello world
  OK
  127.0.0.1:6379> set hello newval nx   # 由于hello存在，所以set命令不会生效，返回nil表示失败。
  (nil)
  127.0.0.1:6379> get hello   # 此时还是原来的值。
  "world"
  
  127.0.0.1:6379> set newkey value nx    # newkey不存在，set命令成功。
  OK
  127.0.0.1:6379> get newkey
  "value"

• 当key存在时，覆盖原有的key/value。

  XX命令：仅当key存在时，set才会生效

  127.0.0.1:6379> set hello world
  OK
  127.0.0.1:6379> set hello newval xx    # 由于hello存在，所以set命令会设置成功。
  OK
  127.0.0.1:6379> get hello              # 可以获取到新值
  "newval"
  
  127.0.0.1:6379> set newkey val xx      # 由于newkey不存在，所以不会设置成功
  (nil)
  127.0.0.1:6379> get newkey
  (nil)

四、类型操作

Redis支持五种数据结构，分别是String，List，Hash，Set，Zset。即字符串，列表，哈希，集合，有序集合。

String字符串

append key “xxx”   在字符串后面加xxx（如果key不存在则创建key）

strlen key  获取字符串的长度

********************************************************

\# i++

\#步长  i+=

incr key   自增1（将key的value加1）

decr  key    减1（将key的value减1）

incrby key  10 （将key的value增加10）

decrby key  10（将key的value减10）

********************************************************

字符串范围    range

getrange key 0 3     截取字符串 [0,3]闭区间

getrange key 0 -1  获取全部字符串  和get key一样

替换

setrange key 1 999   替换指定位置开始的字符串（例如key的value为abcdefg，替换为a999efg）

********************************************************

setex（set with expire ） 设置过期时间

setnx（set if not exist）   不存在设置（在分布式锁中会常常使用！）

setex key  30  "hello"	设置key的值为hello，30秒后过期

setnx key value 将 key 的值设为 value （当且仅当 key 不存在若给定的 key 已经存在，则 SETNX 不做任何动作。）

getset key value1 将key的value值设置为value1 ，返回key旧的value（更新操作）

********************************************************

同时设置多个值 	mset	

同时获取多个值	mget

mset key1 value1 key2 value2 key3 value3  

mget value1 value2 value3

msetnx key1 key1 key4 key4       #会创建失败，msetnx是一个原子性的操作，要么一起成功，要么一起失败

\#	对象	

set user:1{name:zhangsan,age:3}    // 设置一个user:1对象  值为json字符来保存一个对象（user:{id}:{filed}）

127.0.0.1:6379> set user:1:name zhangsan

OK

127.0.0.1:6379> get user:1:name

"zhangsan"

127.0.0.1:6379> 

---

List列表

可以当成栈、队列、阻塞队列使用

所有的List命令都是以L开头

lpush  将一个值或多个值插入到列表头部（左）
通过lenage 0 -1获取全部 也可以区间  
rpush   将一个值或多个值插入到列表尾部（右）

lpop list    移除list的第一个元素
rpop list    移除lsitt的最后一个元素
********************************************************
lindex list 1	通过下标获得list的某个值 下标从0开始
********************************************************
llen list	获取list的长度
********************************************************
移除指定的值
lrem list  x x

移除list集合中指定个数的value

可以删除一个

可以删除多个重复的value

********************************************************
ltrim list 1 2   通过下标截取list中的value ，截取后的list将被修改
********************************************************
rpoplpush   移除列表的最后一个元素，将他移动到新的列表中
rpoplpush list list1   将list中的最后一个value删除并移动到list1
********************************************************
lset	将列表下标中指定下标的值替换为另外一个值，更新操作
lset list 0 good	将list下标为0的值替换为good，若list不存在则会报错
********************************************************

linsert

linsert list before|after xx yy将在lsit的xx前或者后插入yy

list小结：

• list相当于是一个链表，before Node after ，left，right都可以插入值
• 如果key不存在，创建新的链表
• 如果存在，新增内容
• 如果移除了所有值，空链表，也代表不存在

Set集合

值不能重复

********************************************************
sadd set hello	set集合中添加值
smembers set	查看set的所有值
sismember set hello	判断某一个值是不是在set集合中 ，在则返回1
 ********************************************************
scard set	获取set集合中的元素个数
********************************************************
srem set xx	移除set中的指定元素
********************************************************
set无序不重复集合，随机抽
srandmember list    随机抽选set中的一个元素
srandmember list  2  随机抽选set中的指定个数元素
********************************************************
spop set		随机删除一个set集合中的元素
********************************************************
smove set set1 xx		将set中指定的元素移动到set1中
********************************************************

两个集合的 差集 交集 并集

sdiff  set1  set2    查看不同的元素（set中查找与set1不同元素）
sinter  set1  set2  交集：共同元素
sunion set set1    并集

Hash哈希

hset map key value   	set一个具体key-value
hget map key			获取一个字段值
hmset map key1 value1 key2 value2		set多个key-value
hmget map key1 key2		获取多个字段
hgetall map		获取全部数据
hdel map key 	删除指定的key-value
hlen map 		获得map中的长度，有多少个key-value
hexists map key 	判断map中的指定字段是否存在
hkeys map 		获得所有的 key
hvals map	获得所有的value
hincrby map key 1 	将key对应的value加1
hincrby map key -1 	将key对应的value减1
hsetnx map key value		如果存在key则不能设置，不存在可以设置
hset user:1 key value 		对象

Zset有序集合

在set基础上加上了一个值
zadd set 1 one		添加一个值 
zadd set 1 one set2 2 one2  	添加多个值   

zrangebyscore num -inf +inf显示全部用户信息从小到大
zrangebyscore num -inf +inf withscores显示信息并排序
zrangebyscore num -inf 2500 withscores  具体范围
zrevrange num 0 -1   从大到小排序

zrem set xx 		移除有序集合中的指定元素
zcard set		获取有序集合的个数
zcount set 1 3		获取指定区间的成员数量

geospatial

版本3.2以上可用

地理位置，距离等信息，经纬度

官方文档：https://www.redis.net.cn/order/3685.html

getadd 添加地理位置

Hyperloglog

统计数量（数量大时有一定的误差）
PFadd mykey a b c d e f g h i j
PFCOUNT mykey		数量10
PFadd mykey2 i j z x c v b n m
PFCOUNT mykey2	数量9
PFMERGE mykey3 mykey mykey2       合并数量15

Bitmap

操作二进制位来进行储存，只有0和1两个状态

事务

Redis单条命令式保存原子性的，但是事务不保证原子性！

乐观锁

五、整合Springboot

连接远程Redis

redis-cli -h 114.55.26.230 -p 6379 -a 123456789

springboot2.x以后将原来的jedis替换为了lettuce

jedis : 采用的直连，多个线程操作的话，是不安全的，如果想要避免不安全的，使用 jedis pool 连接

池！ 更像 BIO 模式

lettuce : 采用netty，实例可以再多个线程中进行共享，不存在线程不安全的情况！可以减少线程数据

了，更像 NIO 模式

所有的对象需要实例化才能传输

在以后的开发中，实体类都需要进行序列化

User user = new User("袁凯强",3);
String jsonUser = new ObjectMapper().writeValueAsString(user);//使用jackjson序列化

传输中文，在控制台中无法显示，将被转义

因为默认使用的是jdk序列化

@Qualifier注解了，qualifier的意思是合格者，通过这个标示，表明了哪个实现类才是我们所需要的，我们修改调用代码，添加@Qualifier注解，需要注意的是@Qualifier的参数名称必须为我们之前定义@Service注解的名称之一！
@Qualifier解释https://www.cnblogs.com/chenxiaoxian/p/9760032.html

代码参考：https://www.yuque.com/yuankaiqiang/file/19676353

六、Redis持久化（备份）

RDB(Redis默认使用)

优点：适合大规模的数据恢复，备份

redis为内存数据库，断电即失，因此提供了持久化

修改配置文件，60秒内修改了5个key的话就持久化一次生成一个dump.rdb文件

可以根据自己的需要设置配置文件

触发机制

1. svae的规则满足情况下，会自动触发rdb规则
2. 执行flushall操作时，也会触发rdb规则
3. 退出redis时（相当于断电），也会产生rdb

备份自动生成一个rdb文件

恢复rdb文件的数据

1. 只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb 恢复其中

的数据！

2. 查看需要存放的位置，若果在这个目录下存在dump.rdb文件，启动就会自动恢复其中的数据。

例如我启动redis-server /usr/local/bin/myconfig/redis.conf时，dump.rdb就会生成在/usr/local/bin/目录下

恢复时需要要在这个redis-server /usr/local/bin/myconfig/redis.conf启动

AOF（Append Only File）

将我们的所有命令都记录下来，history，恢复的时候就把这个文件全部在执行一遍！

手动开启 设置为yes

优点：

1. 每一次修改都同步，文件的完整会更加好！

2. 每秒同步一次，可能会丢失一秒的数据

3. 从不同步，效率最高的！

缺点：

1. 相对于数据文件来说，aof远远大于 rdb，修复的速度也比 rdb慢！

2. Aof 运行效率也要比 rdb 慢，所以我们redis默认的配置就是rdb持久化

对比

1. RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2. AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重

写，使得AOF文件的体积不至于过大。

3. 只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化

4. 同时开启两种持久化方式

在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。

5. 性能建议

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这条规则。如果Enable AOF 好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。如果不Enable AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。

七、Redis发布订阅

菜鸟教程：https://www.runoob.com/redis/redis-pub-sub.html

八、Redis 如何实现服务高可用？

8.1 Redis主从复制

​ 主从复制是 Redis 高可用服务的最基础的保证，实现方案就是将从前的一台 Redis 服务器，同步数据到多台从 Redis 服务器上，即一主多从的模式，且主从服务器之间采用的是「读写分离」的方式。

​ 主服务器可以进行读写操作，当发生写操作时自动将写操作同步给从服务器，而从服务器一般是只读，并接受主服务器同步过来写操作命令，然后执行这条命令。

所有的数据修改只在主服务器上进行，然后将最新的数据同步给从服务器，这样就使得主从服务器的数据是一致的。

注意，主从服务器之间的命令复制是异步进行的。

具体来说，在主从服务器命令传播阶段，主服务器收到新的写命令后，会发送给从服务器。但是，主服务器并不会等到从服务器实际执行完命令后，再把结果返回给客户端，而是主服务器自己在本地执行完命令后，就会向客户端返回结果了。如果从服务器还没有执行主服务器同步过来的命令，主从服务器间的数据就不一致了。

所以，无法实现强一致性保证（主从数据时时刻刻保持一致），数据不一致是难以避免的。

8.2 哨兵模式

在使用 Redis 主从服务的时候，会有一个问题，就是当 Redis 的主从服务器出现故障宕机时，需要手动进行恢复。

为了解决这个问题，Redis 增加了哨兵模式（Redis Sentinel），因为哨兵模式做到了可以监控主从服务器，并且提供主从节点故障转移的功能。

在使用 Redis 主从服务的时候，会有一个问题，就是当 Redis 的主从服务器出现故障宕机时，需要手动进行恢复。

为了解决这个问题，Redis 增加了哨兵模式（Redis Sentinel），因为哨兵模式做到了可以监控主从服务器，并且提供主从节点故障转移的功能。

8.3 切片集群模式

当 Redis 缓存数据量大到一台服务器无法缓存时，就需要使用 Redis 切片集群（Redis Cluster ）方案，它将数据分布在不同的服务器上，以此来降低系统对单主节点的依赖，从而提高 Redis 服务的读写性能。

Redis Cluster 方案采用哈希槽（Hash Slot），来处理数据和节点之间的映射关系。在 Redis Cluster 方案中，一个切片集群共有 16384 个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个哈希槽中，具体执行过程分为两大步：

• 根据键值对的 key，按照 CRC16 算法 (opens new window)计算一个 16 bit 的值。
• 再用 16bit 值对 16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的哈希槽。

接下来的问题就是，这些哈希槽怎么被映射到具体的 Redis 节点上的呢？有两种方案：

• 平均分配： 在使用 cluster create 命令创建 Redis 集群时，Redis 会自动把所有哈希槽平均分布到集群节点上。比如集群中有 9 个节点，则每个节点上槽的个数为 16384/9 个。
• 手动分配： 可以使用 cluster meet 命令手动建立节点间的连接，组成集群，再使用 cluster addslots 命令，指定每个节点上的哈希槽个数。

上图中的切片集群一共有 2 个节点，假设有 4 个哈希槽（Slot 0～Slot 3）时，我们就可以通过命令手动分配哈希槽，比如节点 1 保存哈希槽 0 和 1，节点 2 保存哈希槽 2 和 3。

redis-cli -h 192.168.1.10 –p 6379 cluster addslots 0,1
redis-cli -h 192.168.1.11 –p 6379 cluster addslots 2,3

然后在集群运行的过程中，key1 和 key2 计算完 CRC16 值后，对哈希槽总个数 4 进行取模，再根据各自的模数结果，就可以被映射到哈希槽 1（对应节点1） 和 哈希槽 2（对应节点2）。

需要注意的是，在手动分配哈希槽时，需要把 16384 个槽都分配完，否则 Redis 集群无法正常工作。

集群脑裂导致数据丢失怎么办？

产生原因：

​ 在 Redis 主从架构中，部署方式一般是「一主多从」，主节点提供写操作，从节点提供读操作。 如果主节点的网络突然发生了问题，它与所有的从节点都失联了，但是此时的主节点和客户端的网络是正常的，这个客户端并不知道 Redis 内部已经出现了问题，还在照样的向这个失联的主节点写数据（过程A），此时这些数据被旧主节点缓存到了缓冲区里，因为主从节点之间的网络问题，这些数据都是无法同步给从节点的。

这时，哨兵也发现主节点失联了，它就认为主节点挂了（但实际上主节点正常运行，只是网络出问题了），于是哨兵就会在「从节点」中选举出一个 leader 作为主节点，这时集群就有两个主节点了 —— 脑裂出现了。

然后，网络突然好了，哨兵因为之前已经选举出一个新主节点了，它就会把旧主节点降级为从节点（A），然后从节点（A）会向新主节点请求数据同步，因为第一次同步是全量同步的方式，此时的从节点（A）会清空掉自己本地的数据，然后再做全量同步。所以，之前客户端在过程 A 写入的数据就会丢失了，也就是集群产生脑裂数据丢失的问题。

总结：由于网络问题，集群节点之间失去联系。主从数据不同步；重新平衡选举，产生两个主服务。等网络恢复，旧主节点会降级为从节点，再与新主节点进行同步复制的时候，由于会从节点会清空自己的缓冲区，所以导致之前客户端写入的数据丢失了。

解决方案：

min-slaves-to-write x	# 主节点必须要有至少 x 个从节点连接，如果小于这个数，主节点会禁止写数据。
min-slaves-max-lag x	# 主从数据复制和同步的延迟不能超过 x 秒，如果超过，主节点会禁止写数据。

九、Redis 如何实现数据不丢失？

Redis 共有三种数据持久化的方式：

• AOF 日志（默认方式）：每执行一条写操作命令，就把该命令以追加的方式写入到一个文件里；
• RDB 快照：将某一时刻的内存数据，以二进制的方式写入磁盘；
• 混合持久化方式：Redis 4.0 新增的方式，集成了 AOF 和 RBD 的优点；

9.1 AOF 日志是如何实现的？

​ Redis 在执行完一条写操作命令后，就会把该命令以追加的方式写入到一个文件里，然后 Redis 重启时，会读取该文件记录的命令，然后逐一执行命令的方式来进行数据恢复。

执行【set name xiaolin】命令作为例子，Redis 执行了这条命令后，记录在 AOF 日志里的内容如下图：

「*3」表示当前命令有三个部分，每部分都是以「$+数字」开头，后面紧跟着具体的命令、键或值。然后，这里的「数字」表示这部分中的命令、键或值一共有多少字节。例如，「$3 set」表示这部分有 3 个字节，也就是「set」命令这个字符串的长度。

为什么先执行命令，再把数据写入日志呢？

Reids 是先执行写操作命令后，才将该命令记录到 AOF 日志里

• 避免额外的检查开销：因为如果先将写操作命令记录到 AOF 日志里，再执行该命令的话，如果当前的命令语法有问题，那么如果不进行命令语法检查，该错误的命令记录到 AOF 日志里后，Redis 在使用日志恢复数据时，就可能会出错。
• 不会阻塞当前写操作命令的执行：因为当写操作命令执行成功后，才会将命令记录到 AOF 日志。

当然，这样做也会带来风险：

• 数据可能会丢失： 执行写操作命令和记录日志是两个过程，那当 Redis 在还没来得及将命令写入到硬盘时，服务器发生宕机了，这个数据就会有丢失的风险。
• 可能阻塞其他操作： 由于写操作命令执行成功后才记录到 AOF 日志，所以不会阻塞当前命令的执行，但因为 AOF 日志也是在主线程中执行，所以当 Redis 把日志文件写入磁盘的时候，还是会阻塞后续的操作无法执行。

AOF 写回策略有几种？

Redis 写入 AOF 日志的过程

• Always，这个单词的意思是「总是」，所以它的意思是每次写操作命令执行完后，同步将 AOF 日志数据写回硬盘；
• Everysec（默认策略），这个单词的意思是「每秒」，所以它的意思是每次写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，然后每隔一秒将缓冲区里的内容写回到硬盘；
• No，意味着不由 Redis 控制写回硬盘的时机，转交给操作系统控制写回的时机，也就是每次写操作命令执行完后，先将命令写入到 AOF 文件的内核缓冲区，再由操作系统决定何时将缓冲区内容写回硬盘。

AOF 日志过大，会触发什么机制？

​ AOF 日志是一个文件，随着执行的写操作命令越来越多，文件的大小会越来越大。 如果当 AOF 日志文件过大就会带来性能问题，比如重启 Redis 后，需要读 AOF 文件的内容以恢复数据，如果文件过大，整个恢复的过程就会很慢。

​ 所以，Redis 为了避免 AOF 文件越写越大，提供了 AOF 重写机制，当 AOF 文件的大小超过所设定的阈值后，Redis 就会启用 AOF 重写机制，来压缩 AOF 文件。

​ AOF 重写机制是在重写时，读取当前数据库中的所有键值对，然后将每一个键值对用一条命令记录到「新的 AOF 文件」，等到全部记录完后，就将新的 AOF 文件替换掉现有的 AOF 文件。

​ 在没有使用重写机制前，假设前后执行了「set name xiaolin」和「set name xiaolincoding」这两个命令的话，就会将这两个命令记录到 AOF 文件。

​ 但是在使用重写机制后，就会读取 name 最新的 value（键值对） ，然后用一条 「set name xiaolincoding」命令记录到新的 AOF 文件，之前的第一个命令就没有必要记录了，因为它属于「历史」命令，没有作用了。这样一来，一个键值对在重写日志中只用一条命令就行了。重写工作完成后，就会将新的 AOF 文件覆盖现有的 AOF 文件，这就相当于压缩了 AOF 文件，使得 AOF 文件体积变小了。

重写 AOF 日志的过程是怎样的？

Redis 的重写 AOF 过程是由后台子进程 bgrewriteaof 来完成的，这么做可以达到两个好处：

• 子进程进行 AOF 重写期间，主进程可以继续处理命令请求，从而避免阻塞主进程；
• 子进程带有主进程的数据副本，这里使用子进程而不是线程，因为如果是使用线程，多线程之间会共享内存，那么在修改共享内存数据的时候，需要通过加锁来保证数据的安全，而这样就会降低性能。而使用子进程，创建子进程时，父子进程是共享内存数据的，不过这个共享的内存只能以只读的方式，而当父子进程任意一方修改了该共享内存，就会发生「写时复制」，于是父子进程就有了独立的数据副本，就不用加锁来保证数据安全。

​ 触发重写机制后，主进程就会创建重写 AOF 的子进程，此时父子进程共享物理内存，重写子进程只会对这个内存进行只读，重写 AOF 子进程会读取数据库里的所有数据，并逐一把内存数据的键值对转换成一条命令，再将命令记录到重写日志（新的 AOF 文件）。

​ 但是重写过程中，主进程依然可以正常处理命令，那问题来了，重写 AOF 日志过程中，如果主进程修改了已经存在 key-value，那么会发生写时复制，此时这个 key-value 数据在子进程的内存数据就跟主进程的内存数据不一致了，这时要怎么办呢？

为了解决这种数据不一致问题，Redis 设置了一个 AOF 重写缓冲区，这个缓冲区在创建 bgrewriteaof 子进程之后开始使用。

在重写 AOF 期间，当 Redis 执行完一个写命令之后，它会同时将这个写命令写入到 「AOF 缓冲区」和 「AOF 重写缓冲区」。

在 bgrewriteaof 子进程执行 AOF 重写期间，主进程需要执行以下三个工作:

• 执行客户端发来的命令；
• 将执行后的写命令追加到 「AOF 缓冲区」；
• 将执行后的写命令追加到 「AOF 重写缓冲区」；

当子进程完成 AOF 重写工作（扫描数据库中所有数据，逐一把内存数据的键值对转换成一条命令，再将命令记录到重写日志）后，会向主进程发送一条信号，信号是进程间通讯的一种方式，且是异步的。

主进程收到该信号后，会调用一个信号处理函数，该函数主要做以下工作：

• 将 AOF 重写缓冲区中的所有内容追加到新的 AOF 的文件中，使得新旧两个 AOF 文件所保存的数据库状态一致；
• 新的 AOF 的文件进行改名，覆盖现有的 AOF 文件。

信号函数执行完后，主进程就可以继续像往常一样处理命令了。

9.2 RDB 快照是如何实现的呢？

​ 因为 AOF 日志记录的是操作命令，不是实际的数据，所以用 AOF 方法做故障恢复时，需要全量把日志都执行一遍，一旦 AOF 日志非常多，势必会造成 Redis 的恢复操作缓慢。

​ 为了解决这个问题，Redis 增加了 RDB 快照。所谓的快照，就是记录某一个瞬间东西，比如当我们给风景拍照时，那一个瞬间的画面和信息就记录到了一张照片。

所以，RDB 快照就是记录某一个瞬间的内存数据，记录的是实际数据，而 AOF 文件记录的是命令操作的日志，而不是实际的数据。

​ 因此在 Redis 恢复数据时， RDB 恢复数据的效率会比 AOF 高些，因为直接将 RDB 文件读入内存就可以，不需要像 AOF 那样还需要额外执行操作命令的步骤才能恢复数据。

RDB 做快照时会阻塞线程吗？

Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave，他们的区别就在于是否在「主线程」里执行：

• 执行了 save 命令，就会在主线程生成 RDB 文件，由于和执行操作命令在同一个线程，所以如果写入 RDB 文件的时间太长，会阻塞主线程；
• 执行了 bgsave 命令，会创建一个子进程来生成 RDB 文件，这样可以避免主线程的阻塞；

Redis 还可以通过配置文件的选项来实现每隔一段时间自动执行一次 bgsave 命令，默认会提供以下配置：

# 实际上执行的是 bgsave 命令，也就是会创建子进程来生成 RDB 快照文件

# 900 秒之内，对数据库进行了至少 1 次修改；
save 900 1
# 300 秒之内，对数据库进行了至少 10 次修改；
save 300 10
# 60 秒之内，对数据库进行了至少 10000 次修改。
save 60 10000

​ Redis 的快照是全量快照，也就是说每次执行快照，都是把内存中的「所有数据」都记录到磁盘中。所以执行快照是一个比较重的操作，如果频率太频繁，可能会对 Redis 性能产生影响。如果频率太低，服务器故障时，丢失的数据会更多。

RDB 在执行快照的时候，数据能修改吗？

可以的，执行 bgsave 过程中，Redis 依然可以继续处理操作命令的，也就是数据是能被修改的，关键的技术就在于写时复制技术（Copy-On-Write, COW）。

​ 执行 bgsave 命令的时候，会通过 fork() 创建子进程，此时子进程和父进程是共享同一片内存数据的，因为创建子进程的时候，会复制父进程的页表，但是页表指向的物理内存还是一个，此时如果主线程执行读操作，则主线程和 bgsave 子进程互相不影响。

​ 如果主线程执行写操作，则被修改的数据会复制一份副本，然后 bgsave 子进程会把该副本数据写入 RDB 文件，在这个过程中，主线程仍然可以直接修改原来的数据。

9.3 混合持久化方式

RDB 优点是数据恢复速度快，但是快照的频率不好把握。频率太低，丢失的数据就会比较多，频率太高，就会影响性能。

AOF 优点是丢失数据少，但是数据恢复不快。

为了集成了两者的优点， Redis 4.0 提出了混合使用 AOF 日志和内存快照，也叫混合持久化，既保证了 Redis 重启速度，又降低数据丢失风险。

​ 混合持久化工作在 AOF 日志重写过程，当开启了混合持久化时，在 AOF 重写日志时，fork 出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件，然后主线程处理的操作命令会被记录在重写缓冲区里，重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

也就是说，使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。

混合持久化优点：

• 混合持久化结合了 RDB 和 AOF 持久化的优点，开头为 RDB 的格式，使得 Redis 可以更快的启动，同时结合 AOF 的优点，有减低了大量数据丢失的风险。

混合持久化缺点：

• AOF 文件中添加了 RDB 格式的内容，使得 AOF 文件的可读性变得很差；
• 兼容性差，如果开启混合持久化，那么此混合持久化 AOF 文件，就不能用在 Redis 4.0 之前版本了。

十、 Redis 过期删除与内存淘汰

10.1 Redis 使用的过期删除策略是什么？

Redis 是可以对 key 设置过期时间的，因此需要有相应的机制将已过期的键值对删除，而做这个工作的就是过期键值删除策略。

每当我们对一个 key 设置了过期时间时，Redis 会把该 key 带上过期时间存储到一个过期字典（expires dict）中，也就是说「过期字典」保存了数据库中所有 key 的过期时间。

当我们查询一个 key 时，Redis 首先检查该 key 是否存在于过期字典中：

• 如果不在，则正常读取键值；
• 如果存在，则会获取该 key 的过期时间，然后与当前系统时间进行比对，如果比系统时间大，那就没有过期，否则判定该 key 已过期。

Redis 使用的过期删除策略是「惰性删除+定期删除」这两种策略配和使用。

什么是惰性删除策略？

惰性删除策略的做法是，不主动删除过期键，每次从数据库访问 key 时，都检测 key 是否过期，如果过期则删除该 key。

惰性删除的流程图如下：

惰性删除策略的优点：

• 因为每次访问时，才会检查 key 是否过期，所以此策略只会使用很少的系统资源，因此，惰性删除策略对 CPU 时间最友好。

惰性删除策略的缺点：

• 如果一个 key 已经过期，而这个 key 又仍然保留在数据库中，那么只要这个过期 key 一直没有被访问，它所占用的内存就不会释放，造成了一定的内存空间浪费。所以，惰性删除策略对内存不友好。

什么是定期删除策略？

定期删除策略的做法是，每隔一段时间「随机」从数据库中取出一定数量的 key 进行检查，并删除其中的过期key。

Redis 的定期删除的流程：

1. 从过期字典中随机抽取 20 个 key；
2. 检查这 20 个 key 是否过期，并删除已过期的 key；
3. 如果本轮检查的已过期 key 的数量，超过 5 个（20/4），也就是「已过期 key 的数量」占比「随机抽取 key 的数量」大于 25%，则继续重复步骤 1；如果已过期的 key 比例小于 25%，则停止继续删除过期 key，然后等待下一轮再检查。

可以看到，定期删除是一个循环的流程。那 Redis 为了保证定期删除不会出现循环过度，导致线程卡死现象，为此增加了定期删除循环流程的时间上限，默认不会超过 25ms。

定期删除的流程如下：

定期删除策略的优点：

• 通过限制删除操作执行的时长和频率，来减少删除操作对 CPU 的影响，同时也能删除一部分过期的数据减少了过期键对空间的无效占用。

定期删除策略的缺点：

• 难以确定删除操作执行的时长和频率。如果执行的太频繁，就会对 CPU 不友好；如果执行的太少，那又和惰性删除一样了，过期 key 占用的内存不会及时得到释放。

可以看到，惰性删除策略和定期删除策略都有各自的优点，所以 Redis 选择「惰性删除+定期删除」这两种策略配和使用，以求在合理使用 CPU 时间和避免内存浪费之间取得平衡。

10.2 Redis 持久化时，对过期键会如何处理的？

Redis 持久化文件有两种格式：RDB（Redis Database）和 AOF（Append Only File）

RDB 文件分为两个阶段，RDB 文件生成阶段和加载阶段。

• RDB 文件生成阶段：从内存状态持久化成 RDB（文件）的时候，会对 key 进行过期检查，过期的键「不会」被保存到新的 RDB 文件中，因此 Redis 中的过期键不会对生成新 RDB 文件产生任何影响。
• RDB 加载阶段：RDB 加载阶段时，要看服务器是主服务器还是从服务器，分别对应以下两种情况：
  • 如果 Redis 是「主服务器」运行模式的话，在载入 RDB 文件时，程序会对文件中保存的键进行检查，过期键「不会」被载入到数据库中。所以过期键不会对载入 RDB 文件的主服务器造成影响；
  • 如果 Redis 是「从服务器」运行模式的话，在载入 RDB 文件时，不论键是否过期都会被载入到数据库中。但由于主从服务器在进行数据同步时，从服务器的数据会被清空。所以一般来说，过期键对载入 RDB 文件的从服务器也不会造成影响。

AOF 文件分为两个阶段，AOF 文件写入阶段和 AOF 重写阶段。

• AOF 文件写入阶段：当 Redis 以 AOF 模式持久化时，如果数据库某个过期键还没被删除，那么 AOF 文件会保留此过期键，当此过期键被删除后，Redis 会向 AOF 文件追加一条 DEL 命令来显式地删除该键值。
• AOF 重写阶段：执行 AOF 重写时，会对 Redis 中的键值对进行检查，已过期的键不会被保存到重写后的 AOF 文件中，因此不会对 AOF 重写造成任何影响。

10.3 Redis 主从模式中，对过期键会如何处理？

当 Redis 运行在主从模式下时，从库不会进行过期扫描，从库对过期的处理是被动的。也就是即使从库中的 key 过期了，如果有客户端访问从库时，依然可以得到 key 对应的值，像未过期的键值对一样返回。

从库的过期键处理依靠主服务器控制，主库在 key 到期时，会在 AOF 文件里增加一条 del 指令，同步到所有的从库，从库通过执行这条 del 指令来删除过期的 key。

10.4 Redis 内存满了，会发生什么？

​ 在 Redis 的运行内存达到了某个阀值，就会触发内存淘汰机制，这个阀值就是我们设置的最大运行内存，此值在 Redis 的配置文件中可以找到，配置项为 maxmemory。

八种内存淘汰策略

这八种策略大体分为「不进行数据淘汰」和「进行数据淘汰」两类策略。

1. 不进行数据淘汰的策略

   • noeviction（Redis3.0之后，默认的内存淘汰策略） ：它表示当运行内存超过最大设置内存时，不淘汰任何数据，而是不再提供服务，直接返回错误。

2. 进行数据淘汰的策略

   针对「进行数据淘汰」这一类策略，又可以细分为「在设置了过期时间的数据中进行淘汰」和「在所有数据范围内进行淘汰」这两类策略。

   在设置了过期时间的数据中进行淘汰：

   • volatile-random：随机淘汰设置了过期时间的任意键值；
   • volatile-ttl：优先淘汰更早过期的键值。
   • volatile-lru（Redis3.0 之前，默认的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最久未使用的键值；
   • volatile-lfu（Redis 4.0 后新增的内存淘汰策略）：淘汰所有设置了过期时间的键值中，最少使用的键值；

   在所有数据范围内进行淘汰：

   • allkeys-random：随机淘汰任意键值;
   • allkeys-lru：淘汰整个键值中最久未使用的键值；
   • allkeys-lfu（Redis 4.0 后新增的内存淘汰策略）：淘汰整个键值中最少使用的键值。

10.5 LRU 算法和 LFU 算法有什么区别？

什么是 LRU 算法？

LRU 全称是 Least Recently Used 翻译为最近最少使用，会选择淘汰最近最少使用的数据。

​ 传统 LRU 算法的实现是基于「链表」结构，链表中的元素按照操作顺序从前往后排列，最新操作的键会被移动到表头，当需要内存淘汰时，只需要删除链表尾部的元素即可，因为链表尾部的元素就代表最久未被使用的元素。

Redis 并没有使用这样的方式实现 LRU 算法，因为传统的 LRU 算法存在两个问题：

• 需要用链表管理所有的缓存数据，这会带来额外的空间开销；
• 当有数据被访问时，需要在链表上把该数据移动到头端，如果有大量数据被访问，就会带来很多链表移动操作，会很耗时，进而会降低 Redis 缓存性能。

Redis 是如何实现 LRU 算法的？

Redis 实现的是一种近似 LRU 算法，目的是为了更好的节约内存，它的实现方式是在 Redis 的对象结构体中添加一个额外的字段，用于记录此数据的最后一次访问时间。

当 Redis 进行内存淘汰时，会使用随机采样的方式来淘汰数据，它是随机取 5 个值（此值可配置），然后淘汰最久没有使用的那个。

Redis 实现的 LRU 算法的优点：

• 不用为所有的数据维护一个大链表，节省了空间占用；
• 不用在每次数据访问时都移动链表项，提升了缓存的性能；

​ 但是 LRU 算法有一个问题，无法解决缓存污染问题，比如应用一次读取了大量的数据，而这些数据只会被读取这一次，那么这些数据会留存在 Redis 缓存中很长一段时间，造成缓存污染。

因此，在 Redis 4.0 之后引入了 LFU 算法来解决这个问题。

什么是 LFU 算法？

​ LFU 全称是 Least Frequently Used 翻译为最近最不常用的，LFU 算法是根据数据访问次数来淘汰数据的，它的核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”。

​ 所以， LFU 算法会记录每个数据的访问次数。当一个数据被再次访问时，就会增加该数据的访问次数。这样就解决了偶尔被访问一次之后，数据留存在缓存中很长一段时间的问题，相比于 LRU 算法也更合理一些。

Redis 是如何实现 LFU 算法的？

LFU 算法相比于 LRU 算法的实现，多记录了「数据的访问频次」的信息。Redis 对象的结构如下：

typedef struct redisObject {
    ...
      
    // 24 bits，用于记录对象的访问信息
    unsigned lru:24;  
    ...
} robj;

Redis 对象头中的 lru 字段，在 LRU 算法下和 LFU 算法下使用方式并不相同。

在 LRU 算法中，Redis 对象头的 24 bits 的 lru 字段是用来记录 key 的访问时间戳，因此在 LRU 模式下，Redis可以根据对象头中的 lru 字段记录的值，来比较最后一次 key 的访问时间长，从而淘汰最久未被使用的 key。

在 LFU 算法中，Redis对象头的 24 bits 的 lru 字段被分成两段来存储，高 16bit 存储 ldt(Last Decrement Time)，用来记录 key 的访问时间戳；低 8bit 存储 logc(Logistic Counter)，用来记录 key 的访问频次。

十一、Redis的缓存设计

11.1 如何避免缓存雪崩、缓存击穿、缓存穿透？

如何避免缓存雪崩？

​ 通常为了保证缓存中的数据与数据库中的数据一致性，会给 Redis 里的数据设置过期时间，当缓存数据过期后，用户访问的数据如果不在缓存里，业务系统需要重新生成缓存，因此就会访问数据库，并将数据更新到 Redis 里，这样后续请求都可以直接命中缓存。

那么，当大量缓存数据在同一时间过期（失效）时，如果此时有大量的用户请求，都无法在 Redis 中处理，于是全部请求都直接访问数据库，从而导致数据库的压力骤增，严重的会造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃，这就是缓存雪崩的问题。

对于缓存雪崩问题，我们可以采用两种方案解决。

• 将缓存失效时间随机打散： 我们可以在原有的失效时间基础上增加一个随机值（比如 1 到 10 分钟）这样每个缓存的过期时间都不重复了，也就降低了缓存集体失效的概率。
• 设置缓存不过期： 我们可以通过后台服务来更新缓存数据，从而避免因为缓存失效造成的缓存雪崩，也可以在一定程度上避免缓存并发问题。

如何避免缓存击穿？

如果业务通常会有几个数据会被频繁地访问，比如秒杀活动，这类被频地访问的数据被称为热点数据。

​ 如果缓存中的某个热点数据过期了，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库很容易就被高并发的请求冲垮，这就是缓存击穿的问题。

可以发现缓存击穿跟缓存雪崩很相似，你可以认为缓存击穿是缓存雪崩的一个子集。 应对缓存击穿可以采取前面说到两种方案：

• 互斥锁方案：（Redis 中使用 setNX 方法设置一个状态位，表示这是一种锁定状态），保证同一时间只有一个业务线程请求缓存，未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。
• 不给热点数据设置过期时间，由后台异步更新缓存，或者在热点数据准备要过期前，提前通知后台线程更新缓存以及重新设置过期时间；

如何避免缓存穿透？

​ 当发生缓存雪崩或击穿时，数据库中还是保存了应用要访问的数据，一旦缓存恢复相对应的数据，就可以减轻数据库的压力，而缓存穿透就不一样了。

​ 当用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据，没办法构建缓存数据，来服务后续的请求。那么当有大量这样的请求到来时，数据库的压力骤增，这就是缓存穿透的问题。

缓存穿透的发生一般有这两种情况：

• 业务误操作，缓存中的数据和数据库中的数据都被误删除了，所以导致缓存和数据库中都没有数据；
• 黑客恶意攻击，故意大量访问某些读取不存在数据的业务；

应对缓存穿透的方案，常见的方案有三种。

• 非法请求的限制：当有大量恶意请求访问不存在的数据的时候，也会发生缓存穿透，因此在 API 入口处我们要判断求请求参数是否合理，请求参数是否含有非法值、请求字段是否存在，如果判断出是恶意请求就直接返回错误，避免进一步访问缓存和数据库。
• 设置空值或者默认值：当我们线上业务发现缓存穿透的现象时，可以针对查询的数据，在缓存中设置一个空值或者默认值，这样后续请求就可以从缓存中读取到空值或者默认值，返回给应用，而不会继续查询数据库。
• 使用布隆过滤器快速判断数据是否存在，避免通过查询数据库来判断数据是否存在：我们可以在写入数据库数据时，使用布隆过滤器做个标记，然后在用户请求到来时，业务线程确认缓存失效后，可以通过查询布隆过滤器快速判断数据是否存在，如果不存在，就不用通过查询数据库来判断数据是否存在，即使发生了缓存穿透，大量请求只会查询 Redis 和布隆过滤器，而不会查询数据库，保证了数据库能正常运行，Redis 自身也是支持布隆过滤器的。

11.2 如何设计一个缓存策略，可以动态缓存热点数据呢？

​ 由于数据存储受限，系统并不是将所有数据都需要存放到缓存中的，而只是将其中一部分热点数据缓存起来，所以我们要设计一个热点数据动态缓存的策略。

热点数据动态缓存的策略总体思路：通过数据最新访问时间来做排名，并过滤掉不常访问的数据，只留下经常访问的数据。

以电商平台场景中的例子，现在要求只缓存用户经常访问的 Top 1000 的商品。具体细节如下：

• 先通过缓存系统做一个排序队列（比如存放 1000 个商品），系统会根据商品的访问时间，更新队列信息，越是最近访问的商品排名越靠前；
• 同时系统会定期过滤掉队列中排名最后的 200 个商品，然后再从数据库中随机读取出 200 个商品加入队列中；
• 这样当请求每次到达的时候，会先从队列中获取商品 ID，如果命中，就根据 ID 再从另一个缓存数据结构中读取实际的商品信息，并返回。

在 Redis 中可以用 zadd 方法和 zrange 方法来完成排序队列和获取 200 个商品的操作。

11.3 说说常见的缓存更新策略？

常见的缓存更新策略共有3种：

• Cache Aside（旁路缓存）策略；
• Read/Write Through（读穿 / 写穿）策略；
• Write Back（写回）策略；

实际开发中，Redis 和 MySQL 的更新策略用的是 Cache Aside，另外两种策略应用不了。

Cache Aside（旁路缓存）策略

​ Cache Aside（旁路缓存）策略是最常用的，应用程序直接与「数据库、缓存」交互，并负责对缓存的维护，该策略又可以细分为「读策略」和「写策略」。

写策略的步骤：

• 先更新数据库中的数据，再删除缓存中的数据。

读策略的步骤：

• 如果读取的数据命中了缓存，则直接返回数据；
• 如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入到缓存，并且返回给用户。

注意，写策略的步骤的顺序不能倒过来，即不能先删除缓存再更新数据库，原因是在「读+写」并发的时候，会出现缓存和数据库的数据不一致性的问题。

举个例子，假设某个用户的年龄是 20，请求 A 要更新用户年龄为 21，所以它会删除缓存中的内容。这时，另一个请求 B 要读取这个用户的年龄，它查询缓存发现未命中后，会从数据库中读取到年龄为 20，并且写入到缓存中，然后请求 A 继续更改数据库，将用户的年龄更新为 21。

最终，该用户年龄在缓存中是 20（旧值），在数据库中是 21（新值），缓存和数据库的数据不一致。

为什么「先更新数据库再删除缓存」不会有数据不一致的问题？

继续用「读 + 写」请求的并发的场景来分析。

假如某个用户数据在缓存中不存在，请求 A 读取数据时从数据库中查询到年龄为 20，在未写入缓存中时另一个请求 B 更新数据。它更新数据库中的年龄为 21，并且清空缓存。这时请求 A 把从数据库中读到的年龄为 20 的数据写入到缓存中。

最终，该用户年龄在缓存中是 20（旧值），在数据库中是 21（新值），缓存和数据库数据不一致。 从上面的理论上分析，先更新数据库，再删除缓存也是会出现数据不一致性的问题，但是在实际中，这个问题出现的概率并不高。

因为缓存的写入通常要远远快于数据库的写入，所以在实际中很难出现请求 B 已经更新了数据库并且删除了缓存，请求 A 才更新完缓存的情况。而一旦请求 A 早于请求 B 删除缓存之前更新了缓存，那么接下来的请求就会因为缓存不命中而从数据库中重新读取数据，所以不会出现这种不一致的情况。

Cache Aside 策略适合读多写少的场景，不适合写多的场景，因为当写入比较频繁时，缓存中的数据会被频繁地清理，这样会对缓存的命中率有一些影响。如果业务对缓存命中率有严格的要求，那么可以考虑两种解决方案：

• 一种做法是在更新数据时也更新缓存，只是在更新缓存前先加一个分布式锁，因为这样在同一时间只允许一个线程更新缓存，就不会产生并发问题了。当然这么做对于写入的性能会有一些影响；
• 另一种做法同样也是在更新数据时更新缓存，只是给缓存加一个较短的过期时间，这样即使出现缓存不一致的情况，缓存的数据也会很快过期，对业务的影响也是可以接受。

Read/Write Through（读穿 / 写穿）策略

Read/Write Through（读穿 / 写穿）策略原则是应用程序只和缓存交互，不再和数据库交互，而是由缓存和数据库交互，相当于更新数据库的操作由缓存自己代理了。

1、Read Through 策略

先查询缓存中数据是否存在，如果存在则直接返回，如果不存在，则由缓存组件负责从数据库查询数据，并将结果写入到缓存组件，最后缓存组件将数据返回给应用。

2、Write Through 策略

当有数据更新的时候，先查询要写入的数据在缓存中是否已经存在：

• 如果缓存中数据已经存在，则更新缓存中的数据，并且由缓存组件同步更新到数据库中，然后缓存组件告知应用程序更新完成。
• 如果缓存中数据不存在，直接更新数据库，然后返回；

下面是 Read Through/Write Through 策略的示意图

​ Read Through/Write Through 策略的特点是由缓存节点而非应用程序来和数据库打交道，在我们开发过程中相比 Cache Aside 策略要少见一些，原因是我们经常使用的分布式缓存组件，无论是 Memcached 还是 Redis 都不提供写入数据库和自动加载数据库中的数据的功能。而我们在使用本地缓存的时候可以考虑使用这种策略。

Write Back（写回）策略

Write Back（写回）策略在更新数据的时候，只更新缓存，同时将缓存数据设置为脏的，然后立马返回，并不会更新数据库。对于数据库的更新，会通过批量异步更新的方式进行。

实际上，Write Back（写回）策略也不能应用到我们常用的数据库和缓存的场景中，因为 Redis 并没有异步更新数据库的功能。

Write Back 是计算机体系结构中的设计，比如 CPU 的缓存、操作系统中文件系统的缓存都采用了 Write Back（写回）策略。

Write Back 策略特别适合写多的场景，因为发生写操作的时候， 只需要更新缓存，就立马返回了。比如，写文件的时候，实际上是写入到文件系统的缓存就返回了，并不会写磁盘。

但是带来的问题是，数据不是强一致性的，而且会有数据丢失的风险，因为缓存一般使用内存，而内存是非持久化的，所以一旦缓存机器掉电，就会造成原本缓存中的脏数据丢失。所以你会发现系统在掉电之后，之前写入的文件会有部分丢失，就是因为 Page Cache 还没有来得及刷盘造成的。

这里贴一张 CPU 缓存与内存使用 Write Back 策略的流程图：

十二、分布式锁

• 当在分布式模型下，数据只有一份（或有限制），此时需要利用锁的技术控制某一时刻修改数据的进程数。
• 用一个状态值表示锁，对锁的占用和释放通过状态值来标识

1. 加锁

   加锁实际上就是在redis中，给Key键设置一个值，为避免死锁，并给定一个过期时间。当任务时间大于设置的过期时间时，检测剩余生存时间，然后重新设置过期的时间即可（重新设计时间时不需要加上NX）。

   SET lock_key random_value NX PX 5000
   TTL lock_key  #当 key 不存在时，返回 -2 。 当 key 存在但没有设置剩余生存时间时，返回 -1 。 否则，以秒为单位，返回 key 的剩余生存时间。

   random_value 是客户端生成的唯一的字符串。
   NX 代表只在键不存在时，才对键进行设置操作。

   XX只在键已经存在的时候，才对键进行设置操作。

   PX 5000 设置毫秒，设置键的过期时间为5000毫秒。

   EX设置秒

   • 在沙滩上踩一脚，留下自己的脚印，就对应了加锁操作。其他进程或者线程，看到沙滩上已经有脚印，证明锁已被别人持有，则等待。

2. 解锁

   解锁的过程就是将Key键删除。但也不能乱删，不能说客户端1的请求将客户端2的锁给删除掉。这时候random_value的作用就体现出来，为了保证解锁操作的原子性，我们用LUA脚本完成这一操作。先判断当前锁的字符串是否与传入的值相等，是的话就删除Key，解锁成功。

   if redis.call('get',KEYS[1]) == ARGV[1] then 
      return redis.call('del',KEYS[1]) 
   else
      return 0 
   end

   • 把脚印从沙滩上抹去，就是解锁的过程。

3. 锁超时

   • 为了避免死锁，我们可以设置一阵风，在单位时间后刮起，将脚印自动抹去。

# Redis数据库索引（默认为0）
spring.redis.database=0
# Redis服务器地址
spring.redis.host=127.0.0.1
# Redis服务器连接端口
spring.redis.port=6379
# Redis服务器连接密码（默认为空）
spring.redis.password=123456789
# 连接池最大连接数（使用负值表示没有限制）
spring.redis.jedis.pool.max-active=20
# 连接池最大阻塞等待时间（使用负值表示没有限制）
spring.redis.jedis.pool.max-wait=-1
# 连接池中的最大空闲连接
spring.redis.jedis.pool.max-idle=10
# 连接池中的最小空闲连接
spring.redis.jedis.pool.min-idle=0
# 连接超时时间（毫秒）
spring.redis.timeout=1000

/**
 * @ClassName: RedisLock
 * @Description: 加锁解锁操作
 * @Author yuankaiqiang
 * @DateTime 2021-07-06 23:24:08
 */
@Service
public class RedisLock {
	
	private static final Logger log = LoggerFactory.getLogger(RedisLock.class);

	private String lock_key = "redis_lock"; // 锁键

	protected long internalLockLeaseTime = 30000;// 锁过期时间

	private long timeout = 999999; // 获取锁的超时时间

	@Autowired
	private RedisTemplate<String, Object> redisTemplate;

	/**
	 * 加锁
	 * 
	 * @param id
	 * @return
	 */
	public boolean lock(String id, String threadName) {
		Long start = System.currentTimeMillis();
		try {
			while (true) {
				boolean flag = redisTemplate.opsForValue().setIfAbsent(lock_key, id, internalLockLeaseTime,
						TimeUnit.MILLISECONDS);
				// true，则证明获取锁成功，处理相关数据
				if (flag) {
					IndexController.setCount(IndexController.getCount() + 1);
					log.info(threadName + "->线程获取锁成功，当前count值为：{1}" + IndexController.getCount());
					return true;
				}
				// 否则循环等待，在timeout时间内仍未获取到锁，则获取失败
				long l = System.currentTimeMillis() - start;
				if (l >= timeout) {
					log.info(threadName + "->线程获取锁超时！");
					return false;
				}
				try {
					Thread.sleep(1000);
					log.info(threadName + "->锁被占用，正在等待！");
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			}
		} catch (Exception e) {
			return false;
		}
	}

	/**
	 * 解锁
	 * 
	 * @param id
	 * @return
	 */
	public boolean unlock(String id, String threadName) {
		String script = "if redis.call('get',KEYS[1]) == ARGV[1] then" + "   return redis.call('del',KEYS[1]) " + "else"
				+ "   return 0 " + "end";
		try {
			// 执行 lua 脚本
			DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
			// 指定 lua 脚本
			redisScript.setScriptText(script);
			// 指定返回类型
			redisScript.setResultType(Long.class);
			// 参数一：redisScript，参数二：key列表，参数三：arg（可多个）
			Long result = redisTemplate.execute(redisScript, Collections.singletonList(lock_key), id);

			if (1 == result) {
				log.info(threadName + "->线程任务完成，解锁成功！");
				return true;
			}
			return false;
		} catch (Exception e) {
			return false;
		}
	}
}

/**
 * @ClassName: IndexController
 * @Description: 分布式锁实现
 * @Author yuankaiqiang
 * @DateTime 2021-07-06 23:23:53
 */
@RestController
public class IndexController {
	
	private static final Logger log = LoggerFactory.getLogger(IndexController.class);

    @Autowired
    RedisLock redisLock;
    
    static int count = 0;
    
    /**
     * @Title: index
     * @Description: 增加了redis分布式锁，每次都一致，只是简单实现
     * @Author yuankaiqiang
     * @DateTime 2021-07-06 23:23:10
     * @return
     * @throws InterruptedException
     */
    @RequestMapping("/index")
    public int index() throws InterruptedException {
        int clientcount = 100;

        for (int i = 0;i < clientcount;i++){
			String key = i + "_" + UUID.randomUUID().toString().replaceAll("-","").toLowerCase();
			new Thread( ()-> {
        		try {
        			redisLock.lock(key, Thread.currentThread().getName());
        		} finally {
                    redisLock.unlock(key, Thread.currentThread().getName());
        		}
        	}, key).start();
        }
        return count;
    }
    
    /**
     * @Title: index1
     * @Description: 不使用分布式锁，每次count的值都不一样，很少情况才为正确的值
     * @Author yuankaiqiang
     * @DateTime 2021-07-06 22:51:15
     * @return
     * @throws InterruptedException
     */
    @RequestMapping("/index1")
    public int index1() throws InterruptedException {
    	count = 0;
        int clientcount = 100;
        
        for (int i = 0;i < clientcount;i++){
			new Thread( ()-> {
        		try {
        			try {
						Thread.sleep(1);
						count++;
					} catch (InterruptedException e) {
						e.printStackTrace();
					}
        		} catch (Exception e) {
        			e.printStackTrace();
				}
        	}).start();
        }
        
        Thread.sleep(5000);
        log.info("count值：" + count);
        return count;
    }
    
	public static int getCount() {
		return count;
	}

	public static void setCount(int count) {
		IndexController.count = count;
	}
    
}

增加锁后，每次变量都为100

十三、常见问题

redis-cli中文显示问题

#查看value值，对象中含中文
39.103.149.176:6379> get user
"[\"com.redis.pojo.User\",{\"name\":\"\xe8\xa2\x81\xe5\x87\xaf\xe5\xbc\xba\",\"age\":3}]"
#使用客户端时加上 --raw
redis-cli --raw -h 39.103.149.176

yuankaiqiang@Mac ~ % redis-cli --raw -h 39.103.149.176
39.103.149.176:6379> auth 123456789
OK
39.103.149.176:6379> ping
PONG
39.103.149.176:6379> get user
["com.redis.pojo.User",{"name":"袁凯强","age":3}]

十四、Redis的线程

参考：http://t.zoukankan.com/traditional-p-13273089.html

问题：Redis是属于单线程还是多线程？

Redis4.0之前：Redis是单线程运行的

Redis6.0：新增了多线程的功能来提高I/O的读写性能

​ Redis是基于内存操作的，它的瓶颈在于机器的内存、网络带宽，而不是CPU，在你CPU还没达到瓶颈时你的内存可能就先满了、或者带宽达到瓶颈了。因此CPU不是主要原因，那么自然就采用单线程了，况且使用多线程比较麻烦。但是在Redis4.0的时候，已经开始支持多线程了，比如后台删除等功能。

Redis在4.0之前使用单线程的模式是因为以下三个原因：

• 使用单线程模式的Redis，其开发和维护会更简单，因为单线程模型方便开发和调试。
• 即使使用单线程模型也能够并发地处理多客户端的请求，主要是因为Redis内部使用了基于epoll的多路复用。
• 对于Redis来说，主要的性能瓶颈是内存或者网络带宽，而并非CPU。

但Redis在4.0以及之后的版本中引入了惰性删除(也叫异步删除)

unlink key
# 这里是异步删除一个key，同步的话则是
del key

这样处理的好处就是不会使Redis的主线程卡顿，会把这些删除操作交给后台线程来执行。

通常情况下使用 del 指令可以很快的删除数据，但是当被删除的 key 是一个非常大的对象时，例如：删除的是包含了成千上万个元素的 hash 集合时，那么 del 指令就会造成 Redis 主线程卡顿，因此使用惰性删除可以有效的避免 Redis 卡顿的问题。

Redis在4.0版本中虽然引入了多线程，但是此版本的多线程只能用于大数据量的异步删除，对于非删除操作的意义并不是很大。

如果我们使用Redis多线程就可以分摊Redis同步读写I/O的压力，以及充分利用多核CPU资源，并且可以有效地提升Redis的QPS。在Redis中虽然使用了I/O多路复用，并且是基于非阻塞I/O进行操作的，但是I/O的读和写本身是阻塞的。比如当socket中有数据时，Redis会先将数据从内核态空间拷贝到用户态空间，然后再进行相关操作，而这个拷贝过程是阻塞的，并且当数据量越大时拷贝所需要的时间就越多，而这些操作都是基于单线程完成的。

Redis6.0中新增了多线程的功能来提高I/O的读写性能：

​ 它的主要实现思路是将主线程的I/O读写任务拆分给一组独立的线程去执行，这样就可以使多个socket的读写并行化了，但Redis的命令依旧是由主线程串行执行的。

但是注意：Redis6.0是默认禁用多线程的，但可以通过配置文件redis.conf中的io-threads-do-reads等于true来开启，完整配置为io-threads-do-reads true。但是还不够，除此之外我们还需要设置线程的数量才能正确地开启多线程的功能，同样是修改Redis的配置，例如设置io-threads 4，表示开启4个线程。

Redis 采用单线程为什么还这么快？

• Redis 的大部分操作都在内存中完成，并且采用了高效的数据结构，因此 Redis 瓶颈可能是机器的内存或者网络带宽，而并非 CPU，既然 CPU 不是瓶颈，那么自然就采用单线程的解决方案了；
• Redis 采用单线程模型可以避免了多线程之间的竞争，省去了多线程切换带来的时间和性能上的开销，而且也不会导致死锁问题。
• Redis 采用了 I/O 多路复用机制处理大量的客户端 Socket 请求，IO 多路复用机制是指一个线程处理多个 IO 流，就是我们经常听到的 select/epoll 机制。简单来说，在 Redis 只运行单线程的情况下，该机制允许内核中，同时存在多个监听 Socket 和已连接 Socket。内核会一直监听这些 Socket 上的连接请求或数据请求。一旦有请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果。

十五、Redis可以用来做什么

1、缓存，毫无疑问这是Redis当今最为人熟知的使用场景。在提升服务器性能方面非常有效；

2、排行榜，如果使用传统的关系型数据库来做这个事儿，非常的麻烦，而利用Redis的SortSet（Zset）数据结构能够非常方便搞定；

3、计算器/限速器，利用Redis中原子性的自增操作，我们可以统计类似用户点赞数、用户访问数等，这类操作如果用MySQL，频繁的读写会带来相当大的压力；限速器比较典型的使用场景是限制某个用户访问某个API的频率，常用的有抢购时，防止用户疯狂点击带来不必要的压力；

注：限速器也是对请求限流的一种实现方式。

4、好友关系，利用集合的一些命令，比如求交集、并集、差集等。可以方便搞定一些共同好友、共同爱好之类的功能；

5、简单消息队列，除了Redis自身的发布/订阅模式，我们也可以利用List来实现一个队列机制，比如：到货通知、邮件发送之类的需求，不需要高可靠，但是会带来非常大的DB压力，完全可以用List来完成异步解耦；

6、Session共享，默认Session是保存在服务器的文件中，即当前服务器，如果是集群服务，同一个用户过来可能落在不同机器上，这就会导致用户频繁登陆；采用Redis保存Session后，无论用户落在那台机器上都能够获取到对应的Session信息