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文件创建完成为止

save的数据流程图

在redis数据库中创建几个列表set test1 1 set test2 2set test3 3
save进入备份文件目录
cd /var/lib/redis/6379
cp dump.rdb /opt清空数据库
停服务
/etc/init.d/redis_6379 stop把复制到opt目录下的dump.rdb复制到etc/init.conf/6379目录下开启服务
/etc/init.d/redis_6379 start
刚刚创建数据库的文件，也恢复了

bgsave的数据流程

bgsave就是主从复制的机制

bgsave工作流程

主进程会通过fork机制创建一个子进程，子进程的创建过程中，主进程会阻塞，子进程创建完毕，主进程解除阻塞

子进程来创建RDB文件，创建完成之后，通知主进程更新通知信息

自动存储机制

vim /etc/redis/6379.conf
219行
save 900 1
900秒	当时间到900秒时，redis的数据至少发生了1次变化，就执行bgsavesave 300 10
300秒	当时间到300秒时，redis的数据至少发生了10次变化，就执行bgsavesave 60 10000
60秒	当时间到60秒时，redis的数据至少发生了10000次变化，就执行bgsave数据变动越多，执行的时间要越短，数据变动不大，时间间隔242行
rdbcompression yes
开启RDB的文件压缩功能，在高并发场景建议关闭264行
dir /var/lib/redis/6379 
保存持久化文件目录

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

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

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

启动时加载

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

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

AOF持久化

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

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

vim /etc/redis/6379.conf
700行
appendonly yes 
yes是开启持久化功能appendfilename "appendonly.aof"aof-load-truncated yes
用于判断AOF文件，如果被截断时的行为
yes：发现被截断（写入过程中出现异常，导致文件未能完全写入），redis会尽可能的恢复文件中的数据，redis会继续运行
no：发现AOF文件被截断，redis将拒绝启动
如果你对数据完整性的要求高 no注重数据服务器的可用性 yes

aof备份和恢复

进入数据库并创建
set test1 1
set test2 2
set test3 3删除库内容关闭服务
/etc/init.d/redis_6379  stop进入日志文件
vim /var/lib/redis/appendonly.aofflushall上面*以下全部删除在开启服务
/etc/init.conf/6379 start 
刚刚删除的文件，就会恢复

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

AOF的重写功能

为什么要重写？

随着时间增长，AOF文件当中的数据也会不断增加，AOF的文件也会越来越大，过大的AOF文件不仅仅会影响服务器的正常运行，也会导致导致数据恢复的时间过长

什么叫重写？

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

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

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

vim /etc/redis/6379.conf
729行#appendfsync always
appendfsync everysec
#appendfsync noappendfsync always  写入过程中，立刻调用redis系统的fsync操作写入到AOF文件，这次写入都执行同步，硬盘的性能有瓶颈，硬盘的寿命也会大大降低appendfsync no	写入操作调用系统的write操作，不对AOF文件进行同步，操作系统来同步，同步周期30秒，文件同步的时间不可控，缓冲区堆积大量数据，数据的安全也无法保证appendfsync everysec	命令写入，调用write操作，write操作结束后，线程会返回，FSYNC同步文件操作由专门的线程，每秒调用一次，这一个折中的策略，是性能和安全性的平衡，是redis的默认配置，也是推荐配置

重写的触发条件是什么？

1、手动触发

redis-cli bgrewriteaof 执行重写的命令

查看日志文件

手动触发的数据流程

对原有的数据，只是保留纪录没有其他的操作

2、自动触发

vim /etc/redis/6379.conf
771行和772行
auto-aof-rewrite-percentage 100
文件的大小查过基准的百分比，默认值就是100，文件的超过两倍时，执行bgrewriteaof 设置为0 禁用自动触发auto-aof-rewrite-min-size 64mb
文件大于基准值，才会进行重写，这个值是AOF文件执行重写的最小值，避免开启启动redis后，文件太小，然后频繁的进行重写