怎样进行公司网站建设,网站建设公司兴田德润在那里,网站开发这个专业前景怎样,国外 创意 网站Redis支持两种方式的持久化#xff0c;一种是RDB方式、另一种是AOF#xff08;append-only-file#xff09;方式#xff0c;两种持久化方式可以单独使用其中一种#xff0c;也可以将这两种方式结合使用。
•RDB#xff1a;根据指定的规则“定时”将内存中的数据存储在硬…Redis支持两种方式的持久化一种是RDB方式、另一种是AOFappend-only-file方式两种持久化方式可以单独使用其中一种也可以将这两种方式结合使用。
•RDB根据指定的规则“定时”将内存中的数据存储在硬盘上生成的快照
•AOF每次执行命令后将命令本身记录下来每次执行命令都会将命令写入到aof文件中
RDB模式
RDB的持久化方式是通过快照snapshotting完成的它是Redis默认的持久化方式
Redis允许用户自定义快照条件当符合快照条件时Redis会自动执行快照操作。快照的条件可以由用户在配置文件中配置。配置格式如下
save
例如
# save 3600 1
# save 300 100
# save 60 10000
第一个参数是时间窗口第二个是键的个数也就是说在第一个时间参数配置的时间范围内被更改的键的个数大于后面配置的changes时即符合快照条件。当触发条件时Redis会自动将内存中的数据生成一份副本rbd文件并存储在磁盘上进行一个数据持久化这个过程称为快照
除了上述规则之外符合我们条件redis自动生成快照还有以下几种方式生成快照。
1.用户执行SAVE或者GBSAVE命令
2.执行FLUSHALL命令
3.执行复制(replication)时
save 5 1 表示5秒内有一个key发生变化就会生成rdb文件。
save和bgsave命令
除了让Redis自动进行快照以外当我们对服务进行重启或者服务器迁移我们需要人工去干预备份。redis提供了两条命令来完成这个任务
1save命令当执行save命令时Redis同步做快照操作在快照执行过程中会阻塞所有来自客户端的请求。当redis内存中的数据较多时通过该命令将导致Redis较长时间的不响应。所以不建议在生产环境上使用这个命令而是推荐使用bgsave命令 2,bgsave命令
bgsave命令bgsave命令可以在后台异步地进行快照操作快照的同时服务器还可以继续响应来自客户端的请求。执行BGSAVE后Redis会立即返回ok表示开始执行快照操作
1redis使用fork函数开启一个子进程
2父进程继续接收并处理客户端发来的命令而子进程开始将内存中的数据写入硬盘中的临时rdb文件
3当子进程写入完所有数据后会用该临时rdb文件替换旧的RDB文件至此一次快照操作完成。
bgsave是异步执行快照的在调用fork函数创建子进程时只对这个时间之前的数据集进行备份(fork函数创建的子进程是复制该时间点的父进程的该时间点之后的数据是没有复制的)该时间点之后客户端对redis服务端发送的命令对数据的修改是没有持久化的没有保存到快照中 一、优势
1.RDB是一个非常紧凑(compact)的文件它保存了redis 在某个时间点上的数据集这种文件非常适合用于进行备份和灾难恢复。
2.生成RDB文件的时候redis主进程会fork()一个子进程来处理所有保存工作主进程不需要进行任何磁盘IO操作。
3.RDB 在恢复大数据集时的速度比AOF的恢复速度要快。
二、劣势
•1、RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程频繁执行成本过高
•2、在一定间隔时间做一次备份所以如果redis意外down掉的话最后一次快照之后的修改数据会被丢失数据有丢失。
如果数据相对来说比较重要希望将损失降到最小则可以使用AOF方式进行持久化。
AOF持久化方式
AOF(Append Only File)Redis 默认不开启。AOF采用日志的形式来记录每个写操作并追加到文件中。开启后执行更改Redis数据的命令时就会把命令写入到AOF文件中。
Redis 重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。
配置
# 开关 appendonly no /yes # 文件名 appendfilename “appendonly.aof”
AOF相关问题
问题1数据都是实时持久化到磁盘吗
虽然每次执行更改Redis数据库内容的操作时AOF都会将命令记录在AOF文件中但是事实上由于操作系统的缓存机制数据并没有真正地写入硬盘而是进入了aof_buf缓存中。在默认情况下系统每30秒会执行一次同步操作。以便将aof_buf缓存中的内容真正地写入磁盘中。
在这30秒的过程中如果系统异常退出则会导致aof_buf缓存中的数据丢失。这个时候就需要Redis在写入AOF文件后主动要求系统将aof_buf缓存内容同步到磁盘中。在redis.conf中通过如下配置来设置同步机制。
fork()出一个子进程通过子进程将aof_buf缓存中的数据同步到磁盘中 参数
说明
appendfsync everysec
AOF持久化策略硬盘缓存到磁盘默认
everysec
1 no 表示不执行fsync由操作系统保证数据同步到磁盘速度最快但是不太安全
2 always 表示每次写入都执行fsync以保证数据同步到磁盘效率很低
3 everysec表示每秒执行一次fsync可能会导致丢失这1s数据。通常选择 everysec 兼顾安全性和效率。
问题2文件越来越大怎么办
AOF持久化是Redis不断将写命令记录到 AOF 文件中随着Redis不断的运行AOF 的文件会越来越大文件越大
为了解决这个问题Redis新增了重写机制
当AOF文件的大小超过所设定的阈值时Redis就会启动AOF文件的内容压缩只保留可以恢复数据的最小指令集。
AOF 文件重写并不是对原文件进行重新整理而是直接读取服务器现有的键值对然后用一条命令去代替之前记录这个键值对的多条命令生成一个新的文件后去替换原来的 AOF 文件。
在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中载入的速度相对于RDB会慢一些
AOF重写机制触发时机 问题3重写过程中AOF文件被更改了怎么办
Redis 可以在 AOF 文件体积变得过大时自动地在后台对 AOF 进行重写重写后的新 AOF 文件包含了重写这一时刻之前数据集所需的最小命令集合。
重写的流程是这样
• 主进程会fork一个子进程出来进行AOF重写并不是对原文件进行重新整理而是直接读取redis服务内存中现有的键值对然后用一条命令去代替每个键值对写入到新的AOF文件中
• 在fork子进程这个过程中服务端仍然可以对外提供服务在子进程重写的这个时间段里面主进程的数据更新操作会缓存到aof_rewrite_buf中也就是单独开辟一块缓存来存储重写期间收到的命令当子进程重写完以后再把缓存中的数据追加到新的aof文件。
• 当所有的数据全部追加到新的aof文件中后会把旧的aof文件替换成新的aof文件此后所有的操作都会被写入新的aof文件。
•如果在rewrite过程中出现故障不会影响原来aof文件的正常工作只有当rewrite完成后才会切换文件。因此这个rewrite过程是比较可靠的。 在aof_buf缓存到旧的aof文件中间其实还有一个子进程将aof_buf缓存中的数据同步到aof文件中取
(3)重写子进程会将redis服务中的所有数据键值通过一条指令替代 Redis允许同时开启AOF和RDB既保证了数据安全又使得进行备份等操作十分容易。如果同时开启后Redis重启会使用AOF文件来恢复数据因为AOF方式的持久化可能丢失的数据更少。
优点
1、AOF 持久化的方法使用默认的每秒同步一次Redis 最多也就丢失 1 秒的数据而已。
缺点
1、对于具有相同数据的的RedisAOF 文件通常会比 RDB 文件体积更大RDB存的是数据快照。
2、虽默认情况下每秒同步一次的频率也具有较高的性能。在高并发的情况下RDB 比 AOF 具有更好的性能保证。
