Radis高可用

Redis高可用

一、Redis如何实现高可用

​ 持久化：众所周知Redis运行在内存中，如果服务器宕机内存负的数据就无了，所有我们需要讲运行在内存中的数据保存在磁盘上这就 是持久化。

​ 主从复制：主从复制是该可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用。主从复制主要实现了数据的多机备份，以 及对于操作的负载均衡和简单的故障恢复。当然主从复制有些缺陷比如Redis和Mysql一样有一个缺陷就故障恢复无法自动 化，写操作无法负载均衡，存储能力收到单机的限制

​ 哨兵：从主从复制的基础上哨兵实现了自动化的故障切换。缺陷：写操作无法负载均衡，存储能力收到单机的限制

​ 群集：通过集群解决了写操作无法负载均衡以及存储能力受到单机限制的问题，实现了较为完善的高可用方案

二、Redis持久化

1.什么是持久化

​ Redis是内存数据库，数据都是存储在内存中，为了避免服务器断电等原因导致Redis进程异常退出后导致数据丢失，需要定期将Redis中的数据以某种形式（数据或命令）从内存保存到硬盘中，下次重启Redis时利用持久化文件实现数据恢复,除此之外为了进行容灾备份，可以将持久化文件拷贝到异地

2.Redis两个持久化

​ RDB持久化: 将内存中的数据定时记录到磁盘上

​ AOF持久化: 将Redis的操作日志以追加的方式写入文件，和Mysql的二进制文件类似

三、RDB持久化

​ 在指定的时间间隔内将内存中的进程中的数据生成快照保存到硬盘（因此也称做快照持久化），用二进制压缩存储，保存的文件后缀是rdb；当Redis重新启动时，可读取快照文件恢复数据。

3.1触发条件

​ （1）手动触发

​ save命令和bgsave命令都可以生成RDB文件

​ （2）save和bgsave的区别

​ save命令会阻塞Redis进程直到RDB文件创建完毕，属于同步阻塞，在返回结果前服务器将无法处理任意请求

​ bgsave会创建一个子进程，由子进程来负责创建RDB文件，而父进程（Redis的主进程）为异步非阻塞将可以继续处理请求

e

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lTFByFmO-1663499514805)(C:/Users/mogu/Downloads/%E6%9C%AA%E5%91%BD%E5%90%8D%E6%96%87%E4%BB%B6.png)]

​ （3）自动触发

​ 命令：save m n

​ 指当m秒内数据发生了n次变化时会触发bgsave

​ 对配置文件修改：vim /etc/redis/6379.conf

​ （220）满足以下任意条件就会触发bgsave[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JvXYYWSU-1663499514806)(C:/Users/mogu/AppData/Roaming/Typora/typora-user-images/image-20220821110922783.png)]

​ （255） 指定RDB文件名

​ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uoUVZ4Zm-1663499514806)(C:/Users/mogu/AppData/Roaming/Typora/typora-user-images/image-20220821111033342.png)]

​ （265） 指定RDB文件或AOF文件所在的位置[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EYXWU2Nk-1663499514807)(C:/Users/mogu/AppData/Roaming/Typora/typora-user-images/image-20220821111139744.png)]

​ （243）是否对RDB文件进行压缩[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-j4adId6k-1663499514807)(C:/Users/mogu/AppData/Roaming/Typora/typora-user-images/image-20220821111314714.png)]

3.2除了save m n 以外，还有一些其他情况会触发bgsave：

​ ●在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令，并将rdb文件发送给从节点。
​ ●执行shutdown命令时，自动执行rdb持久化

3.3启动时加载

​ RDB文件载入工作是在服务器启动时自动执行的，但是由于AOF优先级更高，所以当开启AOF时,Redis会优先执行AOF文件来恢复数据；只有当AOF关闭的时候服务器才会检测RDB文件并自动载入，当然载入RDB时服务器会处于阻塞状态，直到载入完成为止。

四、AOF持久化

	AOF与RDB面向的对象不同，RDB是面向数据，将数据保存到文件中，而AOF面向的的是对Redis数据修改的的记录（写、删除的语句），将记录保存到文件中，Redis重启时再次执行AOF文件中的命令来恢复数据（和Mysql二进制文件恢复数据执行sql脚本类似）

4.1.开启AOF

​ redis默认是RDB，所以我们得手动开启AOF从配置文件中打开

vim /etc/redis/6379.conf
 
700行修改，开启AOF
appendonly yes
 
704行指定AOF文件名称
appendfilename "appendonly.aof"
 
796行是否忽略最后一条可能存在问题的指令
aof-load-truncated yes
 

4.2执行流程

​ 和RDB不同的是AOF是记录没条修改数据的命令，所以没有触发条件（或者可以说触发条件就是每一次修改数据），下面介绍下执行流程

​ 1.命令追加（append）：将Redis写的命令追加到缓冲区

​ 2.文件写入（write）：和文件同步（ sync）：根据不同的同步策略将aof_buf（缓冲区）的内容同步到硬盘

​ 3.文件重写（rewrite）：定期重写AOF文件，达到压缩的目的

​ （1）命令追加

​ 首先我们将命令追加到硬盘而不是直接写入文件，主要是为了避免每次有命令就写到硬盘导致硬盘I/O成redis的负载瓶颈。

​ 命令追加的格式是Redis命令请求的协议格式，它是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单避免二次开销等优点。在AOF文件中，除了用于指定数据库的select命令（如select 0为选中0号数据库）是由Redis添加的，其他都是客户端发送来的写命令。

​ （2）文件写入和文件同步

​ Redis提供了多种AOF缓存区的同步文件策略，策略涉及到write函数和fsync函数

​ 正常来说，用户调用write函数将数据写入文件时，操作系统通常会写入缓冲区，等缓冲区被写满或超出指定的阈值时才会写入硬盘中，所以在这期间如果服务器宕机，缓冲区的是位于内存中，代表缓冲区的数据将丢失。因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。

​ 修改配置文件：vim /etc/redis/6379.conf

​ 在729到733行选择三种策略

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-B2AMj4Ug-1663499514808)(C:/Users/mogu/AppData/Roaming/Typora/typora-user-images/image-20220821120541339.png)]

​ appendfsync always：命令写入缓冲区后会立即调用fsync同步到AOF文件，fsync完成后线程立即返回。简单的来说就是每次有命令都要同步到AOF文件，大量的请求到Redis是磁盘的I/O性能将会拖累Redis的性能

​ appendfsync everysec no：命令写入缓冲区后由系统调用write操作，不会对AOF文件做fsync同步；通常阈值为30秒及同步周期为30秒,这种情况下缓冲区堆积的数据是不可控的（鬼知道这30秒能有几条数据）。

​ appendfsync everysec ：命令写入缓冲区后，每秒调用一次fsync同步，everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。

​ （3）文件重写

​ 随着时间增长，Redis对数据修改的命令会主键变多，原先的AOF文件会愈发臃肿，我们会选择将Redis的数据转化为写的命令同步到新的AOF文件中，当然我们的同步只会对新文件操作，不会影响旧文件

​ 文件重写之所以能够压缩AOF文件，原因在于：

​ 过期的数据不再写入文件
​ 无效的命令不再写入文件：如有些数据被重复设值(set mykey v1, set mykey v2)、有些数据被删除了(sadd myset v1, del myset)等。
​ 多条命令可以合并为一个：如sadd myset v1, sadd myset v2, sadd myset v3可以合并为sadd myset v1 v2 v3。
​ 通过上述内容可以看出，由于重写后AOF执行的命令减少了，文件重写既可以减少文件占用的空间，也可以加快恢复速度。

​ 当然文件重写也分为自动触发和手动触发

​ 自动触发：自动触发要修改配置文件的两个参数分别为auto-aof-rewrite-percentage 100 和auto-aof-rewrite-min-size 64mb

​ auto-aof-rewrite-percentage 100: 当AOF文件的大小是上一次重写时的两倍时会自动触发重写

​ auto-aof-rewrite-min-size 64mb:执行重写的最小值，避免刚开始启动Redis时由于文件尺寸较小导致频繁重写

vim /etc/redis/6379.conf

 766 # is useful to avoid rewriting the AOF file even if the percentage increase
 767 # is reached but it is still pretty small.
 768 #
 769 # Specify a percentage of zero in order to disable the automatic AOF
 770 # rewrite feature.
 771 
 772 auto-aof-rewrite-percentage 100
 773 auto-aof-rewrite-min-size 64mb
 774 
 775 # An AOF file may be found to be truncated at the end during the Redis
 776 # startup process, when the AOF data gets loaded back into memory.
 777 # This may happen when the system where Redis is running
 778 # crashes, especially when an ext4 filesystem is mounted without the
 779 # data=ordered option (however this can't happen when Redis itself
 780 # crashes or aborts but the operating system still works correctly).

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

​ 流程

1.首先父进程判断是否在执行bgsave或bgrewriteaof进程，如果是直接返回，如果没有调用fork创建子进程，在此过程中系统是阻塞的

2.fork完bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父进程，可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制的正确。

3.但由于fork的机制，子进程只会共享fork操作时的内存数据（及此时数据为静止的）。但由于父进程又在响应其他请求，所以为了防止数据的不一致，在生成新AOF期间Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区。

4.子进程会更具内存快照，按照命令合并规则写到新的AOF文件

5.子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息，具体可以通过info persistence查看。

6.父进程将重写缓冲区的数据同步到新AOF文件，这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。

7.使用新的AOF文件替换老文件，完成AOF重写。

4.3启动时加载

​ 当AOF开启时，先载入AOF，只有当AOF关闭服务器才会读RDB文件来恢复数据，当AOF没有数据时即使RDB存在如果不关闭AOF依然不会读RDB

​ Redis载入AOF文件时，会对AOF文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。但如果是AOF文件结尾不完整(机器突然宕机等容易导致文件尾部不完整)，且aof-load-truncated参数开启，则日志中会输出警告，Redis忽略掉AOF文件的尾部，启动成功。aof-load-truncated参数默认是开启的。

五、RDB和AOF的优缺点

​ RDB持久化：

​ 优点：RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AOF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小。

​ 缺点：无法做到实时持久化，且RDB文件需要满足特定的格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。

对于RDB持久化，一方面是bgsave在进行fork操作时Redis主进程会阻塞，另一方面，子进程向硬盘写数据也会带来IO压力。

​ AOF持久化

​ 优点：与RDB持久化相对应，AOF的优点在于支持秒级持久化、兼容性好

​ 缺点：文件大、恢复速度慢、对性能影响大。

对于AOF持久化，向硬盘写数据的频率大大提高(everysec策略下为秒级)，IO压力更大，甚至可能造成AOF追加阻塞问题。

AOF文件的重写与RDB的bgsave类似，会有fork时的阻塞和子进程的IO压力问题。相对来说，由于AOF向硬盘中写数据的频率更高，因此对 Redis主进程性能的影响会更大。

六、Redis性能管理

----- 查看Redis内存使用 -----
redis-cli -h 192.168.226.123 -p 6379
192.168.226.123:6379> info memory

​ 内存碎片率

​ 是通过系统分配的内存值used_memory_rss除以Redis使用的内存值used_memory计算得出

​ 内存碎片是由操作系统低效的分配/回收物理内存导致的（不连续物理内存分配）

​ 跟踪内存碎片率对理解Redis实例的资源性能是非常重要的：

• 内存碎片率稍大于1为合理的，表示内存碎片率低
• 内存碎片率超过1.5说明Redis消耗了实际需要内存的150%，其中50%是内存碎片率。需要在redis-cli工具上输入shutdown save 命令，并重启 Redis 服务器。
• 内存碎片率低于1的，说明Redis内存分配超出了物理内存，操作系统正在进行内存交换。需要增加可用物理内存或减少 Redis 内存占用。（及内存不够，系统使用swap分区）

​ 内存使用率

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

​ 如何避免：

​ ●针对缓存数据大小选择安装 Redis 实例

​ ●尽可能的使用Hash数据结构存储

​ ●设置key的过期时间

​ 内存回收Key

​ 为了保证合理分配Redis有限的内存资源，当达到最大阈值时，需要选择一种key回收策略，淘汰一些数据。

​ 配置文件中修改 maxmemory-policy 属性值：

vim /etc/redis/6379.conf
 
598取消注释
maxmemory-policy noenviction

volatile-lru 使用LRU算法从已设置过期时间的数据集合中淘汰数据
volatile-ttl 从已设置过期时间的数据集合中挑选即将过期的数据淘汰
volatile-random 从已设置过期时间的数据集合中随机挑选数据淘汰
allkeys-lru 使用LRU算法从所有数据集合中淘汰数据
allkeys-random 从数据集合中任意选择数据淘汰
vim /etc/redis/6379.conf

598取消注释
maxmemory-policy noenviction

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