网站风格抄袭,做交易平台的网站需要哪些技术,如何制作可以下单的网站,做一款app的流程目录
RDB#xff08;Redis DataBase Backup file#xff09;
RDB执行原理
AOF#xff08;Append-Only File#xff09;
RDB和AOF对比 Redis支持多种持久化方式#xff0c;以确保数据在内存中持久存储#xff0c;以便在Redis服务器重启时数据不会丢失。Redis中持久化的…目录
RDBRedis DataBase Backup file
RDB执行原理
AOFAppend-Only File
RDB和AOF对比 Redis支持多种持久化方式以确保数据在内存中持久存储以便在Redis服务器重启时数据不会丢失。Redis中持久化的两种主要实现方式RDB和AOF。
RDBRedis DataBase Backup file
RDB是Redis的快照持久化方式它会在指定的时间间隔内生成数据快照并将其保存到磁盘上的一个文件中。RDB文件包含了数据库的数据和键的过期时间信息。RDB持久化是一个点对点的持久化方式它适用于数据快照的定期备份以及在Redis服务重启时快速恢复数据。
RDB持久化可以通过配置文件设置允许管理员指定快照的保存频率和文件名。RDB文件通常以二进制格式存储可以通过SAVE或BGSAVE命令手动触发持久化。
[root10 ~]# redis-cli -h 127.0.0.1 -p 6379 -a password #用密码方式连接
Warning: Using a password with -a or -u option on the command line interface may not be safe.
127.0.0.1:6379 save #由Redis主进程执行RDB会阻塞所有命令
OK
127.0.0.1:6379 bgsave #开启子进程执行RDB避免主线程受影响
Background saving started
127.0.0.1:6379
Redis内部有触发RDB的机制在redis.conf文件中
# Save the DB to disk.
#
# save seconds changes
#
# Redis will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# Snapshotting can be completely disabled with a single empty string argument
# as in following example:
#
# save
#
# Unless specified otherwise, by default Redis will save the DB:
# * After 3600 seconds (an hour) if at least 1 key changed
# * After 300 seconds (5 minutes) if at least 100 keys changed
# * After 60 seconds if at least 10000 keys changed
#
# You can set these explicitly by uncommenting the three following lines.
#
# save 3600 1
# save 300 100
# save 60 10000
说明一下
# save 这是禁用RDB
save 3600 1 # 表示每小时有至少1个key发生变化就执行bgsave
save 300 100 # 表示每5分钟有至少100个key发生变化就执行bgsave
save 60 10000 # 表示每1分钟有至少10000个key发生变化就执行bgsave
RDB执行原理 Redis使用fork函数复制一份当前进程(父进程)的副本(子进程)。 父进程接收处理客户端命令子进程将内存中的数据写入硬盘中的临时文件。 当子进程写入完所有数据后使用临时文件替换旧的RDB文件至此一次快照操作完成。 需要注意的是 页表记录虚拟地址与物理地址的映射关系操作系统用户空间程序只能访问虚拟内存而不是直接操作物理内存。 Fork采用的是一种copy-on-write的策略目的是防止数组脏写 父进程读数据时共享读取 父进程写数据是拷贝副本单独写操作 在最近一次RDB和下一次RDB间隔期间出现Redis服务宕机是会丢失这批数据的。
Redis启动后会读取RDB文件文件是压缩过的二进制格式。占用空间小利于传输和恢复。读取的时间根据服务器性能、数据结构、数据量大小会有不同差异。通常一个记录1000万个字符串类型键、大小为1GB的快照文件载入内存需要花费20-30秒。
RDB实现持久化一旦出现异常退出恢复的时候只能恢复到最近一次RDB的节点数据。如果数据比较重要希望将损失降到最小那么可以使用AOF进行持久化。
AOFAppend-Only File
AOF是Redis的追加日志持久化方式它将每个写操作包括SET、INCR等追加到一个日志文件中以记录数据库操作的历史。AOF文件包含了一系列命令它们可以用于重建数据库状态。 AOF持久化可以通过配置文件设置可以选择以同步fsync或异步no fsync方式将操作追加到AOF文件中。同步方式可以保证数据的完整性但通常会降低性能。异步方式则更快但在发生故障时可能会导致数据丢失。
AOF默认是关闭的在redis.conf文件进行设置
# 是否开启AOF默认是no
appendonly yes
# AOF文件的名称
appendfilename appendonly.aof
AOF的命令记录的频率(也叫刷盘策略)是可以通过redis.conf配置的
# appendfsync always 表示每执行一次写命令立即记录到AOF文件
appendfsync everysec # 推荐的也是默认的每秒刷盘策略
# appendfsync no 表示写命令执行完先放到AOF缓冲区由操作系统决定何时将缓冲区内容写入磁盘
配置项刷盘时机优点缺点Always同步刷盘可靠性高几乎不丢数据性能影响大everysec每秒刷盘性能适中最多丢失1秒数据no操作系统控制性能最好可靠性较差可能丢失大量数据
由于AOF记录的是写命令文件比RDB大的多。而且AOF会记录对同一个key的多次操作但只有最后一次写操作才有意义。我们可以通过bgrewriteaof命令可以让AOF文件执行重写功能用最少的命令达到相同的结果。 AOF也会在触发阈值时自动重写AOF文件。阈值可以在redis.cof配置
# AOF文件比上次增长超过多少百分比触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积达到多少触发重写
auto-aof-rewrite-min-size 64mb
RDB和AOF对比
** **RDBAOF持久化方式定时对整个内存做快照记录每一次执行的命令数据完整性不完整两次备份之间会丢失相对完整取决于刷盘策略文件大小会有压缩文件体积小记录命令文件体积很大宕机恢复速度很快慢数据恢复优先级低因为数据完整性不如AOF高因为数据完整性更高系统资源占用高大量CPU和内存消耗低主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源使用场景可以容忍数分钟的数据丢失追求更快的启动速度对数据安全性要求较高常见
两者各有优缺点而实际的项目中往往是结合一起使用的以提供更可靠的数据保护。在Redis重启时会优先使用AOF日志文件来恢复数据因为AOF记录了更详细的操作历史。如果AOF文件不存在或损坏Redis可以使用RDB文件来进行数据恢复。
