xml地图|网站地图|网站标签 [设为首页] [加入收藏]
来自 每日资讯 2019-10-02 01:18 的文章
当前位置: 新濠国际登录平台 > 每日资讯 > 正文

新进程的所有数据(变量,②定量生成快照

3 Redis主动同步设置方法 Redis主从同步

redis持久化缓存相关理解,redis缓存

rdb - Redis DataBase

Redis基本原理

1.Redis主从同步特点

redis 持久化缓存:

一:SNAPSHOTTING(快照方式 -》二进制文件)

①定时生成快照

②定量生成快照

观察redis的配置文件中的SNAPSHOTTING设置模块的设置信息,我们可以发现

新濠国际登录平台 1

上图已经对save命令的意思做出了解释,现在我再来说一下,意思就是:

save? 900? 1????? 每900秒(15分钟)至少一次键值变更时被触发;

新濠国际登录平台 2?

 

##当snapshot时出现错误无法继续时,是否阻塞客户端“变更操作”,“错误”可能因为磁盘已满/磁盘故障/OS级别异常等  
stop-writes-on-bgsave-error yes  

新濠国际登录平台 3

rdbcompression?

RDB文件过大时,是可以压缩的,Redis默认开启压缩,当然也可以通过配置rdbcompression参数来禁用压缩。

 

压缩和不压缩的优缺点:

压缩:

优点:减少磁盘存储空间
缺点:消耗CPU资源

不压缩:

优点:不消耗CPU资源
缺点:占用磁盘空间多

 

如何选择? 那就需要看需求、看服务器资源情况了。

 

RDB的快照过程:

 

1.redis 调用 fork,现在有了子进程和父进程。

  1. 父进程继续处理 client 请求,子进程负责将内存内容写入到临时文件。由于 os 的实时复制机制( copy on write)父子进程会共享相同的物理页面,当父进程处理写请求时 os 会为父进程要修改的页面创建副本,而不是写共享的页面。所以子进程地址空间内的数据是 fork时刻整个数据库的一个快照。

3.当子进程将快照写入临时文件完毕后,用临时文件替换原来的快照文件,然后子进程退出。client 也可以使用 save 或者 bgsave 命令通知 redis 做一次快照持久化。 save 操作是在主线程中保存快照的,由于 redis 是用一个主线程来处理所有 client 的请求,这种方式会阻塞所有client 请求。所以不推荐使用。另一点需要注意的是,每次快照持久化都是将内存数据完整写入到磁盘一次,并不是增量的只同步变更数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘 io 操作,可能会严重影响性能。

 

 

手动快照:

 

如果没有触发自动快照,可以对redis进行手动快照操作,SAVE和BGSAVE都可以执行手动快照,两个命令的区别是前者是由主进程进行快照操作,会阻塞其他请求;而后者是通过fork子进程进行快照操作。

新濠国际登录平台 4

 

注意:

由于redis使用fork来复制一份当前进程,那么子进程就会占有和主进程一样的内存资源,比如说主进程8G内存,那么在备份的时候必须保证有16G内存,要不然会启用虚拟内存,性能非常差。

二:APPEND ONLY MODE(aof类似于预写日志)

①后台执行

②边服务边备份

 

Redis AOF是类似于log的机制,每次写操作都会写到硬盘上,当系统崩溃时,可以通过AOF来恢复数据。每个带有写操作的命令被Redis服务器端收到运行时,该命令都会被记录到AOF文件上。由于只是一个append到文件操作,所以写到硬盘上的操作往往非常快。

其实Redis oaf机制包括了两件事,rewrite和AOF。rewrite类似于普通数据库管理系统日志恢复点,当AOF文件随着写命令的运行膨胀时,当文件大小触碰到临界时,rewrite会被运行。
rewrite会像replication一样,fork出一个子进程,创建一个临时文件,遍历数据库,将每个key、value对输出到临时文件。输出格式就是Redis的命令,但是为了减小文件大小,会将多个key、value对集合起来用一条命令表达。在rewrite期间的写操作会保存在内存的rewrite buffer中,rewrite成功后这些操作也会复制到临时文件中,在最后临时文件会代替AOF文件。

以上在AOF打开的情况下,如果AOF是关闭的,那么rewrite操作可以通过bgrewriteaof命令来进行。

 

Redis Bgrewriteaof 命令用于异步执行一个 AOF(AppendOnly File) 文件重写操作。重写会创建一个当前 AOF 文件的体积优化版本。

即使 Bgrewriteaof 执行失败,也不会有任何数据丢失,因为旧的 AOF 文件在 Bgrewriteaof 成功之前不会被修改。

注意:从 Redis 2.4 开始, AOF 重写由 Redis 自行触发, BGREWRITEAOF 仅仅用于手动触发重写操作。

 

 

官网介绍:

redis持久化(aof) append online file:
写log(aof), 到一定程度再和内存合并. 追加再追加, 顺序写磁盘, 对性能影响非常小

一个master可以拥有多个slave

自动的bgrewriteaof

为了避免aof文件过大,我们会周期性的做bgrewriteaof来重整aof文件。以前我们会额外的配置crontab在业务低峰期执行这个命令,这额外的增加一个workaroud的脚本任务在大集群里是很糟糕的,不易检查,出错无法即时发现。

于是这个自动bgrewriteaof功能被直接加到redis的内部。首先对于aof文件,server对象添加一个字段来记录aof文件的大小server.appendonly_current_size,每次aof发生变化都会维护这个字段。

bgrewriteaof完毕或者实例启动载入aof数据后也会调用aofUpdateCurrentSize这个函数维护这个字段,同时会记录下此时的aof文件的大小server.auto_aofrewrite_base_size作为基准值,用于接下来判断aof增长率。

有了当前值和基准值我们就可以判断aof文件的增长情况。另外还需要配置两个参数来判断是否需要自动触发bgrewriteaof。

?auto-aof-rewrite-percentage:aof文件的大小超过基准百分之多少后触发bgrewriteaof。默认这个值设置为100,意味着当前aof是基准大小的两倍的时候触发bgrewriteaof。把它设置为0可以禁用自动触发的功能。
auto-aof-rewrite-min-size: 当前aof文件大于多少字节后才触发。避免在aof较小的时候无谓行为。默认大小为64mb。
两个参数都是可以在conf里静态配置,或者通过config set来动态修改的。

新濠国际登录平台 5

appendonly? 是否开启aof缓存机制

appendfilename??? aof文件的名称

appendfsync?? 的三种执行方式:

 

调用fsync()方式让操作系统写数据到磁盘上,数据同步方式,有下列三种模式

always????????? 每次都调用,比如安全,但速度最慢;

everysec?????? 每秒同步,这也是默认方式;

no ? ? ???????? 不调用fsync,由操作系统决定何时同步,比如快的模式;

no-appendfsync-on-rewrite?? no

 

如上面所说到的bgrewriteaof机制,在一个子进程中进行aof的重写,从而不阻塞主进程对其余命令的处理,同时解决了aof文件过大问题。现在问题出现了,同时在执行bgrewriteaof操作和主进程写aof文件的操作,两者都会操作磁盘,而bgrewriteaof往往会涉及大量磁盘操作,这样就会造成主进程在写aof文件的时候出现阻塞的情形,现在no-appendfsync-on-rewrite参数出场了。如果该参数设置为no,是最安全的方式,不会丢失数据,但是要忍受阻塞的问题。如果设置为yes呢?这就相当于将appendfsync设置为no,这说明并没有执行磁盘操作,只是写入了缓冲区,因此这样并不会造成阻塞(因为没有竞争磁盘),但是如果这个时候redis挂掉,就会丢失数据。丢失多少数据呢?在linux的操作系统的默认设置下,最多会丢失30s的数据。

因此,如果应用系统无法忍受延迟,而可以容忍少量的数据丢失,则设置为yes。如果应用系统无法忍受数据丢失,则设置为no。

  在指定的时间间隔内存中的数据集快照写入磁盘,也就是行话将的Snapshot快照,它恢复时是将快照文件直接读到内存中。

  1. 单实例单进程

多个slave可以连接同一个master,还可以连接到其他slave

三.总结:

AOF和RDB各有优缺点,这是有它们各自的特点所决定:

1) AOF更加安全,可以将数据更加及时的同步到文件中,但是AOF需要较多的磁盘IO开支,AOF文件尺寸较大,文件内容恢复数度相对较慢。
*2) snapshot,安全性较差,它是“正常时期”数据备份以及master-slave数据同步的最佳手段,文件尺寸较小,恢复数度较快。

可以通过配置文件来指定它们中的一种,或者同时使用它们(不建议同时使用),或者全部禁用,在架构良好的环境中,master通常使用AOF,slave使用snapshot,主要原因是master需要首先确保数据完整性,它作为数据备份的第一选择;slave提供只读服务(目前slave只能提供读取服务),它的主要目的就是快速响应客户端read请求;但是如果你的redis运行在网络稳定性差/物理环境糟糕情况下,建议你master和slave均采取AOF,这个在master和slave角色切换时,可以减少“人工数据备份”/“人工引导数据恢复”的时间成本;如果你的环境一切非常良好,且服务需要接收密集性的write操作,那么建议master采取snapshot,而slave采用AOF。

Redis数据恢复

当redis服务器挂掉时,重启时将按以下优先级恢复数据到内存种:

1.?如果只配置了AOF,重启时加载AOF文件恢复数据.

2.?如果同时配置了RBD和AOF,启动时只加载AOF文件恢复数据.

3.?如果只配置了RDB,启动时将加载dump文件恢复数据。

redis 持久化缓存: 一:SNAPSHOTTING(快照方式 -》二进制文件) ①定时生成快照 ②定量生成快照 观察r...

是什么:

Redis使用的是单进程,所以在配置时,一个实例只会用到一个CPU;
在配置时,如果需要让CPU使用率最大化,可以配置Redis实例数对应CPU数, Redis实例数对应端口数(8核Cpu, 8个实例, 8个端口), 以提高并发:
单机测试时, 单条数据在200字节, 测试的结果为8~9万tps;

主从复制不会阻塞master,在同步数据时,master可以继续处理client请求。

  Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到内存里一个临时文件中,待持久化过程都结束了,在用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能对丢失。

  1. Replication

提高系统的伸缩性

Fork:

过程: 数据写到master–>master存储到slave的rdb中–>slave加载rdb到内存。
存储点(save point): 当网络中断了, 连上之后, 继续传.
Master-slave下第一次同步是全传,后面是增量同步;
Redis的所有数据都是保存在内存中,然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”);也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。

2.Redis主从同步的过程

  Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量,环境变量,程序计数器等)数值都是和原进程一致,但是是一个全新的进程,并作为原进程的子进程。(存在一个问题:如果原程序的数据数据特别大,fork一份)


配置好slave服务器连接master后,slave会建立和master的连接,然后发送sync命令。

Rdb 保存的是dump.rdb文件

持久化的两种方式:

无论是第一次同步建立的连接还是连接断开后的重新连接,master都会启动一个后台进程,将数据库快照保存到磁盘文件中,同时master主进程会开始收集新的写命令并缓存起来。

Save the DB on disk

一:第一种方法filesnapshotting:默认redis是会以快照的形式将数据持久化到磁盘的(一个二进 制文件,dump.rdb,这个文件名字可以指定),在配置文件中的格式是:save N M表示在N秒之内,redis至少发生M次修改则redis抓快照到磁盘。当然我们也可以手动执行save或者bgsave(异步)做快照。
工作原理:当redis做持久化的时候,redis会fork一个进程;子进程将数据写到磁盘上的一个临时rdb文件中;写完后,将原来的rdb替换掉,好处就是可以copy-on-write;
还有一种持久化方法:Append-only:filenapshotting方法在redis死掉时,最近的数据会丢失。Append-only方法可以做到全部数据不丢失,但是会影响性能。aof就可以做到全程持久化,只需要在配置文件中开启(默认no),appendonly yes开启aof后,redis每执行一个修改数据的命令,都会把它添加到aof文件中,当redis重启时,将会读取aof文件进行“重放”来回复到redis关闭前的最后一刻。--当使用AOF时,redis推荐同时使用BGREWRITEAOF。

当后台进程完成写磁盘文件后,master就将快照文件发送给slave,slave将文件保存到磁盘上,然后加载到内存将数据库快照恢复到slave上。

# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
#
# Note: you can disable saving completely by commenting out all "save" lines.
#


slave完成快照文件的恢复后,master就会把缓存的命令都转发给slave,slave更新内存数据库。

如果想禁用RDB持久化的策略,只要不设置任何save指令,或者给save传入一个空字符串参数也可以
# It is also possible to remove all the previously configured save
# points by adding a save directive with a single empty string argument
# like in the following example:
#
# save ""

AOF文件刷新的方式,有三种,参考配置参数appendfsync :appendfsync always每提交一个修改命令都调用fsync刷新到AOF文件,非常非常慢,但也非常安全;appendfsync everysec每秒钟都调用fsync刷新到AOF文件,很快,但可能会丢失一秒以内的数据;appendfsync no依靠OS进行刷新,redis不主动刷新AOF,这样最快,但安全性就差。默认并推荐每秒刷新,这样在速度和安全上都做到了兼顾。

redis支持两种方式持久化:1.Snapshotting(快照)也是默认方式;2.Append-only file(aof)方式。
1.Snapshotting
快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久 化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照,下面是默认的快照保存配置

save 900 1 #900秒内如果超过1个key被修改,则发起快照保存
save 300 10 #300秒内容如超过10个key被修改,则发起快照保存
save 60 10000
2.Append-only file

aof 比快照方式有更好的持久化性,是由于在使用aof持久化方式时,redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存 write做的修改,所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis我们想要 通过fsync函数强制os写入到磁盘的时机。有三种方式如下(默认是:每秒fsync一次)

appendonly yes //启用aof持久化方式

后续master收到的写命令都会通过开始建立的连接发送给slave。从master到slave的同步数据的命令和从client到master发送的命令使用相同的协议格式。当master和slave的连接断开时,slave可以自动重新建立连接。如果master同时收到多个slave发来的同步连接命令,只会使用启动一个进程来写数据库镜像,然后发送给所有slave。

RDB是整个内存的压缩过的Snapshot,RDB的数据结构,可以配合复合的快照触发条件,

appendfsync always //每次收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用

appendfsync everysec //每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,推荐

3 Redis主动同步设置方法

默认是

appendfsync no //完全依赖os,性能最好,持久化没保证

aof 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次,文件中必须保存全部的100条命令,其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100就够了。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据 以命令的方式保存到临时文件中,最后替换原来的文件。具体过程如下

  1. redis调用fork ,现在有父子两个进程
  2. 子进程根据内存中的数据库快照,往临时文件中写入重建数据库状态的命令
    3.父进程继续处理client请求,除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
    4.当子进程把快照内容写入已命令方式写到临时文件中后,子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
    5.现在父进程可以使用临时文件替换老的aof文件,并重命名,后面收到的写命令也开始往新的aof文件中追加。

需要注意到是重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。

1 )在redis.conf配置文件中设置

  1分钟内改了1万次,

通过简单的配置slave(master端无需配置),用户就能使用redis的主从复制
我们让端口6379的redis做master;另一台端口6379的redis做slave

  或5分钟内改了10万次,

我们修改slave主机的redis.conf的配置文件
vim   redis.conf | sed -n '189,215p'
   189  ################################# REPLICATION #################################
   190 
   191  # Master-Slave replication. Use slaveof to make a Redis instance a copy of
   192  # another Redis server. Note that the configuration is local to the slave
   193  # so for example it is possible to configure the slave to save the DB with a
   194  # different interval, or to listen to another port, and so on.
   195  #
   196  # slaveof <masterip> <masterport>
   197  slaveof 172.16.1.2 6379              在此处添加本行内容,指定主master的IP和端口
   198  # If the master is password protected (using the "requirepass" configuration
   199  # directive below) it is possible to tell the slave to authenticate before
   200  # starting the replication synchronization process, otherwise the master will
   201  # refuse the slave request.
   202  #
   203  # masterauth <master-password>
   204  masterauth 123456                    在此处添加本行内容,指定验证的密码
   205  # When a slave loses its connection with the master, or when the replication
   206  # is still in progress, the slave can act in two different ways:
   207  #
   208  # 1) if slave-serve-stale-data is set to 'yes' (the default) the slave will
   209  #    still reply to client requests, possibly with out of date data, or the
   210  #    data set may just be empty if this is the first synchronization.
   211  #
   212  # 2) if slave-serve-stale-data is set to 'no' the slave will reply with
   213  #    an error "SYNC with master in progress" to all the kind of commands
   214  #    but to INFO and SLAVEOF.
   215  #

  或15分钟内改了1次。

2)进行redis主从同步测试

 

redis-cli   -a  123456  get name      #获取master    redis6379的键name的值
"benet"
[root@redis-master ~]# redis-cli -a 123456  set name xxxxx    #向redis6379里存一个key=name,value=xxxxx的数据
OK
[root@redis-master ~]# redis-cli -a 123456  get name  #获取redis6379的键name的值
"xxxxx"

可以使用 save命令立即进行备份

3.Append-Only File(追加式的操作日志)

 

  • 另外由于快照方式是在一定间隔时间做一次的,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话,可以采用aof持久化方式。下面介绍Append-only file。
  • aof比快照方式有更好的持久化性,是由于在使用aof持久化方式时,redis会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容.当然由于os会在内核中缓存write做的修改,所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis我们想要通过fsync函数强制os写入到磁盘的时机。有三种方式如下(默认是:每秒fsync一次)
  • appendonly yes #启用aof持久化方式
  • appendfsync always #收到写命令就立即写入磁盘,最慢,但是保证完全的持久化
  • appendfsync everysec #美秒钟写入磁盘一次,在性能和持久化方面做了很好的折中
  • appendfsync no #完全依赖os,性能最好,持久化没保证
  • redis还支持一种追加式的操作日志记录,叫append only file,其日志文件以aof结尾,我们一般各为aof文件。要开启aof日志的记录,你需要在配置文件中进行如下设置:

# 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.
stop-writes-on-bgsave-error yes

aof引发的问题:

如果在后台save出错了,前台要停止写

aof的方式也同时带来了另一个问题。持久化文件会变得越来越大.例如我们调用incr test命令100次,文件中必须保存全部的100条命令,其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100 就够了。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中,最后替换原来的文件。具体过程如下:

如果配置成no,表示你不在乎数据不一致或者有其他的手段发现和控制

  • redis调用fork,现在有父子两个进程
  • 子进程根据内存中的数据库快照,往临时文件中写入重建数据库状态的命令。
  • 父进程继续处理client请求,除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来.这样就能保证如果子进程重写失败的话并不会出问题。
  • 当子进程把快照内容写入已命令方式写到临时文件中后,子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
  • 现在父进程可以使用临时文件替换老的aof文件,并重命令名,后面收到的写命令也开始往新的aof文件中追加。

 

需要注意到是重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。接下来我们看一下实际的例子。

# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes

开启bgrewriteaof重写的方式

rdbcompressiion:对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话,可以设置关闭此功能

##开启AOF
vim /usr/local/redis/conf/redis.conf
   449  appendonly yes                  #修改本行内容开启AOF
新濠国际登录平台,  
#重启redis服务
[root@redis-master redis]# redis-cli -a 123456 shutdown
[4022] 08 Oct 23:27:22.183 # User requested shutdown...
[4022] 08 Oct 23:27:22.183 * Saving the final RDB snapshot before exiting.
[4022] 08 Oct 23:27:22.195 * DB saved on disk
[4022] 08 Oct 23:27:22.195 # Redis is now ready to exit, bye bye...
[1]+  Done                    redis-server /usr/local/redis/conf/redis.conf
[root@redis-master redis]# redis-server /usr/local/redis/conf/redis.conf &

 

#关于bgrewriteaof重写的配置文件代码如下:
vim   /usr/local/redis/conf/redis.conf 
   503  # Automatic rewrite of the append only file.
   504  # Redis is able to automatically rewrite the log file implicitly calling
   505  # BGREWRITEAOF when the AOF log size grows by the specified percentage.
   506  #
   507  # This is how it works: Redis remembers the size of the AOF file after the #它是如何工作的呢?redis会记住AOF文件的大小
   508  # latest rewrite (if no rewrite has happened since the restart, the size of #当最后一次重写的时候,如果在重启时没有重写发生。
   509  # the AOF at startup is used).  #那么AOF文件会在开始时被使用
   510  #
   511  # This base size is compared to the current size. If the current size is
   512  # bigger than the specified percentage, the rewrite is triggered. Also
   513  # you need to specify a minimal size for the AOF file to be rewritten, this
   514  # is useful to avoid rewriting the AOF file even if the percentage increase
   515  # is reached but it is still pretty small.
   516  #
   517  # Specify a percentage of zero in order to disable the automatic AOF
   518  # rewrite feature.
   519 
   520  auto-aof-rewrite-percentage 100 #当100%达到最小大小的时候才会执行重写
   521  auto-aof-rewrite-min-size 64mb  #自动重写aof文件的最小大小

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes

 

rdbchecksum:在存储快照后,还可以让redis使用CRC64算法来进行数据校验,但这样会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能,不过一般不用关,可以再空闲时进行压缩和校验

本文由新濠国际登录平台发布于每日资讯,转载请注明出处:新进程的所有数据(变量,②定量生成快照

关键词: