上一篇blog在linux中安装了Redis，并且对Redis进行了启动和操作。本篇blog主要学习下Redis的持久化策略。什么是持久化呢？举个最简单的例子，就是内存中的数据如果突然遭遇断电，将会丢失，那么为了保证数据不丢失，内存中的数据要持久化到硬盘里来，利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。持久化的作用就是防止数据的意外丢失，确保数据安全性！也就是为什么我们每写会儿文档就要保存一次的原因。
在这里插入图片描述
因为Redis本质上也是个数据库，所以也面临持久化的问题，Redis提供的持久化策略有两种，一种是RDB，也就是数据快照，一种是AOF，也就是数据日志。

RDB方案

RDB是数据快照的持久化策略，只存储数据结果，存储格式简单，关注点在数据。依据执行持久化时机分为如下三种策略：

save即时执行策略

save即使生成策略持久化的命令为save。我们执行下查看：

127.0.0.1:6379> keys *
1) "love"
127.0.0.1:6379> save
OK
127.0.0.1:6379> set age 26
OK
127.0.0.1:6379> save
OK
127.0.0.1:6379> set sex girl
OK
127.0.0.1:6379> save
OK
127.0.0.1:6379>

我们找到之前设定的log文件地址查看文件，可以看到生成了一个新的文件：
在这里插入图片描述

save执行原理

这就是之前大佬们老是讨论的而我一无所知的dump快照文件啊！，那么save执行的原理是什么呢？因为redis是单线程的，所以多客户端操作的时候，会有个指令执行顺序。
在这里插入图片描述
save指令比较耗费服务器性能！

RDB最佳配置

在这里插入图片描述
其实使用RDB存在一些最佳实践，我们调整下它的配置，还是在redis-6379.conf进行修改，修改后配置为：

port 6379
daemonize yes
logfile "redis-6379.log" 
dir /root/redis-6.0.8/data/
dbfilename dump-6379.rdb
rdbcompression yes
rdbchecksum yes

同时我们可以把6380也同步修改了即可，修改完后杀掉进程，重启服务：

[root@192 ~]# ps -ef |  grep redis-
root      35924      1  0 11:28 ?        00:01:05 redis-server *:6379
root      36048      1  0 11:35 ?        00:01:04 redis-server *:6380
root      39574  39523  5 15:24 pts/0    00:00:00 grep --color=auto redis-
[root@192 ~]# kill -s 9 35924
[root@192 ~]# kill -s 9 36048
[root@192 ~]# ps -ef |  grep redis-
root      39591  39523  0 15:25 pts/0    00:00:00 grep --color=auto redis-
[root@192 redis-6.0.8]# redis-server config/redis-6379.conf
[root@192 redis-6.0.8]# redis-cli -p 6379
127.0.0.1:6379> set name tml love guochengyu
(error) ERR syntax error
127.0.0.1:6379> set name tmlloveguochengyu
OK
127.0.0.1:6379> get name
"tmlloveguochengyu"
127.0.0.1:6379> save
OK
127.0.0.1:6379>

我们可以看到已经写了新的dump文件进入data了，我们把之前的删掉即可。
在这里插入图片描述
查看即可隐约看到文件内容：

[root@192 redis-6.0.8]# cd data/
[root@192 data]# ll
总用量 12
-rw-r--r-- 1 root root  121 10月 24 15:30 dump-6379.rdb
-rw-r--r-- 1 root root 3102 10月 24 15:30 redis-6379.log
-rw-r--r-- 1 root root 1447 10月 24 11:35 redis-6380.log
[root@192 data]# cat dump-6379.rdb 
REDIS0009dis-ver6.0.8edis-bitsctime_ed-mem

bgsave后台执行策略

使用指令bgsave会使用延迟执行save策略。

[root@192 redis-6.0.8]# redis-cli 
127.0.0.1:6379> set age 35
OK
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379>

在这里插入图片描述

bgsave执行的这个子进程不参与redis的数据读写，可以通过查看日志文件看到这个信息：

39800:M 24 Oct 2020 15:44:54.394 * Background saving started by pid 39915
39915:C 24 Oct 2020 15:44:54.397 * DB saved on disk
39915:C 24 Oct 2020 15:44:54.397 * RDB: 0 MB of memory used by copy-on-write
39800:M 24 Oct 2020 15:44:54.408 * Background saving terminated with success

条件save后台执行策略

限定时间限定条件的save持久化：满足限定时间内key的变化数量达到指定数量则进行持久化。命令为：

save second changes

second代表指定时间，changes代表key的变化数量，如果设置为：

save 100  10

100秒内有10个key变化则进行持久化，那么如果我在100秒到期的时候只有9个key变化，则重置时间，重新从上一次持久化后的key的变化数全量统计变化值【实际上也就是9个】，也就是剩余100秒只需再等待一个key变化就能进行持久化了。

配置添加

需要在配置文件进行配置：

port 6379
daemonize yes
logfile "redis-6379.log" 
dir /root/redis-6.0.8/data/
dbfilename dump-6379.rdb
rdbcompression yes
rdbchecksum yes
save 10 2

配置完成后进行下实验，首先重启后台进程：

[root@192 redis-6.0.8]# ps -ef |  grep redis-              
root      39800      1  1 15:37 ?        00:00:22 redis-server *:6379
root      40243  39523  0 16:05 pts/0    00:00:00 grep --color=auto redis-
[root@192 redis-6.0.8]# kill -s 9 39800
[root@192 redis-6.0.8]# ps -ef |  grep redis-
root      40246  39523  0 16:05 pts/0    00:00:00 grep --color=auto redis-
[root@192 redis-6.0.8]# redis-server config/redis-6379.conf

同时干掉快照文件：
在这里插入图片描述
然后进行实验，要记住两点，1，只有对key产生变化的才算【get不算，del和set都算】，2，同一个key的两次变化都算，因为不进行数据比对，redis不会记忆上一个变化的是什么。我们先操作一次：

127.0.0.1:6379> set name tmlhhhh
OK
127.0.0.1:6379> get name
"tmlhhhh"
127.0.0.1:6379> 
[root@192 redis-6.0.8]#

这里可以看到虽然是两条指令，但一条是get不算。我们可以看到还是没有dump文件产生：
在这里插入图片描述
接下来我们再操作一次：

[root@192 redis-6.0.8]# redis-cli  
127.0.0.1:6379> set age 25
OK
127.0.0.1:6379>

dump文件产生了，我们可以看到：
在这里插入图片描述

条件save执行原理

带有条件的save的工作原理如下：
在这里插入图片描述
需要注意的是：

save配置后台执行的是bgsave的操作，只是有一定的触发时间
second和change要设置成互补的，如果是相同的则没什么意义。例如如果我业务量特别大，每10秒更新1000条数据，我设置的key太小了没什么意义，一会儿一次dump写入，要爆炸，所以设置成save 1 100000，也就是1秒内变化的key数量不超过100000，就不需要写入dump了，反之，如果我业务量很小，每10秒更新1条数据，但是这条数据又很重要，那么我需要尽快持久化，所以设置成save 100 1，也就是100秒内，只要有一条变化就写入dump，实际情况往往是依据业务场景来的

以上就是RDB的优化方式。

RDB三种执行策略对比

以下是三种执行RDB方式的对比：

方式	save	bgsave	条件save
读写	同步	异步	满足条件异步
阻塞客户端指令	是	否	否
额外内存	否	是	是
启动新进程	否	是	是
推荐使用度	低	中	高

其实说白了，又是一个空间换时间的例子。另外说几个特殊的RDB启动时机：

进行全量复制时，首先需要有快照
重启服务Redis时，可以执行RDB：debug reload
关闭服务Redis的时候可以执行RDB：shutdown save

以上就是一些特殊的启动形式

RDB恢复文件

我们存储了快照，那么该如何验证快照能恢复回数据呢？我们先把进程杀掉，也就是把内存里的干掉，看能不能恢复回来。

[root@192 redis-6.0.8]# redis-cli -p 6379
127.0.0.1:6379> keys *
1) "name"
127.0.0.1:6379> get name
"tmlloveguochengyu"
[root@192 redis-6.0.8]# ps -ef |  grep redis-              
root      39624      1  1 15:27 ?        00:00:09 redis-server *:6379
root      39782  39523  0 15:36 pts/0    00:00:00 grep --color=auto redis-
[root@192 redis-6.0.8]# kill -s 9 39624
[root@192 redis-6.0.8]# ps -ef |  grep redis-
root      39794  39523  0 15:37 pts/0    00:00:00 grep --color=auto redis-
[root@192 redis-6.0.8]# redis-server config/redis-6379.conf
[root@192 redis-6.0.8]# ps -ef |  grep redis-              
root      39800      1  0 15:37 ?        00:00:00 redis-server *:6379
root      39806  39523  0 15:37 pts/0    00:00:00 grep --color=auto redis-
[root@192 redis-6.0.8]# redis-cli
127.0.0.1:6379> keys *
1) "name"
127.0.0.1:6379> get name
"tmlloveguochengyu"

我们杀掉进程后重启服务端，发现数据还留存着，其实就是当我们重启服务端的时候Redis读取dump文件将数据恢复了。

RDB优缺点

优点

RDB存储效率高【能存更多】，RDB文件是紧凑的二进制文件，存储效率高，比较适合做冷备，灾备，全量复制的场景。RDB做会生成多个文件，每个文件都代表了某一个时刻的Redis完整的数据快照，RDB这种多个数据文件的方式，非常适合做冷备，因为大量的一个个的文件，可以每隔一定的时间，复制出来；可以将这种完整的数据文件发送到一些远程的云服务、分布式存储上进行安全的存储，以预定好的备份策略来定期备份Redis中的数据；
RDB恢复数据更快【能恢复更快】，直接基于RDB数据文件来重启和恢复Redis进程，更加快速：RDB就是一份数据文件，恢复的时候，直接加载到内存中即可；
**RDB对Redis的读写无影响，RDB对Redis【不影响Redis】对外提供的读写服务，影响非常小，可以让Redis保持高性能，因为Redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可;RDB每次写，都是直接写Redis内存，只是在一定的时候，才会将数据写入磁盘中

缺点

RDB无法做到实时持久化【可能会丢数据】，一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦Redis进程宕机，那么会丢失最近5分钟的数据；这个问题，也是RDB最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多;
RDB在fork子进程时消耗内存【有一些内存损耗】，RDB每次在fork子进程来执行RDB快照数据文件生成的时候，都会牺牲一些内存。
RDB基于快照，每次读写都是全量数据，数据量大时性能较低
RDB如果设置的dump读写时间不合适，大数据量下会有IO频繁的风险

以上就是RDB的优缺点，学习完AOF后，我们来一个整体的对比

AOF方案

AOF是数据快照的持久化策略，存储操作过程，存储格式复杂，关注点在数据的操作过程。我们依据RDB的缺点就能理解AOF的存在价值了，因为没有哪种策略是完美的，只有合适的：

RDB无法做到实时持久化【可能会丢数据】，一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦Redis进程宕机，那么会丢失最近5分钟的数据；这个问题，也是RDB最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多;
RDB在fork子进程时消耗内存【有一些内存损耗】，RDB每次在fork子进程来执行RDB快照数据文件生成的时候，都会牺牲一些内存。
RDB基于快照，每次读写都是全量数据，数据量大时性能较低
RDB如果设置的dump读写时间不合适，大数据量下会有IO频繁的风险

基于以上问题，我们看下AOF的实现。

只记录部分数据，不记录全量数据
只记录操作过程，不记录操作数据
对所有操作均记录，降低丢失数据的可能性。

AOF是以独立日志的形式存在的方式记录每次执行的命令，重启时再执行AOF中记录的命令来达到恢复数据的目的，也就是改记录数据为记录日志，主要解决的就是RDB的非实时持久化的问题，现在已经是Redis持久化的主流方式，优先使用这个。
在这里插入图片描述

AOF的三种策略

依据何时将命令从缓存区同步到AOF文件的时机，有以下几种策略

always写数据策略

Redis 在每个事件循环都要将 AOF 缓冲区中的所有内容写入到 AOF 文件，并且同步 AOF 文件，所以 always 的效率是 appendfsync 选项三个值当中最差的一个，但从安全性来说，也是最安全的。当发生故障停机时，AOF 持久化也只会丢失一个事件循环中所产生的命令数据。数据零误差，性能极低，不推荐使用

everysec写数据策略

Redis 在每个事件循环都要将 AOF 缓冲区中的所有内容写入到 AOF 文件中，并且每隔一秒就要在子线程中对 AOF 文件进行一次同步。从效率上看，该模式足够快。当发生故障停机时，只会丢失一秒钟的命令数据。准确性较高，性能较高，推荐使用

no写数据策略

Redis 在每一个事件循环都要将 AOF 缓冲区中的所有内容写入到 AOF 文件。而 AOF 文件的同步由操作系统控制。这种模式下速度最快，但是同步的时间间隔较长，出现故障时可能会丢失较多数据

AOF的基本操作

我们需要开启AOF的配置，同时指定AOF的操作策略，配置更新为：

port 6379
daemonize yes
logfile "redis-6379.log" 
dir /root/redis-6.0.8/data/
dbfilename dump-6379.rdb
rdbcompression yes
rdbchecksum yes
save 10 2
appendonly yes
appendfilename appendonly-6379.aof
appendfsync everysec

杀掉进程，重新启动Redis后我们可以看到一个新的文件产生了：
在这里插入图片描述

然后我们操作几个命令：

[root@192 redis-6.0.8]# ps -ef |  grep redis-              
root      41544      1  2 17:28 ?        00:00:02 redis-server *:6379
root      41572  39523  1 17:30 pts/0    00:00:00 grep --color=auto redis-
[root@192 redis-6.0.8]# kill -s 9 41544
[root@192 redis-6.0.8]# ps -ef |  grep redis-
root      41580  39523  0 17:30 pts/0    00:00:00 grep --color=auto redis-
[root@192 redis-6.0.8]# redis-server config/redis-6379.conf
[root@192 redis-6.0.8]# redis-cli                          
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set color red
OK
127.0.0.1:6379> get color
"red"
127.0.0.1:6379> 
[root@192 redis-6.0.8]# cd data
[root@192 data]# ll
总用量 28
-rw-r--r-- 1 root root    56 10月 24 17:30 appendonly-6379.aof
-rw-r--r-- 1 root root   118 10月 24 16:11 dump-6379.rdb
-rw-r--r-- 1 root root 12957 10月 24 17:30 redis-6379.log
-rw-r--r-- 1 root root  1447 10月 24 11:35 redis-6380.log
[root@192 data]# cat appendonly-6379.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$5
color
$3
red
[root@192 data]# redis-cli 
127.0.0.1:6379> set age 55
OK
127.0.0.1:6379> 
[root@192 data]# ll
总用量 28
-rw-r--r-- 1 root root    86 10月 24 17:31 appendonly-6379.aof
-rw-r--r-- 1 root root   115 10月 24 17:31 dump-6379.rdb
-rw-r--r-- 1 root root 13307 10月 24 17:31 redis-6379.log
-rw-r--r-- 1 root root  1447 10月 24 11:35 redis-6380.log
[root@192 data]# cat appendonly-6379.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$5
color
$3
red
*3
$3
set
$3
age
$2
55

可以看到，文件中已经写入了记录key变化的命令，当然还是变化的【set、del等，get不会记录】。

需要注意的是，启用了AOF，重启服务器就不会启动RDB快照恢复数据了，所以我们这里看到的key是空的，如果我们设置appendonly no，重启服务器则还是可以拿到RDB的快照文件。

[root@192 redis-6.0.8]# ps -ef |  grep redis-              
root      41484      1  2 17:25 ?        00:00:04 redis-server *:6379
root      41533  39523  0 17:28 pts/0    00:00:00 grep --color=auto redis-
[root@192 redis-6.0.8]# kill -s 9 41377                    
-bash: kill: (41377) - 没有那个进程
[root@192 redis-6.0.8]# kill -s 9 41484
[root@192 redis-6.0.8]# redis-server config/redis-6379.conf
[root@192 redis-6.0.8]# redis-cli                          
127.0.0.1:6379> keys *
1) "name"
2) "age"
127.0.0.1:6379>

AOF重写机制

因为 AOF 持久化是通过保存被执行的写命令来记录 Redis 状态的，所以随着 Redis 长时间运行，AOF 文件中的内容会越来越多，文件的体积也会越来越大，如果不加以控制的话，体积过大的 AOF 文件很可能对 Redis 甚至宿主计算机造成影响。为了解决 AOF 文件体积膨胀的问题，Redis 提供了 AOF 文件重写( rewrite) 功能。通过该功能，Redis 可以创建一个新的 AOF 文件来替代现有的 AOF 文件。新旧两个 AOF 文件所保存的 Redis 最终状态相同，但是新的 AOF 文件不会包含任何浪费空间的冗余命令，所以新 AOF 文件的体积通常比旧 AOF 文件的体积要小得很多
在这里插入图片描述

AOF重写规则

并不是所有的AOF数据都需要重写。

进程里超时的数据不再重写，例如进程里已经过期的一些数据就不再重写了。
忽略无效指令，重写时使用进程中的最终数据直接生成，这样AOF只保留最终数据生成命令。例如连续冗余的set。
对同一数据的多条指令进行合并，例如3次incr num，可以调整为：set num 3

满足这些条件就会触发重写，以降低AOF文件的内存占用。

AOF重写执行方式

AOF共有两种重写执行方式，都是在后台进行的，只不过一个为手动触发，一个为自动触发。

手动AOF后台重写

[root@192 redis-6.0.8]# redis-server config/redis-6379.conf
[root@192 redis-6.0.8]# clear
[root@192 redis-6.0.8]# redis-cli
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set name tml
OK
127.0.0.1:6379> set name ttt
OK
127.0.0.1:6379> set name 555
OK
127.0.0.1:6379> set name 666
OK
127.0.0.1:6379> set name 777
OK
127.0.0.1:6379> set age 333
OK
127.0.0.1:6379> set age 333
OK
127.0.0.1:6379> del name
(integer) 1
[root@192 redis-6.0.8]# cd data
[root@192 data]# ll
总用量 32
-rw-r--r-- 1 root root   214 10月 24 20:50 appendonly-6379.aof
-rw-r--r-- 1 root root   114 10月 24 20:50 dump-6379.rdb
-rw-r--r-- 1 root root 16504 10月 24 20:50 redis-6379.log
-rw-r--r-- 1 root root  1447 10月 24 11:35 redis-6380.log
[root@192 data]# cat appendonly-6379.aof 
*2
$6
SELECT
$1
0
*3
$3
set
$4
name
$3
tml
*3
$3
set
$4
name
$3
ttt
*3
$3
set
$4
name
$3
555
*3
$3
set
$4
name
$3
666
*3
$3
set
$4
name
$3
777
*3
$3
set
$3
age
$3
333
del
$4
name
$3[root@192 data]# ll
总用量 32
-rw-r--r-- 1 root root   237 10月 24 20:52 appendonly-6379.aof
-rw-r--r-- 1 root root   114 10月 24 20:50 dump-6379.rdb
-rw-r--r-- 1 root root 16504 10月 24 20:50 redis-6379.log
-rw-r--r-- 1 root root  1447 10月 24 11:35 redis-6380.log
[root@192 data]# redis-cli
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
127.0.0.1:6379> 
[root@192 data]# ll
总用量 32
-rw-r--r-- 1 root root   105 10月 24 20:54 appendonly-6379.aof
-rw-r--r-- 1 root root   114 10月 24 20:50 dump-6379.rdb
-rw-r--r-- 1 root root 17290 10月 24 20:54 redis-6379.log
-rw-r--r-- 1 root root  1447 10月 24 11:35 redis-6380.log
[root@192 data]# cat appendonly-6379.aof 
REDIS0009dis-ver6.0.8edis-bitsctime_ed-mem

可以看到原来set name和delete name的多次操作，appendonly-6379.aof文件大小为237字节，经过后台重写后，只合并了最后一个命令，删除了name，appendonly-6379.aof文件大小变为105字节，从后台也可以看到日志：

44507:M 24 Oct 2020 20:54:33.965 * Background append only file rewriting started by pid 44594
44507:M 24 Oct 2020 20:54:34.000 * AOF rewrite child asks to stop sending diffs.
44594:C 24 Oct 2020 20:54:34.000 * Parent agreed to stop sending diffs. Finalizing AOF...
44594:C 24 Oct 2020 20:54:34.000 * Concatenating 0.00 MB of AOF diff received from parent.
44594:C 24 Oct 2020 20:54:34.000 * SYNC append only file rewrite performed
44594:C 24 Oct 2020 20:54:34.000 * AOF rewrite: 0 MB of memory used by copy-on-write
44507:M 24 Oct 2020 20:54:34.073 * Background AOF rewrite terminated with success
44507:M 24 Oct 2020 20:54:34.073 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
44507:M 24 Oct 2020 20:54:34.074 * Background AOF rewrite finished successfully

配置条件AOF自动重写

自动重写触发条件如下：
在这里插入图片描述
第一种触发条件为绝对触发条件，第二种为增量百分比触发条件。

AOF工作流程

理解了AOF的基本操作和重写机制后，我们看下AOF执行的重写原理：
在这里插入图片描述
我们最常用的是everysec开启重写这种模式，我们详细看下这种模式：

RDB与AOF的区别

学习完了两种持久化机制后，我们来看下两种持久化机制的对比：

持久化方式	RDB	AOF
占用存储空间	小（数据级压缩）	大（指令级重写）
存储速度	慢	快
恢复速度	快	慢
数据安全性	会丢失数据	依据策略而定，最多1秒
资源消耗	高	低
启动优先级	低	高

选择的时候可以依据如下策略，对数据敏感选择AOF【实时】，对数据不敏感选择RDB【阶段】
在这里插入图片描述

持久化应用场景分析

我们分析以前的Redis持久化的场景分析，看看是否建议使用持久化的方式：
在这里插入图片描述

总结一下：如果数据库里存储了且存的数据比较大，那么就没必要再持久化一次了，直接从数据库读取就行，当然，如果想快速加载，可以优先使用持久化。如果数据库不存储而是只在redis里进行（轻量级数据且变化速度较快且较为重要的数据）就可以使用持久化，如果数据库不存储而是只在redis里进行并且数据不怎么重要，就不需要持久化了

查看全文
如若内容造成侵权/违法违规/事实不符，请联系编程学习网邮箱：809451989@qq.com进行投诉反馈，一经查实，立即删除！

stm32库开发实战指南读书笔记（二）
文章目录stm32库开发实战指南读书笔记（二）基本硬件结构复位电路及时钟电路串口输入及供电led及key电路编写自己的库函数.h文件key.hled.h.c文件led.ckey.c具体实现机理主函数小结stm32库开发实战指南读书笔记（二） 该部分主要是函…...
2024/4/30 17:55:57
JS怎么获取当月最后一天
😎 生活要有仪式感！ 文章导航Date创建Date实例Date()构造函数的四种基本形式☞ 重点在这里简单的使用场景不会吧！不会吧！不会还有人不知道怎么获取当月最后一天吧！😂不过没关系， 这篇文章带你领…...
2024/4/9 5:24:53
二分的变体思维
常见的二分代码加粗样式 int Get_index(vector<int>& nums,int low,int hight,int target){if(low>hight){return -1;}int middle(lowhight)/2;if(nums[middle]<target){return Get_index(nums,middle1,hight,target);}else if(nums[middle]>target){ret…...
2024/4/9 5:24:52
2020-10-24c++nullptr（空指针常量）、constexpr（常量表达式）
总述又来更新了，今天带来的是nullptr空指针常量、constexpr（常量表达式）C的两个用法。Result result_fun nullptr;constexpr static uint32_t try_times 100;这是两个在工作中常用的C操作，但是你知道nullptr和constexpr由来以及…...
2024/4/25 12:33:13
java高级培训-spring框架中ioc（反转控制）的理解
学习过java相关知识的人一定已经听说过Spring的IoC（控制反转）的概念。对于那些刚接触Spring的人来说，IoC的概念总是含糊且难以理解。今天与您共享在Internet上，一些技术专家了解Spring框架的IOC，并谈论我对SpringIoc的…...
2024/4/26 2:41:55
Android学习架构图
Android学习架构图很奇怪今天1024我发布了文章竟然2个小时了都没有勋章，是因为啥原因啊？？？ 算了，这里补个享学课堂的 Android学习架构图，他们将的东西还是挺全的，可以把里面的学习架构作为自己…...
2024/4/9 3:33:51
NOIP 2018 提高组复赛第一天第三题赛道修建 track 5分代码(Floyd)+20分代码(菊花图,树的直径,链(二分)）
NOIP 2018 提高组复赛第一天第三题赛道修建 track 5分代码(Floyd)20分代码(菊花图,树的直径,链(二分)） 总目录详见：NOIP 提高组复赛试题目录信奥历年在线测评地址：https://www.luogu.com.cn/problem/P5021 1.5分代码(floyd算…...
2024/4/9 3:33:49
2020-10-24关于WBS（2）
工作（work)–可以产生有形结果的工作任务；分解（breakdown)–是一种逐步细分和分类的层级结构；结构（structure)–按照一定的模式组织各部分。根据这些概念，WBS有相应的构成因子与其对应： ⑴结构化…...
2024/4/28 11:33:22
IP基础
今天10月24日，程序员节，闲来无事自己就总结一点IP基础，拿出来耍耍！ IP地址是什么？ IP是英文InternetProtocol的缩写，意思是网络之间互连的协议，也就是为计算机网络相互连接进行通信而设计的协…...
2024/5/3 12:25:33
JavaSE第三章笔记(面向对象2)
对象与引用 Java 语言中除基本类型之外的变量类型都称之为引用类型 Java中的对象是通过引用对其操作的 class Car{String color; String name;String model; } Car car new Car(); /** *通常把这条语句的动作称之为创建一个对象，其实，它包含了三…...
2024/4/25 6:39:19
Redis事务详解
一、Redis事务的本质 Redis事务的本质是一组命令的集合，相当于一个队列，一个事务中的的所有命令都会被序列化，在事务执行过程中，按照顺序执行，且不会被中断，所以redis的事务有一次性(执行完则当前事务结束&…...
2024/4/9 5:24:49
C#编程，定时执行某种操作的一种方法。
//启动新线程public static void Start(){ThreadStart start new ThreadStart(ThreadAction);Thread th new Thread(start);th.IsBackground true;th.Start();}public static void ThreadAction(){while (true){try{System.Threading.Thread.Sleep(3000);//每隔3秒执行的方法…...
2024/4/17 7:15:44
maven--思维导图总结
...
2024/4/9 5:24:46
JavaScript 设计模式之命令模式
命令模式命令模式中的命令指的是一个执行某些特定事情的指令。（最简单的设计模式） 简单的实现 let bindClick function (button, func) {button.onclick func; }; let MenuBar {refresh: function () {console.log("刷新");}, }; let b…...
2024/4/9 5:24:46
JS学习总结（11）—— JSON
JavaScript JSON JSON 是用于存储和传输数据的格式。JSON 通常用于服务端向网页传递数据。JSON 是一种轻量级的数据交换格式。JSON 使用 JavaScript 语法，但是 JSON 格式是一个文本，可以被任何编程语言读取及作为数据格式传递。JSON 格式在语法上与创建…...
2024/4/9 5:24:44
pandas 常见操作、报错与解决方案梳理
前言： 本文为整理/大杂烩类文章，会根据实际情况不断更新。本文是笔者对工作内容的一个大致梳理，为了避免再犯同样的错误。由于是由记忆碎片拼凑而成，因此部分内容暂时没有相应的例子，但后续会不断完善。若已有文章…...
2024/4/23 11:28:43
数列的前m项的和。
数列的定义如下： 数列的第一项为n，以后各项为前一项的平方根，求数列的前m项的和。输入数据有多组，每组占一行，由两个整数n（n<10000）和m(m<1000)组成，n和m的含义如前所述。对…...
2024/4/21 22:54:24
Android入门-基础-搭建开发环境（三）
学习目标创建HelloWorld应用AndroidStudio工具常用设置学习使用Android模拟器真机调试 1.1 创建HelloWorld应用 step1: new Android Studio project step2: Phone and Tablet step3: 配置项目信息 step4: finish 02 Android Studio常用设置 2.1 设置Project Structure …...
2024/4/9 5:24:41
【Python】判断python字典中key是否存在的两种方法
今天来说一下如何判断字典中是否存在某个key，一般有两种通用做法，下面为大家来分别讲解一下： 第一种方法：使用自带函数实现。在python的字典的属性方法里面有一个has_key()方法，这个方法使用起来非常简单。例&#x…...
2024/4/9 5:24:40
非常有用的Linux系统操作命令
非常有用的Linux系统操作命令。系统# uname -a # 查看内核/操作系统/CPU信息 # head -n 1 /etc/issue # 查看操作系统版本 # cat /proc/cpuinfo # 查看CPU信息 # hostname # 查看计算机名 # lspci -tv # 列出所有PCI设备 # …...
2024/4/25 5:33:07

【Redis从入门到放弃系列九】Redis持久化策略

RDB方案

save即时执行策略

save执行原理

RDB最佳配置

bgsave后台执行策略

条件save后台执行策略

配置添加

条件save执行原理

RDB三种执行策略对比

RDB恢复文件

RDB优缺点

AOF方案

AOF的三种策略

always写数据策略

everysec写数据策略

no写数据策略

AOF的基本操作

AOF重写机制

AOF重写规则

AOF重写执行方式

手动AOF后台重写

配置条件AOF自动重写

AOF工作流程

RDB与AOF的区别

持久化应用场景分析

相关文章

最新文章

【Redis从入门到放弃系列 九】Redis持久化策略

RDB方案

save即时执行策略

save执行原理

RDB最佳配置

bgsave后台执行策略

条件save后台执行策略

配置添加

条件save执行原理

RDB三种执行策略对比

RDB恢复文件

RDB优缺点

AOF方案

AOF的三种策略

always写数据策略

everysec写数据策略

no写数据策略

AOF的基本操作

AOF重写机制

AOF重写规则

AOF重写执行方式

手动AOF后台重写

配置条件AOF自动重写

AOF工作流程

RDB与AOF的区别

持久化应用场景分析

相关文章

最新文章

【Redis从入门到放弃系列九】Redis持久化策略