。

这些方式都旨在提高系统的稳定性和可用性#xff0c;特别是在面对服务器故障或其他问题时。

持久化#xff1a;

在数据库和缓存系统中#xff0c;持久化是指将数据保存在存储介质单机、主从复制、哨兵模式、和集群模式。

这些方式都旨在提高系统的稳定性和可用性特别是在面对服务器故障或其他问题时。

持久化

在数据库和缓存系统中持久化是指将数据保存在存储介质通常是硬盘上以确保在系统重启或关闭时数据不会丢失。

Redis作为一个内存数据库也提供了持久化的机制以防止数据在内存中丢失。

在Redis中主要有两种持久化方式

RDB持久化是将Redis在内存中的数据定期保存到硬盘上的一个快照文件。

这个快照是一个二进制文件包含了某个时间点上的所有数据。

可以根据配置的规则例如每隔一段时间保存一次或者当有一定数量的写操作发生时保存。

AOF持久化

File持久化是通过将写操作追加到一个文件中来记录数据库状态的变更。

这个文件是一个文本文件可以通过配置将其同步到硬盘。

由于是追加操作AOF持久化方式通常比RDB更耗时但可以提供更好的数据安全性因为它可以记录每一次写操作。

AOF持久化适用于需要快速恢复并且可以接受稍微增加存储和写操作开销的情况。

可以根据应用的需求选择使用RDB、AOF或者同时使用两者即混合持久化。

混合持久化可以兼具RDB的快速恢复和AOF的数据安全性。

在实际应用中选择适当的持久化方式需要权衡数据安全、性能、存储开销等因素。

主从复制模式

主从复制是通过在多台服务器上运行Redis实例其中一台为主服务器Master其余为从服务器Slave。

主服务器负责写操作而从服务器负责复制主服务器的数据提供读操作。

这样可以分担读写压力并提高系统的可用性。

一旦主服务器宕机可以手动或自动将其中一台从服务器切换为主服务器以确保服务的连续性。

哨兵模式

哨兵模式是主从复制的扩展通过引入哨兵Sentinel进程来监控主服务器的状态。

当主服务器宕机或不可达时哨兵会自动选举一个从服务器升级为主服务器以保障服务的可用性。

集群模式

Redis集群模式通过分片和多节点部署来实现高可用性和横向扩展。

数据被分为多个槽slots每个节点负责一部分槽的数据。

这样可以均衡负载提高并发处理能力。

集群模式通过节点间的协调和通信实现了数据的自动迁移和负载均衡增强了系统的可扩展性和容错性。

总体而言Redis的高可用性可以根据实际需求选择适当的部署方式。

单机模式适用于小规模应用而主从复制、哨兵模式和集群模式则适用于大规模、高并发的生产环境。

选择合适的方式需要综合考虑系统的规模、性能需求以及容错能力。

持久化

Backup持久化是Redis用于将内存中的数据定期保存到硬盘上的一种持久化方式。

它通过生成快照来保存数据并且是默认的持久化方式之一。

以下是RDB持久化的流程和原理

RDB持久化流程

RDB持久化可以通过配置文件中的定时触发例如每隔一段时间执行一次或者根据写操作的数量来触发。

生成快照

当触发条件满足时Redis会fork出一个子进程该子进程负责执行RDB持久化操作。

子进程会遍历整个数据集然后将数据集的内容写入一个临时的RDB文件中。

写入临时文件

生成快照时Redis使用一个临时文件来保存数据以确保在生成过程中不会影响到实际的持久化文件。

在确保临时文件完全生成后Redis会用该临时文件替换原来的持久化文件。

持久化文件替换

当生成的临时RDB文件写入完成后Redis会用该文件替换原先的RDB文件。

这个替换操作是一个原子性的操作它可以确保在替换期间不会丢失数据。

RDB持久化原理

RDB快照文件是一个二进制文件包含了Redis在某个特定时间点上的数据集状态。

fork子进程

Redis在进行RDB持久化时通过fork系统调用创建一个子进程。

子进程会复制父进程的内存数据并在内存中执行数据的序列化操作然后将数据写入临时文件。

阻塞风险

在生成快照期间Redis主进程可能会因为fork子进程而阻塞。

阻塞时间取决于数据集的大小和复制操作的速度。

在大型数据集的情况下这可能导致一定时间内的服务停顿。

当Redis重新启动时可以通过加载RDB文件将数据集重新载入到内存中恢复之前的数据状态。

RDB持久化适用于需要进行周期性备份的场景并且相对于AOF持久化它对系统的性能影响较小。

但是在生成快照时可能会导致阻塞因此需要谨慎配置触发条件以平衡数据的实时性和系统的性能。

RDB使用

文件生成完毕。

这样的方式可能在数据较大时影响服务器性能因此一般在生产环境中不推荐使用。

redis-cli

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

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

bgsave命令执行过程中只有fork子进程时会阻塞服务器而对于save命令整个过程都会阻塞服务器因此save已基本被废弃线上环境要杜绝save的使用。

自动触发

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

save

--219行--以下三个save条件满足任意一个时都会引起bgsave的调用

save

当时间到900秒时如果redis数据发生了至少1次变化则执行bgsave

save

当时间到300秒时如果redis数据发生了至少10次变化则执行bgsave

save

当时间到60秒时如果redis数据发生了至少10000次变化则执行bgsave

--254行--指定RDB文件名

在主从复制场景下如果从节点执行全量复制操作则主节点会执行bgsave命令并将rdb文件发送给从节点。

执行流程

Redis父进程首先判断当前是否在执行save或bgsave/bgrewriteaof的子进程如果在执行则bgsave命令直接返回。

bgsave/bgrewriteaof的子进程不能同时执行主要是基于性能方面的考虑两个并发的子进程同时执行大量的磁盘写操作可能引起严重的性能问题。

父进程执行fork操作创建子进程这个过程中父进程是阻塞的Redis不能执行来自客户端的任何命令

saving

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

启动时加载

RDB文件的载入工作是在服务器启动时自动执行的并没有专门的命令。

但是由于AOF的优先级更高因此当AOF开启时Redis会优先载入

AOF文件来恢复数据只有当AOF关闭时才会在Redis服务器启动时检测RDB文件并自动载入。

服务器载入RDB文件期间处于阻塞状态直到载入完成为止。

Redis载入RDB文件时会对RDB文件进行校验如果文件损坏则日志中会打印错误Redis启动失败。

AOF持久化

File持久化是Redis用于将写操作追加到一个文件中以记录数据库状态的变更的一种持久化方式。

以下是AOF持久化的流程和原理

AOF持久化流程

每当有写操作例如SET、DEL等发生时Redis会将这个写操作以协议的形式追加到AOF文件末尾。

根据配置Redis可以选择在每次写操作后进行文件同步fsync操作确保写入磁盘提高数据持久性。

文件同步的频率可以根据需求进行配置可以选择在每个写命令、每秒一次或者根据时间间隔执行。

为了避免AOF文件不断增长Redis支持AOF文件的重写。

这个操作会创建一个新的AOF文件其中包含了当前数据集的完整快照而不是所有历史写操作。

AOF文件重写可以通过BGREWRITEAOF命令手动触发也可以根据配置的自动触发条件来执行。

文件加载

当Redis重新启动时可以通过加载AOF文件将写操作重新执行从而还原数据库的状态。

AOF持久化原理

AOF文件是一个文本文件其中包含了Redis客户端向Redis服务器发送的原始通信协议的内容。

这使得AOF文件相对易于阅读和理解。

追加写入

AOF持久化的主要原理是将写操作追加到AOF文件末尾这是一个追加写入的操作而不是覆盖写入。

文件同步

文件同步操作fsync用于确保将写入磁盘提高数据的持久性。

文件同步的方式有三种无同步、每秒同步、每次写入同步可以根据需求进行配置。

AOF文件重写

AOF文件重写是通过遍历内存中的数据集来创建一个新的AOF文件其中只包含了当前数据集的快照。

这个过程可以减小AOF文件的体积提高AOF文件的读写效率同时保留了完整的数据历史。

AOF持久化适用于需要高可用性和数据安全性的场景因为它可以提供更精确的数据恢复点并且相对于RDB持久化可以实现更小的数据丢失。

AOF使用

Redis先将写命令追加到缓冲区而不是直接写入文件主要是为了避免每次有写命令都直接写入硬盘导致硬盘IO成为Redis负载的瓶颈。

命令追加的格式是Redis命令请求的协议格式它是一种纯文本格式具有兼容性好、可读性强、容易处理、操作简单避免二次开销等优点。

在AOF文件中除了用于指定数据库的select命令如select

0为选中0号数据库是由Redis添加的其他都是客户端发送来的写命令。

Redis提供了多种AOF缓存区的同步文件策略策略涉及到操作系统的write函数和fsync函数说明如下

为了提高文件写入效率在现代操作系统中当用户调用write函数将数据写入文件时操作系统通常会将数据暂存到一个内存缓冲区里当缓冲区被填满或超过了指定时限后才真正将缓冲区的数据写入到硬盘里。

这样的操作虽然提高了效率但也带来了安全问题如果计算机停机内存缓冲区中的数据会丢失因此系统同时提供了fsync、fdatasync等同步函数可以强制操作系统立刻将缓冲区中的数据写入到硬盘里从而确保数据的安全性。

vim

命令写入aof_buf后立即调用系统fsync操作同步到AOF文件fsync完成后线程返回。

这种情况下每次有写命令都要同步到AOF文件硬盘IO成为性能瓶颈Redis只能支持大约几百TPS写入严重降低了Redis的性能即便是使用固态硬盘SSD每秒大约也只能处理几万个命令而且会大大降低SSD的寿命。

appendfsync

命令写入aof_buf后调用系统write操作不对AOF文件做fsync同步同步由操作系统负责通常同步周期为30秒。

这种情况下文件同步的时间不可控且缓冲区中堆积的数据会很多数据安全性无法保证。

appendfsync

everysec

命令写入aof_buf后调用系统write操作write完成后线程返回fsync同步文件操作由专门的线程每秒调用一次。

everysec是前述两种策略的折中是性能和数据安全性的平衡因此是Redis的默认配置也是我们推荐的配置。

文件重写

AOF

文件在运行一段时间后可能会变得很大影响性能。

为了解决这个问题Redis

AOF

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

64mb

#当前AOF文件执行BGREWRITEAOF命令的最小值避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF上述配置表示当

AOF

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

●自动触发通过设置auto-aof-rewrite-min-size选项和auto-aof-rewrite-percentage选项来自动执行BGREWRITEAOF。

只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个选项同时满足时才会自动触发AOF重写即bgrewriteaof操作。

AOF

会执行一个数据快照snapshot将当前数据库的状态保存到内存中。

这个快照包含了当前时刻的所有键值对。

重放写命令

1Redis父进程首先判断当前是否存在正在执行bgsave/bgrewriteaof的子进程如果存在则bgrewriteaof命令直接返回如果存在

3.1父进程fork后bgrewriteaof命令返回”Background

append

并可以响应其他命令。

Redis的所有写命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘保证原有AOF机制的正确。

3.2由于fork操作使用写时复制技术子进程只能共享fork操作时的内存数据。

由于父进程依然在响应命令因此Redis使用AOF重写缓冲区(aof_rewrite_buf)保存这部分数据防止新AOF文件生成期间丢失这部分数据。

也就是说bgrewriteaof执行期间Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区。

5.1子进程写完新的AOF文件后向父进程发信号父进程更新统计信息具体可以通过info

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

当AOF开启时Redis启动时会优先载入AOF文件来恢复数据只有当AOF关闭时才会载入RDB文件恢复数据。

当AOF开启但AOF文件不存在时即使RDB文件存在也不会加载。

Redis载入AOF文件时会对AOF文件进行校验如果文件损坏则日志中会打印错误Redis启动失败。

但如果是AOF文件结尾不完整(机器突然宕机等容易导致文件尾部不完整)且aof-load-truncated参数开启则日志中会输出警告Redis忽略掉AOF文件的尾部启动成功。

aof-load-truncated参数默认是开启的。

手动执行

持久化是通过在指定时间间隔内生成数据库的快照因此对于备份和恢复操作来说性能较好。

加载快照通常比重新执行

AOF

是周期性生成快照如果在生成快照的时间点发生故障可能会导致最后一次快照后的数据丢失。

不适用于实时持久化

持久化就是把内存的数据写到磁盘中去防止服务宕机了内存数据丢失。

有两种持久化方式RDB默认和AOF持久化

RDBRedis

Redis默认的持久化方式。

按照一定的时间将内存的数据以快照的形式保存到硬盘中对应产生的数据文件为dump.rdb。

通过配置文件中的save参数来定义快照的周期。

AOF(append

:是将Redis执行的每次写命令记录到单独的日志文件中当重启Redis会重新将持久化的日志中文件恢复数据。

两种方式都可以把Redis内存中的数据持久化到磁盘上然后再将这些数据备份到别的地方去RDB更适合做冷备AOF更适合做热备

综合比对

如能承受数分钟以内的数据丢失且追求大数据集的恢复速度选用RDB

灾难恢复选用RDB

持久化记录了每个写操作的详细命令因此在故障发生时可以通过重新执行

AOF

文件是文本格式易于查看、分析和手动修改。

这在需要修复损坏的数据时可能会更方便。

文件较大

文件大因为它包含了每个写操作的详细记录。

这可能导致磁盘占用较多空间。

性能相对较低

内存碎片率是衡量系统内存利用效率的一个指标通常表示系统中的空闲内存与总内存之比。

具体来说内存碎片率可以分为两类

外部碎片率External

外部碎片率是指分散在内存中的不连续的小块空闲内存的比例。

这些小块空闲内存虽然总和可以很大但由于它们分布在各个位置可能无法被有效地利用。

外部碎片率的增加可能导致系统难以找到足够的连续内存块来满足某些大内存需求的程序从而影响系统性能。

内部碎片率Internal

内部碎片率是指已经分配给进程但没有被利用的内存的比例。

当内存分配算法为了满足某个进程的内存需求而分配了一块稍大于进程请求的内存块时就会产生内部碎片。

这部分内存虽然已经分配但却没有被充分利用因此被认为是碎片。

used_memory_rss

实例的内存大小。

除了用户定义的数据和内部开销以外used_memory_rss

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

举例来说Redis

需要分配连续内存块来存储

数据该操作就会导致内存碎片的产生。

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

Redis

●内存碎片率超过1.5说明Redis消耗了实际需要物理内存的150%其中50%是内存碎片率。

需要在redis-cli工具上输入shutdown

save

●内存碎片率低于1的说明Redis内存分配超出了物理内存操作系统正在进行内存交换。

需要增加可用物理内存或减少

Redis

内存使用率是指系统当前正在使用的物理内存占总可用内存的比例。

这是一个重要的性能指标用于衡量系统内存资源的利用情况。

在Linux系统中可以使用一些命令来查看内存使用率其中最常用的是

free

命令。

该命令会显示关于内存总量、已使用的内存、空闲内存等相关信息。

free

-m这将以兆字节MB为单位显示内存信息。

也可以使用其他工具或监控软件来实时监测系统内存使用情况以便及时调整系统配置或优化程序性能。

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

#避免内存交换发生的方法

●针对缓存数据大小选择安装

立即过期对于每个设置了过期时间的key会创建一个定时器到过期时间就会立即清除。

这样可以立即清除过期的数据对内存很友好但会占用大量CPU资源影响缓存的响应时间和吞吐量。

惰性过期只有在访问一个key时才判断该key是否已过期过期则清除。

这可以最大程度地节省CPU资源但对内存非常不友好可能导致大量过期key没有再次被访问而占用大量内存。

定期过期每隔一定时间会扫描一定数量的数据库的expires字典中的一定数量的key并清除已过期的key。

这是前两者的折中方案通过调整定时扫描的时间间隔和每次扫描的限定耗时可以在不同情况下使CPU和内存资源达到最优的平衡效果。

noeviction默认策略对于写请求不再提供服务直接返回错误除了DEL请求和部分特殊请求。

volatile-lru仅从设置了过期时间的key中使用LRU算法进行淘汰。

内存清理策略保证合理分配redis有限的内存资源。

当达到设置的最大阀值时需选择一种key的回收策略默认情况下回收策略是禁止删除。

配置文件中修改

●volatile-lru使用LRU算法从已设置过期时间的数据集合中淘汰数据(移除最近最少使用的key针对设置了TTL的key)

●volatile-ttl从已设置过期时间的数据集合中挑选即将过期的数据淘汰移除最近过期的key

●volatile-random从已设置过期时间的数据集合中随机挑选数据淘汰在设置了TTL的key里随机移除

●allkeys-lru使用LRU算法从所有数据集合中淘汰数据移除最少使用的key针对所有的key

●allkeys-random从数据集合中任意选择数据淘汰随机移除key