redi可持久化配置

回顾：rpcbind111 nfs2049

redis高可用高可用是指服务器可以正常访问的时间，衡量的标准是在多长时间内可以提供正常服务（99.9%，99.99%，99.999%等）

还要考虑提供主从分离，快速容灾技术，考虑数据容量的扩展，数据安全不丢失等，

持久化：持久化最简单的高可用方法主要通过数据备份，保证数据不会因进程退出而不丢失

主从复制：主从复制是高可用的基础，哨兵和集群都是在主从复制的基础上实现的高可用，主从复制主要实现数据的多机备份，以及对读操作的负载均衡和简单故障回复，，缺陷故障回复无法自动化，写操作无法负载均衡，存储能力受到单机的限制

哨兵：主从复制的基础上，哨兵实现自动化故障回复，缺陷写操作无法负载均衡，存储能力收到单机的限制（单个组）

cluster集群：通过集群redis剞劂写操作无法负载均衡，以及存储能力收到单机限制的问题，实现较为完善的高可用方案（六台以上redis）

## Redis持久化 ##

方法：持久化的功能:Bedis是内存数据库，数据都是存储在内存中，为了避免服务器断电等原因导致redis进程异常退出后数据的永久丢失，需要定期将Rdis中的数据以某种形式(数据或命今)从内存保存到硬盘;当下次Redis重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，以将持久化文件拷贝到一个远程位置。

rdb持久化：原理是将reids在内存中的数据记录定时保存在磁盘上（丢失58s）

aof：原理将redis的操作日志以追加的方式写入文件，类似于mysql的binlog（丢失1s）

rdb持久化是指在指定时间间隔内将内存中当进程中数据生成快照婢妾会做二进制压缩，保存的文件以rdb结尾

重启redis时，可以读取快照文件数据恢复

触发条件

手动出发：save会阻塞服务器进程到rdb文件创建完成fork（父进程生成子进程过程）

自动出发：

在自动触发RDB持久化时，Redis 也会选择bgsave而不是save来进行持久化。

自动触发最常见的情况是在配置文件中通过 save m n 指定当m秒内发生n次变化时，会触发bgsave。

save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。

而bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程（即Redis主进程）则继续处理请求。

bgsave命令执行过程中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用，本地的源下载配置文件位置vim /usr/local/redis/conf/redis.conf

vim /etc/redis/6379.conf
--219行--以下三个save条件满足任意一个时，都会引起bgsave的调用
save 900 1 ：当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 300 10 ：当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
save 60 10000 ：当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave
--254行--指定RDB文件名
dbfilename dump.rdb
--264行--指定RDB文件和AOF文件所在目录
dir /var/lib/redis/6379
--242行--是否开启RDB文件压缩
rdbcompression yes

save设置规则

配置文件save m n设置定时保存其他一些过程会触发bgsave

主从复制场景，从节点全量复制

shutdown自动执行rdb持久化

rdb持久化过程

bgsave命令执行过程

2，执行流程

(1) Redis父进程首先判断:当前是否在执行save，或bgsave/bgrewriteaof的子进程，如果在执行则bgsave命令直接返回.bgsave/bgrewriteaof的子进程不能同时执行，主要是基于性能方面的考虑:两个并发的了进程同时预行人量的盛盘写操作，可能引起”重的性能题。

(2)父进程执行fork操作创建子进程，这个过程中父进程是阻寒的，Redis不能执行来自客户端的任何命令(3)父进程fork后，bgsave命令返回"Background saving started"信息并不再阻塞父进程，并可以响应其他命令

(4)子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换

(5)子进程发送信号给父进程表示完成，父进程更新统计信息

3.启动时加载RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更高，因此当AOF开启时，Bedis会优先载入GOF文件来恢复数据，只有当AOF关团时，才会在Redis服务器启动时检测RB文件，并自动载入。服务器载入RDB文件期间处于阳寒状态，直到载入成为止。Redis载入RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。

aof持久化

aof文件重写流程

rdb持久化是将进程数据写入文件，而aof持久化，则是将redis执行的没次写，删除命令记录到单独的日志，查询操作不会记录；

当redis重启是在执行aof

appendonly.aof

aof-lord-truncated yes 宕机等原因导致最后一条命令错误忽略最后一行错的文件

保存的文件

cd /usr/local/redis/data/appendonly

执行流程（过期数据删除，重复数据压缩）

由于需要记录Redis的每条写命令，因此AOF不需要触发，下面介绍AOF的执行流程。

AOF的执行流程包括:命令追加(append):将Redis的写命令追加到缓冲区aof_buf;文件写入(write)和文件同步(sync): 根据不同的同步策略将aof_buf中的内容同步到硬盘;文件重写(rewrite): 定期重写AOF文件，达到压缩的目的。

(1) 命令追加(append)

redis先将写命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命今都直接写入硬盘，导致硬盘IO成为Redis负载的瓶颈。命令追加的格式是Redis命今请求的协议格式，它是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单避免二次开销等优点。在AOE文住中，除了用于指定数据库的select命令(如select 0为选中0号数据库) 是由Redis添加的，其他都是客户端发送来的写命令。

(2) 文件写入(write)和文件同步(sync)Redis提供了多种AOE缓存区的同步文件策略，策略涉及到操作系统的write函数和fsync函数，说明如下:为了提高文件写入效率，在现代操作系统中，当用户调用write函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。这样的换作虽然提高了效率，但也带来了安全问题，如果计算机停机，内存缓区中的数据会丢失;因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性

AOF缓存区的同步文件策略存在三种同步方式，它们分别是:vim /usr/local/redis/conf/redis.conf

-1439--

appendfsync always;

appendfsync no;

appendfsync everysec;

文件重写

AOF重写是把redis进程内的数据转化为写命令mysql dump进程只有现有数据的写入操作，二进制日志中

文件重写之所以能够压缩AOE文件，原因在于:。过期的数据不再写入文件无效的命令不再写入文件:如有些数据被重复设值(set mykey vlset mykey v2)、有些数据被删除了(set myset vl，del myset)等多条命今可以合并为一个: 如sadd myset vl，sadd myset v2，sadd myset v3可以合并为sad myset vl v2 v3通过上述内容可以看出，由于重写后AOE执行的命令减少了，文件重写既可以减少文件占用的空间，也可以加快恢复速度。文件重写的触发，分为手动触发和自动触发.

手动触发:直接调用bgremriteaof命令，该命令的执行与bgsave有些类似:都是fork子进程进行具体的工作，且都只有在fork时阳塞。

自动触发:通过设置auto-aof-rewrite-min-size选项和auto-aof-rewrite-percentage选项来自动执行BGREMRITEAOF。只有当aut-aof-remrite-min-sizeauto-aof-rerite-percentage两个选项同时满足时，才会自动触发AOF重写，即bgrewriteaof操作。

包括其他命令

vim /usr/local/redis/conf/redis.conf

1480

auto-aof-rewrite-percentage 100

当前AOF文件大小(即aof_current_size)是上次日志重写时AOE文件大小(aof_base_size)两倍时，发生BGREMRITEAOF操作

auto-aof-rewrite-min-size 64mb

当前AOE文件执行BGREMRITEAOE命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOE

rdb持久化和aof优缺点

RDB持久化优点:EDB文件紧凑，体积小，网络传输快，适合全量复制，恢复速度比EOE快很多。当然，与A相比，EDB最重要的优点之一是对性能的影响相对。

缺点:EDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很名时候是于法接受的，因此AOF持久化成为主流。此外，RDB文件需要满足特定格式，兼容性差(如老版本的Redis不兼容新版本的RDB文件)。对于RDB持久化，一方面是basave在进行fork操作时Redis主进程会阻塞，另一方面，子进程向硬写数据也会带来IO压力。

AOF持久化与RDB持久化相对应，AOE的优点在于支持秒级持久化、兼容性好，缺点是文件大、恢复速度慢、对性能影响大。对于AOF持久化，向硬盘写数据的频率大大提高(everysec策略下为秒级)，10压力更大，甚至可能造成AOF追加阻塞问题。AOE文件的重写与RDB的bqsave类似，会有frk时的阻塞和子进程的I0压力问题。相对来说，由于AOE向硬盘中写数据的频率更高，因此对Redis主进程性能的影响会更人。

rdb持久化和aof的区别？

rdb持久化，定时把redis内存中的数据进行快照和压缩保存rdb保存的文件占用空间小，网络速度快，恢复速度比aof快，但兼容性较差，rdb持久化期间在fork子进程时会阻塞父进程，由于是定时持久化，实时性不如aof

aof持久化，以追加的方式将redis写的操作命令记录到文件中，实时性较好，支持秒级持久化，兼容性较好，缺点是持久化的问文件占用空间较大，恢复速度较慢，对io性能消耗更大aof文件重写期间，在fork子进程时会阻塞父进程，且对io性能损耗更大

info memory查看内存使用

mem_fragmentation_ratio 内存碎片率

used_memiry_rss 是redis向操作系统申请的内存

used_memiry 是redis中数据占用的内存

used_memiry_peak 是内存使用的峰值

redis实例的内存使用率超过最大内存，操作系统开始进行内存与swap空间交换

避免内存交换的方法：

针对缓存数据大小选择安装redis实例

设置key的过期时间

尽可能使用hash存储数据结构

#内存碎片如何产生的？
Redis内部有自己的内存管理器，为了提高内存使用的效率，来对内存的申请和释放进行管理。
Redis中的值删除的时候，并没有把内存直接释放，交还给操作系统，而是交给了Redis内部有内存管理器。
Redis中申请内存的时候，也是先看自己的内存管理器中是否有足够的内存可用。
Redis的这种机制，提高了内存的使用率，但是会使Redis中有部分自己没在用，却不释放的内存，导致了内存碎片的发生。

#跟踪内存碎片率对理解Redis实例的资源性能是非常重要的：
●内存碎片率在1到1.5之间是正常的，这个值表示内存碎片率比较低，也说明 Redis 没有发生内存交换。
●内存碎片率超过1.5，说明Redis消耗了实际需要物理内存的150%，其中50%是内存碎片率。
●内存碎片率低于1的，说明Redis内存分配超出了物理内存，操作系统正在进行内存交换。需要增加可用物理内存或减少 Redis内存占用。

内存回收策略

key回收策略默认是禁止删除

vim /usr/local/redis/conf/redis.conf

1149

volatile-lru移除最近最少的key，针对设置ttl的key

volatile-ttl即将过期的键

volatile-random随机ttl里设置的key随机删

allkeys-lru最少

allkeys-random从数据集合随机淘汰key

redis优化

开启aof优化

设置config set activefrag yes 开启内存碎片自动清理或，定时执行memory purge清理内存碎片