网络公司手机网站,国内可以做的国外兼职网站,济南市最新消息,简述网站一般建设的流程文章目录Redis 持久化1 持久化基本原理2 RDB(Redis DataBase) 持久化2.1 持久化的执行2.2 手动 save 命令2.3 手动 bgsave 命令2.4 自动条件触发2.5 查看持久化时间3 RDB 优化配置3.1 save3.2 stop-write-on-bgsave-error3.3 rdbcompression3.4 rdbchecksum3.5 sanitize-dump-p…
文章目录Redis 持久化1 持久化基本原理2 RDB(Redis DataBase) 持久化2.1 持久化的执行2.2 手动 save 命令2.3 手动 bgsave 命令2.4 自动条件触发2.5 查看持久化时间3 RDB 优化配置3.1 save3.2 stop-write-on-bgsave-error3.3 rdbcompression3.4 rdbchecksum3.5 sanitize-dump-payload3.6 dbfilename3.7 rdb-del-sync-files3.8 dir4 RDB 文件结构5 RDB 持久化过程6 补充写实复制技术Redis 持久化
Redis 是一个内存数据库所以其运行效率非常高。但是存在一个问题内存中的数据是不持久的若主机宕机或 Redis 关机重启则内存中的数据全部丢失。Redis 具有持久化功能其会按照设置以快照或操作日志的形式将数据持久化到磁盘。根据持久化使用技术的不同Redis 的持久化分为两种RDB 与 AOF
1 持久化基本原理
Redis 持久化称为钝化是指将内存中数据库的状态描述信息保存到磁盘中。不同的持久化技术对数据的状态描述信息是不同的生成的持久化文件也是不同的。但作用都是相同的避免数据意外丢失。数据恢复过程也称为激活。通过手动方式或自动定时方式或自动条件触发方式将内存中数据库的状态描述信息写入到指定的持久化文件中。当系统重新启动时自动加载持久化文件并根据文件中数据库状态描述信息将数据恢复到内存中。钝化与激活的过程就是 Redis 持久化的基本原理。对于 Redis 单机状态下无论是手动方式还是定时方式或条件触发方式都存在数据丢失问题在尚未手动/自动保存时发生了 Redis 宕机状况那么从上次保存到宕机期间产生的数据就会丢失。不同的持久化方式其数据的丢失率也是不同 RDB 是默认持久化方式但 Redis 允许 RDB 与 AOF 两种持久化技术同时开启此时系统会使用 AOF 方式做持久化即 AOF 持久化技术的优先级要更高。同样两种技术同时开启状态下系统启动时若两种持久化文件同时存在则优先加载 AOF持久化文件。
2 RDB(Redis DataBase) 持久化
RDB是指将内存中某一时刻的数据快照全量写入到指定的 rdb 文件的持久化技术。RDB 持久化默认是开启的,当 Redis 启动时会自动读取 RDB 快照文件将数据从硬盘载入到内存以恢复 Redis 关机前的数据库状态
2.1 持久化的执行
RDB 持久化的执行有三种方式手动 save 命令、手动 bgsave 命令与自动条件触发
2.2 手动 save 命令
通过在 redis-cli 客户端中执行 save 命令可立即进行一次持久化保存。**save 命令在执行期间会阻塞 redis-server 进程直至持久化过程完毕。**而在 redis-server 进程阻塞期间Redis不能处理任何读写请求无法对外提供服务。
2.3 手动 bgsave 命令
background save后台运行 save。bgsave 命令会使服务器进程 redis-server 生成一个子进程由该子进程负责完成保存过程。在子进程进行保存过程中不会阻塞 redis-server 进程对客户端读写请求的处理通过在 redis-cli 客户端中执行 bgsave 命令可立即进行一次持久化保存。
2.4 自动条件触发
自动条件触发的本质仍是 bgsave 命令的执行。用户通过在配置文件中做相应的设置后Redis 会根据设置信息自动调用 bgsave 命令执行。
2.5 查看持久化时间
通过 lastsave 命令可以查看最近一次执行持久化的时间其返回的是一个 Unix 时间戳
3 RDB 优化配置
RDB 相关的配置在 redis.conf 文件的 SNAPSHOTTING 部分
3.1 save # Save the DB to disk.
#保存DB到磁盘
# save seconds changes [seconds changes ...]
#
# Redis will save the DB if the given number of seconds elapsed and it
# surpassed the given number of write operations against the DB.
#如果给定的秒数过去了超过了给定的对DB的写操作数,Redis将保存数据库
#
# Snapshotting can be completely disabled with a single empty string argument
#snapshot可以用一个空字符串参数完全禁用
# as in following example:
# save
#
# Unless specified otherwise, by default Redis will save the DB:
# * After 3600 seconds (an hour) if at least 1 change was performed
# * After 300 seconds (5 minutes) if at least 100 changes were performed
# * After 60 seconds if at least 10000 changes were performed
#
# You can set these explicitly by uncommenting the following line.
#
# save 3600 1 300 100 60 100
#除非另有说明默认情况下Redis会保存DB:
# * 3600秒后(一个小时)如果至少执行了一次更改
# * 在300秒(5分钟)后如果执行了至少100次更改
# * 如果执行了至少10000次更改则在60秒后
#你可以通过取消注释下面的行显式设置。
# save 3600 1 300 100 60 100该配置用于设置快照的自动保存触发条件(save point)。该触发条件是在指定时间段内发生了指定次数的写操作。除非另有规定默认情况下持久化条件为 save 3600 1 300 100 60 10000# save 3600 1 300 100 60 10000
save 3600 1 # 在 3600 秒(1 小时)内发生 1 次写操作
save 300 100 # 在 300 秒(5 分钟)内发生 100 次写操作
save 60 10000 # 在 60 秒(1 分钟)内发生 1 万次写操作如果不启用 RDB 持久化只需设置 save 的参数为空串即可save
3.2 stop-write-on-bgsave-error # By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#默认情况下如果启用RDB快照Redis将停止接受写操作(至少一个保存点)和最新的后台保存失败。
#这将使用户意识到(以一种艰难的方式)数据没有持久化在磁盘上否则很可能没有人会注意到灾难将会发生。
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#如果后台保存进程将重新开始工作Redis将自动允许再次写入。
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
#但是如果您已经设置了适当的Redis服务器监控和持久性你可能想要禁用这个功能以便Redis将继续正常工作即使磁盘有问题permissions等。默认情况下如果 RDB 快照已启用至少一个保存点且最近的 bgsave 命令失败Redis将停止接受写入。这样设置是为了让用户意识到数据没有正确地保存到磁盘上否则很可能没有人会注意到并会发生一些灾难。当然如果 bgsave 命令后来可以正常工作了Redis将自动允许再次写入
3.3 rdbcompression 当进行持久化时启用 LZF 压缩字符串对象。虽然压缩 RDB 文件会消耗系统资源降低性能但可大幅降低文件的大小方便保存到磁盘加速主从集群中从节点的数据同步。
3.4 rdbchecksum 从 RDB5 开始RDB 文件的 CRC64 校验和就被放置在了文件末尾。这使格式更能抵抗 RDB文件的损坏但在保存和加载 RDB 文件时性能会受到影响约 10%因此可以设置为 no禁用校验和以获得最大性能。在禁用校验和的情况下创建的 RDB 文件的校验和为零这将告诉加载代码跳过校验检查。默认为 yes开启了校验功能。
3.5 sanitize-dump-payload 该配置用于设置在加载 RDB 文件或进行持久化时是否开启对 zipList、listPack 等数据的全面安全检测。该检测可以降低命令处理时发生系统崩溃的可能。其可设置的值有三种选择 no不检测yes总是检测clients只有当客户端连接时检测。排除了加载 RDB 文件与进行持久化时的检测。 默认值本应该是 clients但其会影响 Redis 集群的工作所以默认值为 no不检测
3.6 dbfilename 指定 RDB 文件的默认名称默认为 dump.rdb
3.7 rdb-del-sync-files 主从复制时是否删除用于同步的从机上的 RDB 文件。默认是 no不删除。注意只有当从机的 RDB 和 AOF 持久化功能都未开启时才生效。
3.8 dir 指定 RDB 与 AOF 文件的生成目录。默认为 Redis 安装根目录
4 RDB 文件结构
RDB 持久化文件 dump.rdb 整体上有五部分构成 SOF常量一个字符串 REDIS仅包含这五个字符其长度为 5。用于标识 RDB文件的开始以便在加载 RDB 文件时可以迅速判断出文件是否是 RDB 文件。 rdb_version整数长度为 4 字节表示 RDB 文件的版本号。 EOF常量占 1 个字节用于标识 RDB 数据的结束校验和的开始。 check_sum校验和 check_sum 用于判断 RDB 文件中的内容是否出现数据异常。其采用的是 CRC 校验算法。 CRC 校验算法 在持久化时先将 SOF、rdb_version 及内存数据库中的数据快照这三者的二进制数据拼接起来形成一个二进制数假设称为数 a然后再使用这个 a 除以校验和 check_sum此时可获取到一个余数 b然后再将这个 b 拼接到 a 的后面形成 databases。 在加载时需要先使用 check_sum 对 RDB 文件进行数据损坏验证。验证过程只需将RDB 文件中除 EOF 与 check_sum 外的数据除以 check_sum。只要除得的余数不是 0就说明文件发生损坏。当然如果余数是 0也不能肯定文件没有损坏。这种验证算法是数据损坏校验而不是数据没有损坏的校验。 databases:可以包含任意多个非空数据库。而每个 database 又是由三部分构成 SODB是一个常量占 1 个字节用于标识一个数据库的开始。 db_number数据库编号。 key_value_pairs当前数据库中的键值对数据。 每个 key_value_pairs 又由很多个用于描述键值对的数据构成。 VALUE_TYPE是一个常量占 1 个字节用于标识该键值对中 value 的类型。EXPIRETIME_UNIT是一个常量占 1 个字节用于标识过期时间的单位是秒还是毫秒。time当前 key-value 的过期时间。
5 RDB 持久化过程 对于 Redis 默认的 RDB 持久化在进行 bgsave 持久化时redis-server 进程会 fork 出一个 bgsave 子进程由该子进程以异步方式负责完成持久化。而在持久化过程中redis-server进程不会阻塞其会继续接收并处理用户的读写请求。 bgsave 子进程的详细工作原理如下 由于子进程可以继承父进程的所有资源且父进程不能拒绝子进程的继承权。所以bgsave 子进程有权读取到 redis-server 进程写入到内存中的用户数据使得将内存数据持久化到 dump.rdb 成为可能。bgsave 子进程在持久化时首先会将内存中的全量数据 copy 到磁盘中的一个 RDB 临时文件copy 结束后再将该文件 rename 为 dump.rdb替换掉原来的同名文件。 在进行持久化过程中如果 redis-server 进程接收到了用户写请求则系统会将内存中发生数据修改的物理块 copy 出一个副本。等内存中的全量数据 copy 结束后会再将副本中的数据 copy 到 RDB 临时文件。这个副本的生成是由于 Linux 系统的**写时复制技术Copy-On-Write**实现的。
6 补充写实复制技术
写时复制技术是 Linux 系统的一种进程管理技术。原本在 Unix 系统中当一个主进程通过 fork()系统调用创建子进程后内核进程会复制主进程的整个内存空间中的数据然后分配给子进程。这种方式存在以下问题 这个过程非常耗时这个过程降低了系统性能如果主进程修改了其内存数据子进程副本中的数据是没有修改的。即出现了数据冗余而冗余数据最大的问题是数据一致性无法保证。 现代的 Linux 则采用了更为有效的方式写时复制。子进程会继承父进程的所有资源其中就包括主进程的内存空间。即子进程与父进程共享内存。只要内存被共享那么该内存就是只读的写保护的。而写时复制则是在任何一方需要写入数据到共享内存时都会出现异常此时内核进程就会将需要写入的数据 copy 出一个副本写入到另外一块非共享内存区域。
