Redis高可用~~~

一、Redis持久化

1、RDB持久化：将Reids在内存中的数据库记录定时保存到磁盘上（类似快照）。
2、AOF持久化：将Reids的操作日志以追加的方式写入文件，类似于MysQL的binlog。(基于日志持久化方式)
3、由于AoF持久化的实时性更好，即当进程意外退出时丢失的数据更少，因此AoF是目前主流的持久化方式，RD持久化基本都会开启（用于集群）。

一、RDB持久化

RDB持久化是指在指定的时间间隔内将内存中当前进程中的数据生成快照保存到硬盘（因此也称作快照持久化）压缩存储，保存的文件后缀是rdb；当Redis重新启动时，可以读取快照文件恢复数据。
1、周期性：1-10秒（会进行一定的限制，第二周期过于短暂会导致数据同步冗余的情况)
2、保存形式：二进制压缩存储(.rdb )
3、可用于恢复，redis重启后，缓存中的数据会清空，此时redis 中的数据就是基于.rdb文件进行恢复的。

触发条件

RDB持久化的触发分为手动触发和自动触发两种。

一、手动触发

save命令和bgsave命令都可以生成RDB文件。
1、save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求.而ibgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程（即Redis主进程)则继续处理请求。
2、bgsave命令执行过程中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用往往生产环境bgsave依然不允许轻易使用。

手动触发，如下图：

二、自动触发

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

[root@redis utils]# vim /etc/redis/6379.conf

自动触发，如下图：

ps：除了以上方式，还有其他情况会触发bgsave
1、在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令，并将rdb文件发送给从节点。
2、执行shutdown命令时，自动执行rdb持久化。
执行过程：
(1) Redis父进程首先判断：当前是否在执行save，或bgsave/bgrewriteaof的子进程，如果在执行则bgsave命令直接返回。bgsave/bgrewriteaof的子进程不能同时执行，主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。
(2)父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令。
(3）父进程fork后，bgsave命令返回"Background saving started"信息并不再阻塞父进程，并可以响应其他命令。
(4)子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换。
(5) 子进程发送信号给父进程表示完成，父进程更新统计信息。

二、AOF持久化

RDB持久化是将进程数据写入文件，而Aor持久化，则是将Redis执行的每次写及删除命令记录到单独的日志文件中，查询操作不会记录。当Redis重启时优先执行AOF文件中的命令来恢复数据。

[root@redis utils]# vim /etc/redis/6379.conf

[root@redis utils]# /etc/init.d/redis_6379 restart

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

二、RDB和AOF区别

RDB持久化
1、优点：RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AoF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小。
2、缺点：RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，RDB文件需要满足特定格式，兼容性差(如老版本的Redis不兼容新版本的RDB文件)。
3、对于RDB持久化，一方面是bgsave在进行fork操作时Redis主进程会阻塞，另一方面，子进程向硬盘写数据也会带来io压力。
AOF持久化
1、与RDB持久化相对应，AOF的优点在于支持秒级持久化、兼容性好，缺点是文件大、恢复速度慢、对性能影响大。
2、对于AOF持久化，向硬盘写数据的频率大大提高(everysec策略下为秒级)，IO压力更大，甚至可能造成AOF追加阻塞问题。AOF文件的重写与RDB的bgsave类似，会有fork时的阻塞和子进程的IO压力问题。相对来说，由于AOF向硬盘中写数据的频率更高，因此对Redis主进程性能的影响会更大。

三、Redis性能管理

一、查看Redis内存使用

#查看内存使用
[root@redis utils]# redis-cli
127.0.0.1:6379> info memory
# Memory
used_memory:853512
used_memory_human:833.51K
used_memory_rss:10489856
used_memory_rss_human:10.00M
used_memory_peak:4954264
used_memory_peak_human:4.72M
used_memory_peak_perc:17.23%
used_memory_overhead:841110
used_memory_startup:791416
used_memory_dataset:12402
used_memory_dataset_perc:19.97%
allocator_allocated:1460960
allocator_active:1867776
allocator_resident:8966144
total_system_memory:3954196480
total_system_memory_human:3.68G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.28
allocator_frag_bytes:406816
allocator_rss_ratio:4.80
allocator_rss_bytes:7098368
rss_overhead_ratio:1.17
rss_overhead_bytes:1523712
mem_fragmentation_ratio:12.91
mem_fragmentation_bytes:9677368
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:49694
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0

二、内存碎片率

操作系统分配的内存值used_memory_rss除以Redis使用的内存值used_memory计算得出内存碎片是由操作系统低效的分配/回收物理内存导致的(不连续的物理内存分配)。

查看

1、内存碎片率稍大于1是合理的，这个值表示内存碎片率比较低
2、内存碎片率超过1.5，说明Redis消耗了实际需要物理内存的150号，其中50号是内存碎片率。需要在redis-cli工具.上输入shutdown save命令，并重启Redis服务器。
3、内存碎片率低于1的，说明Redis内存分配超出了物理内存，操作系统正在进行内存交换。需要增加可用物理内存或减少Redis内存占用。

三、内存交换

redis实例的内存使用率超过可用最大内存，操作系统将开始进行内存与swap空间交换。
避免方法
1、针对缓存数据大小选择安装Redis实例
2、尽可能的使用Hash数据结构存储
3、设置key的过期时间

四、内回收key

[root@redis utils]# vim /etc/redis/6379.conf

##设置选项注释
noenviction :禁止淘汰数据
volatile-lru :使用LRU算法从已设置过期时间的数据集合中淘汰数据
volatile-ttl :从已设置过期时间的数据集合中挑选即将过期的数据淘汰
volatile-random :从已设置过期时间的数据集合中随机挑选数据淘汰
allkeys-lru :使用LRU算法从所有数据集合中淘汰数据
allkeys-random :从数据集合中任意选择数据淘汰