redis的数据类型的操作增删改查

redis的数据类型的操作增删改查

redis的高可用：

在集群当中有一个非常重要的指标，提供正常服务的时间的百分比（365天）99.9%

redis的高可用的含义要更加宽泛，正常服务是指标之一数据容量扩展，数据的安全性

在redis中实现这种高可用技术：持久化 主从复制，哨兵模式 cluster集群。

持久化: 持久化是最简单的高可用方法，主要作用是数据备份，也就是把redis缓存在内存中的数据保存到本地的硬盘中

redis持久化的两种方式：

1、RDB持久化：redis在内存中的数据定时保存到磁盘。（自动执行，手动执行）

2、AOF持久化：redis的操作日志，以追加的方式写入一个AOF的文件，类似于mysql的binlog。

rdb的持久化： 指在指定的时间间隔内，将内存中当前进程中的数据生成快照保存到硬盘（快照持久化），用二进制压缩存储

保存的文件名的后缀.rdb redis启动时可以直接读取快照文件，实现数据恢复。

rdb的触发机制

手动机制:save bgsave都可以省程RDB文件。

save创建RDB文件时，整个redis进程会被阻塞，期间redis将无法进行读写操作，直到RDB文件创建完成为止。

bgsave就是主从复制的机制

bgsave的特点就是父进程会通过fork机制创建一个子进程，子进程的创建过程中，父进程会阻塞，子进程创建完毕，主进程会解除阻塞，然后由子进程来创建RDB文件。创建完成之后，通知主进程更新通知信息。

save 900 1

900秒 当时间到900秒时，如果redis的数据至少发生一次变化，就会执行bgsave，

save 300 10

300 秒 时间到300秒时，如果redis的数据至少发生10次变化，就会执行bgsave，

save 60 10000

60秒 时间到60秒时，如果redis的数据至少发生一万次变化，就会执行bgsave，

sava 120 1000 bgsave

save 60 10000 bgsave

数据变动越多，执行的时间要越短，数据变动不大，时间间隔要长一点。

rdbcompression yes

开启rdb的文件压缩功能，在高并发场景建议关闭。

除了配置文件中的save m n 之外

主从复制，从节点执行全量复制操作，主节点会执行bgsave，把rdb文件传送给从节点。

关闭主进程，shutdown只会，会自动执行rdb的持久化

启动时加载：

发现rdb文件被损坏，日志中会打印错误，redis会拒绝启动。

redis-check-rdb修复rdb的持久化文件。

AOF持久化：

aof持久化是将redis的每一次读 写 删除命令记录到一个单独的.aof结尾的文件。查询操作由主进程记录。当redis重启时，再次执行AOF文件中的命令来恢复数据。

AOF的实时性更好，也是主流的持久化方案。

aof-load-truncated yes

用于判断AOF文件，如果被截断时的行为

yes：发现在被截断（写入过程中出现了异常，导致文件未能完全写入） redis会尽可能恢复文件中的数据，redis会继续运行

no：发现AOF文件被截断，redis将拒绝启动。

数据完整性要求比较高用no

注重数据服务器的可用性用yes

rdb是redis的默认持久化文件，但是一但开启AOF持久化，那么redis会以AOF的持久化文件作为最高优先级。

AOF的重写功能

1、随着时间增长，AOF文件当中的数据也会不断增加,AOF的文件也会也来越大，过大的AOF文件不仅仅会影响，也会导致数据恢复的时间过长。

文件重写是指定期的重写AOF文件，减小AOF文件的体积。AOF重写是把redis进程内的数据，转化为写的命令，同步到新的aof文件当中（不会额外的生成一个新的文件，只是在原内容当中进行压缩）。不会对原有的AOF文件进行任何读写的操作。

*文件重写虽然是AOF持久化强烈推荐的，但不是必须的，没有重写并不影响redis启动时读写数据，在实际中，会关闭自动的文件重写，通过定时任务来完成。

AOF同步文件的策略的三种方式

appendfsync always

写入过程中，会立刻调用redis系统的fsync 操作立刻写入到AOF文件，这次写入都执行同步，硬盘的性能有瓶颈，硬盘的寿命也会大大降低

appendfsync everysec：命令写入，调用write操作，write操作结束后，线程会返回。FSYNC同步文件操作由专门的线程，每秒调用一次，这是一个这种的策略，是性能喝安全性的平衡，是redis的默认配置，也是推荐配置

appendfsync no ：写入操作调用系统的write操作，不对AOF文件进行同步，操作系统来同步，同步周期30秒，文件同步的时间不可控，缓冲区会堆积大量数据，数据的安全也无法保证。

重写的出发条件是什么

1、手动触发

redis-cli bgrewriteaof

2、自动触发

auto-aof-rewrite-percentage 100

文件的大小超过基准的百分比，默认值就是100，文件的超过两倍时，执行bgrewriteaof，设置为0，禁用自动触发

100M 200M 200M 400M

auto-aof-rewrite-min-size 64mb

文件大于基准值，才会进行重写，整个值时AOF文件执行重写的最小值，避免开始穷redis后，文件太小，然后频繁的进行重写。

AOF为什么能够压缩文件；

1、重写的过程中，过期的数据不会写入文件

2、无效的命令不在写入文件，数据被重复设置，set test=1 set test 2 删除的数据也不会写入

多条命令合并成一个 sadd test1 v1 sadd test1 v2

sadd test1 v3 sadd test1 v1 v2 v3

重写之后AOF文件当中的命令减少了，空间也少了，恢复速度也增增加了 重写不是必须的

RDB和AOF之间的优缺点

RDB的优点:文件体积小，如果需要备份，网络传输速度很快，适合全量复制，恢复速度也比AOF要快

缺点：做不了实时的持久化，数据如此重要不能够容忍丢失的，另外RDB需要满足特定的格式，兼容性很差，老版本的RDB不支持新版本，（redis的版本一定要一致）5.0.7版本

AOF的优点；秒级的持久化。兼容性好，文本格式保存的命令。

缺点：文件大，恢复速度慢。AOF持久化需要频繁的向磁盘写入数据，磁盘的io压力也很大，对redis主进程的性能也会有一定影响。

重点：

持久化方式：redis的持久化也算是高可用的一种，通过备份文件来恢复数据，冷备份。

rdb ：sava线上禁用，bgsave

AOF：实时持久化写入的是操作的命令，除了查 set del 会记录 get select不计入

实时记录恢复方式类似于mysql的binlog

重写；推荐但不是必须的，重写也是主进程创建一个子进程，在过程中产生的数据以及同步策略都会写入到AOF当中。

实验：重复写入数据

重复插入同一个数据只会写入最后一个设置的数据