redis的高可用

redis-cli -h 192.168.233.10 -p 6379

redis的数据类型的增删改查

redis的高可用在集群当中有一个非常重要的指标，提供正常服务的时间的百分比(365天)

99.9%

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

在redis种实现高可用技术：①持久化；②主从复制；③哨兵模式；④cluster集群

持久化

持久化是最简单的高可用方法

主要作用是数据备份，也就是把redis缓存在内存中的数据保存到本地的硬盘中（冷备份方式）

redis持久化的两种方式

1、RDB持久化

redis在内存中的数据定时保存到磁盘

自动执行、手动执行皆可

指在指定的时间间隔内，将内存中当前进程中的数据生成快照保存到硬盘（快照持久化），用二进制压缩存储。保存的文件名的后缀是 .rdb。redis启动时，可以直接读取快照文件，实现数据恢复

RDB的触发机制

①手动机制

save 和 bgsave 都可以生成RDB文件

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

bgsave  

bgsave就是主从复制的机制

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

②自动机制

219gg

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

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

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

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

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

如果启动时加载rdb文件被损坏，日志中会打印错误，redis会拒绝启动。需要用redis-check-rdb 修复RDB的持久化文件

242gg

开启RDB压缩功能

在高并发场景建议关闭

264gg

保存持久化文件的位置

2、AOF持久化

redis的操作日志以追加的方式写入一个AOF的文件，类似于MySQL的binlog

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

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

700gg（no改成yes

704gg

796gg

Q：出现截断怎么办？

aof-load-truncated yes

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

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

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

A：对数据完整性要求高，用no；注重数据服务器的可用性，用yes。在可以的情况下，一般是yes

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

AOF的重写功能

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

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

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

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

729gg

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

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

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

重写的触发条件

1、手动触发

redis-cli bgrewriteaof

工作流程

2、自动触发

771gg

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

64mb 文件大于基准值才会进行重写。这个值是AOF文件执行重写的最小值。避免开始启动redis后，文件太小，然后频繁的进行重写。这个必须要有。

创建定时任务，100必须改成0

AOF重写为什么可以压缩文件？

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

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

3、多条命令合并成一个。sadd test1 v1 sadd test1 V2 sdd test1 3

sadd test1 V1 V2 W3

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

RDB和AQF之间的优缺点:

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

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

AOF的优点: 秒级持久化。兼容性好（文本格式保存的是命令）

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

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

持久化的两种方法：RDB和AOFRDB：save线上禁用；bgsave

AOF：实时持久化。写入的操作的命令，除了查 set del会记录get select不入；实时记录，恢复方式类似于MySQL的binlog

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