非关系型数据库Redis(二）

命令	描述
multi	标记一个事务的开始
exec	执行所有事务块内的命令
discard	取消事务，放弃执行事务块内的所有命令
watch key1 [key2]	监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断，类似乐观锁。(在执行multi之前，先执行watch key1 [key2]，watch演示，启动两个客户端)
unwatch	取消watch命令对所有 key 的监视

1.4 为什么添加事务

场景：超卖问题，当很多人同时去购买票，发现票池的数量变负数。

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

乐观锁(Optimistic Lock) 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

二、Redis持久化

Redis 是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以 Redis 提供了持久化功能：RDB和AOF。

1.RDB:将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据。

2.AOF:将数据的操作过程进行保存,日志形式，存储操作过程，关注点在数据的操作过程。

2.1 RDB方式

概念：RDB是Redis的默认持久化方式，它通过将Redis的内存数据以快照的形式保存到磁盘上的一个二进制文件中，它恢复时是将快照文件直接读到内存里。RDB持久化可以手动触发，也可以根据配置文件中的自动保存规则定期触发。RDB持久化适合用于备份、灾难恢复等场景。

RDB持久化的过程包括以下几个步骤：

1.Redis会fork出一个子进程，负责将数据写入到磁盘上的RDB文件中。

2.在写入RDB文件之前，Redis会将内存中的数据进行快照，生成一个临时的RDB文件

3.当临时RDB文件生成完成后，Redis会用这个文件替换掉之前的RDB文件，完成持久化。

2.1.1 RDB手动

save指令

命令 :save
作用 :手动执行一次保存操作

save指令相关配置

dbfilename dump.rdb
说明：设置本地数据库文件名，默认值为 dump.rdb
经验：通常设置为 dump-端口号.rdb
dir
说明：设置存储.rdb文件的路径
经验：通常设置成存储空间较大的目录中，目录名称data
rdbcompression yes
说明：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF算法压缩
经验：通常默认为开启状态，如果设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）

save指令工作原理(单线程任务执行序列)

客户端1 127.0.0.1:6379>set key1 value1
客户端2 127.0.0.1:6379>set key2 value2
客户端3 127.0.0.1:6379>save
客户端4 127.0.0.1:6379>get key
对redis数据库执行4此指令顺序===> set set save get
注意：save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。

bgsave指令

命令：bgsave
作用：手动启动后台保存操作，但不是立即执行

bgsave指令工作原理

注意： bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

2.1.2 RDB自动

配置：save second changes

作用 : 满足限定时间范围内key的变化数量达到指定数量即进行持久化。

参数 :

second：监控时间范围
changes：监控key的变化量

位置 : 在conf文件中进行配置

注意： save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的。

save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系。

save配置启动后执行的是bgsave操作。

2.2 RDB优缺点

RDB优点

1.RDB是一个紧凑压缩的二进制文件，存储效率较高。

2.RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景。

3.RDB恢复数据的速度要比AOF快很多。

4.RDB节省磁盘空间。

RDB缺点

1.Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。

2.虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

3.RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据。

4.Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象。

2.2 AOF

概念：AOF(append only file)持久化是以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的；与RDB相比可以简单描述为改记录数据为记录数据产生的过程AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。AOF持久化可以通过配置文件中的不同策略来控制写入的频率，包括每次写入、每秒写入一次、不写入等。AOF持久化相对于RDB持久化来说，数据更加安全，但是文件体积较大，恢复速度较慢。

AOF执行过程

1.客户端的请求写命令会被append追加到AOF缓冲区内；

2.AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

3.AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

4.Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的。

AOF写数据三种策略(appendfsync)

always(每次）
每次写入操作均同步到AOF文件中，数据零误差，性能较低
everysec（每秒）
每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高
在系统突然宕机的情况下丢失1秒内的数据
no（系统控制）
由操作系统控制每次同步到AOF文件的周期，整体过程不可控

AOF相关配置

配置：appendonly yes|no
作用：是否开启AOF持久化功能，默认为不开启状态
配置：appendfsync always|everysec|no
作用：AOF写数据策略
配置：appendfilename filename
作用：AOF持久化文件名，默认文件名未appendonly.aof，建议配置为appendonly-端口号.aof
配置：dir
作用：AOF持久化文件保存路径，与RDB持久化文件保持一致即可

AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

AOF重写作用

1.降低磁盘占用量，提高磁盘利用率

2.提高持久化效率，降低持久化写时间，提高IO性能

3.降低数据恢复用时，提高数据恢复效率

2.2.1 AOF优缺点

AOF优点

1.备份机制更稳健，丢失数据概率更低。

2.可读的日志文本，通过操作AOF文件，可以处理误操作。

AOF缺点

1.比起RDB占用更多的磁盘空间

2.恢复备份速度要慢。

3.每次读写都同步的话，有一定的性能压力。

2.3 RDB和AOF的区别

持久化方式	RDB	AOF
占用存储空间	小（数据级：压缩）	大（指令级：重写）
存储速度	慢	快
恢复速度	快	慢
数据安全性	会丢失数据	依据策略决定
资源消耗	高/重量级	低/轻量级
启动优先级	低	高

总结：官方推荐两个都启用，如果对数据不敏感，可以选单独用RDB，不建议单独用 AOF，因为可能会出现 Bug。如果只是做纯内存缓存，可以都不用。

三、Redis删除策略

3.1 过期数据

Redis是一种内存级数据库，所有数据均存放在内存中，内存中的数据可以通过TTL指令获取其状态：

XX ：具有时效性的数据
-1 ：永久有效的数据
-2 ：已经过期的数据或被删除的数据或未定义的数据

问：过期的数据真的删除了吗？答：不是的

3.2 数据删除策略

数据删除策略的目标：在内存占用与CPU占用之间寻找一种平衡，顾此失彼都会造成整体redis性能的下降，甚至引发服务器宕机或内存泄露。

3.2.1 定时删除

创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作。

优点：节约内存，到时就删除，快速释放掉不必要的内存占用。

缺点：CPU压力很大，无论CPU此时负载量多高，均占用CPU，会影响redis服务器响应时间和指令吞吐量。

总结：用处理器性能换取存储空间（拿时间换空间）。

3.2.2 惰性删除

数据到达过期时间，不做处理，等下次访问该数据时，如果未过期，返回数据；发现已过期，删除，返回不存在。

优点：节约CPU性能，发现必须删除的时候才删除。

缺点：内存压力很大，出现长期占用内存的数据。

总结：用存储空间换取处理器性能（拿空间换时间）。

3.2.3 定期删除

周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度。

优点1：CPU性能占用设置有峰值，检测频度可自定义设置。

优点2：内存压力不是很大，长期占用内存的冷数据会被持续清理。

总结：周期性抽查存储空间（随机抽查，重点抽查）。

3.2.4 删除策略对比

定时删除	节约内存，无占用	不分时段占用CPU资源，频度高	拿时间换空间
惰性删除	内存占用严重	延时执行，CPU利用率高	拿空间换时间
定期删除	内存定期随机清理	每秒花费固定的CPU资源维护内存	随机抽查，重点抽查

3.3 逐出算法

当新数据进入redis时，如果内存不足怎么办？

Redis使用内存存储数据，在执行每一个命令前，会调用freeMemoryIfNeeded()检测内存是否充足。如果内存不满足新加入数据的最低存储要求，redis要临时删除一些数据为当前指令清理存储空间。清理数据的策略称为逐出算法。
注意：逐出数据的过程不是100%能够清理出足够的可使用的内存空间，如果不成功则反复执行。当对所有数据尝试完毕后，如果不能达到内存清理的要求，将出现错误信息。抛出异常：(error) OOM command not allowed when used memory >'maxmemory'。

影响数据逐出的相关配置

maxmemory最大可使用内存

占用物理内存的比例，默认值为0，表示不限制,生产环境中根据需求设定，通常设置在50%以上。

maxmemory-samples每次选取待删除数据的个数

选取数据时并不会全库扫描，导致严重的性能消耗，降低读写性能。因此采用随机获取数据的方式作为待检测删除数据

maxmemory-policy删除策略

检测易失数据（可能会过期的数据集server.db[i].expires ）
① volatile-lru：挑选最近最少使用的数据淘汰
② volatile-lfu：挑选最近使用次数最少的数据淘汰
③ volatile-ttl：挑选将要过期的数据淘汰
④ volatile-random：任意选择数据淘汰
检测全库数据（所有数据集server.db[i].dict ）
⑤ allkeys-lru：挑选最近最少使用的数据淘汰
⑥ allkeys-lfu：挑选最近使用次数最少的数据淘汰
⑦ allkeys-random：任意选择数据淘汰
放弃数据驱逐
⑧ no-enviction（驱逐）：禁止驱逐数据（redis4.0中默认策略），会引发错误OOM（Out Of Memory）达到最大内存后的，对被挑选出来的数据进行删除的策略

四、企业级解决方案

4.1 缓存预热

“宕机”服务器启动后迅速宕机

问题排查

1. 请求数量较高。
2. 主从之间数据吞吐量较大，数据同步操作频度较高,因为刚刚启动时，缓存中没有任何数据。

解决方案

准备工作：

1. 日常例行统计数据访问记录，统计访问频度较高的热点数据。
2. 将统计结果中的数据分类，根据级别，redis优先加载级别较高的热点数据。

实施：

1. 使用脚本程序固定触发数据预热过程。
2. 如果条件允许，使用了CDN（内容分发网络），效果会更好。

总结：缓存预热就是系统启动前，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题。用户直接查询事先被预热的缓存数据。

4.2 缓存雪崩

缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。

解决方案：

给不同的Key的TTL添加随机值。
利用Redis集群提高服务的可用性。
给缓存业务添加降级限流策略。
给业务添加多级缓存。

4.3 缓存击穿

缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。

解决方案：

互斥锁方案：由于保证了互斥性，所以数据一致，且实现简单，因为仅仅只需要加一把锁而已，也没其他的事情需要操心，所以没有额外的内存消耗，缺点在于有锁就有死锁问题的发生，且只能串行执行性能肯定受到影响。
逻辑过期方案：线程读取过程中不需要等待，性能好，有一个额外的线程持有锁去进行重构数据，但是在重构数据完成前，其他的线程只能返回之前的数据，且实现起来麻烦。

4.4 缓存穿透

缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库。

解决方案：

缓存空对象
- 优点：实现简单，维护方便。
- 缺点： ①额外的内存消耗 ②可能造成短期的不一致
布隆过滤
- 优点：内存占用较少，没有多余key。
- 缺点： ①实现复杂 ②存在误判可能

顾唯.

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
非关系型数据库Redis(二）

与RDB相比可以简单描述为改记录数据为记录数据产生的过程AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。(Optimistic Lock) 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。概念：RDB是Redis的默认持久化方式，它通过将Redis的内存数据以快照的形式保存到磁盘上的一个二进制文件中，它恢复时是将快照文件直接读到内存里。发现已过期，删除，返回不存在。
复制链接

扫一扫