Redis持久化实践及灾难恢复模拟
时间：2019-02-25 分类：Redis 作者：编程之家用户 <h2 class="title entry-title">Redis持久化实践及灾难恢复模拟
源地址：
另一篇：Redis主从自动failover
<div class="entry">
参考资料：Redis Persistence http://redis.io/topics/persistenceGoogle Groups https://groups.google.com/forum/?fromgroups=#!forum/redis-db
一、对Redis持久化的探讨与理解
目前Redis持久化的方式有两种： RDB 和 AOF
首先，我们应该明确持久化的数据有什么用，答案是用于重启后的数据恢复。Redis是一个内存数据库，无论是RDB还是AOF，都只是其保证数据恢复的措施。所以Redis在利用RDB和AOF进行恢复的时候，都会读取RDB或AOF文件，重新加载到内存中。
RDB就是Snapshot快照存储，是默认的持久化方式。可理解为半持久化模式，即按照一定的策略周期性的将数据保存到磁盘。对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。下面是默认的快照设置：
1 save 900 12 save 300 103 save 60 10000 #当有10000条Keys数据被改变时，60秒刷新到Disk一次
Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的。当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件。这样在任何时候出现故障，Redis的RDB文件都总是可用的。
同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。第一次Slave向Master同步的实现是：Slave向Master发出同步请求，Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。第二次以及以后的同步实现是：Master将变量的快照直接实时依次发送给各个Slave。但不管什么原因导致Slave和Master断开重连都会重复以上两个步骤的过程。Redis的主从复制是建立在内存快照的持久化基础上的，只要有Slave就一定会有内存快照发生。
可以很明显的看到，RDB有它的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的。从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。
AOF(Append-Only File)比RDB方式有更好的持久化性。由于在使用AOF持久化方式时，Redis会将每一个收到的写命令都通过Write函数追加到文件中，类似于MySQL的binlog。当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。对应的设置参数为：$ vim /opt/redis/etc/redis_6379.conf
12345 # appendfsync no #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。
AOF的完全持久化方式同时也带来了另一个问题，持久化文件会变得越来越大。比如我们调用INCR test命令100次，文件中就必须保存全部的100条命令，但其实99条都是多余的。因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。为了压缩AOF的持久化文件，Redis提供了bgrewriteaof命令。收到此命令后Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件，以此来实现控制AOF文件的增长。由于是模拟快照的过程，因此在重写AOF文件时并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件。对应的设置参数为:$ vim /opt/redis/etc/redis_6379.conf
1 no-appendfsync-on-2 auto-aof-rewrite-percentage 1003 auto-aof-rewrite-min-size 64mb #当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
到底选择什么呢？下面是来自官方的建议：通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用RDB。很多用户仅使用了AOF，但是我们建议，既然RDB可以时不时的给数据做个完整的快照，并且提供更快的重启，所以最好还是也使用RDB。因此，我们希望可以在未来（长远计划）统一AOF和RDB成一种持久化模式。
在数据恢复方面：RDB的启动时间会更短，原因有两个：一是RDB文件中每一条数据只有一条记录，不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作，所以在CPU消耗上要远小于AOF日志的加载。
二、灾难恢复模拟 既然持久化的数据的作用是用于重启后的数据恢复，那么我们就非常有必要进行一次这样的灾难恢复模拟了。据称如果数据要做持久化又想保证稳定性，则建议留空一半的物理内存。因为在进行快照的时候，fork出来进行dump操作的子进程会占用与父进程一样的内存，真正的copy-on-write，对性能的影响和内存的耗用都是比较大的。目前，通常的设计思路是利用Replication机制来弥补aof、snapshot性能上的不足，达到了数据可持久化。即Master上Snapshot和AOF都不做，来保证Master的读写性能，而Slave上则同时开启Snapshot和AOF来进行持久化，保证数据的安全性。
首先，修改Master上的如下配置：$ sudo vim /opt/redis/etc/redis_6379.conf
1 #save 900 12 #save 300 10
3 #save 60 10000
4
5 appendonly no #禁用AOF
接着，修改Slave上的如下配置：$ sudo vim /opt/redis/etc/redis_6379.conf
01 save 900 102 save 300 10
03 save 60 10000
04
050607080910
11 no-appendfsync-on-12 auto-aof-rewrite-percentage 10013 auto-aof-rewrite-min-size 64mb #启动新的日志重写过程的最小值
分别启动Master与Slave$ /etc/init.d/redis start
启动完成后在Master中确认未启动Snapshot参数redis 127.0.0.1:6379> CONFIG GET save1) "save"2) ""
然后通过以下脚本在Master中生成25万条数据：dongguo@redis:/opt/redis/data/6379$ cat redis-cli-generate.temp.sh
01 #!/bin/02
03 REDISCLI="redis-cli -a slavepass -n 1 SET"
04 ID=1
05
06 (($ID<5000107
08 INSTANCE_NAME="i-2-$ID-VM"
09 UUID=`cat /proc/sys/kernel/random/10 PRIVATE_IP_ADDRESS=10.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" |bc`.`echo "$RANDOM % 255 + 1" |11 CREATED=`date "+%Y-%m-%d %H:%M:%S"12
13 $REDISCLI vm_instance:$ID:instance_name "$INSTANCE_NAME"
14 $REDISCLI vm_instance:$ID:uuid "$UUID"
15 $REDISCLI vm_instance:$ID:private_ip_address "$PRIVATE_IP_ADDRESS"
16 $REDISCLI vm_instance:$ID:created "$CREATED"
17
18 $REDISCLI vm_instance:$INSTANCE_NAME:id "$ID"
19
20 ID=$(($ID+121 done
dongguo@redis:/opt/redis/data/6379$ ./redis-cli-generate.temp.sh
在数据的生成过程中，可以很清楚的看到Master上仅在第一次做Slave同步时创建了dump.rdb文件，之后就通过增量传输命令的方式给Slave了。dump.rdb文件没有再增大。dongguo@redis:/opt/redis/data/6379$ ls -lhtotal 4.0K-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb
而Slave上则可以看到dump.rdb文件和AOF文件在不断的增大，并且AOF文件的增长速度明显大于dump.rdb文件。dongguo@redis-slave:/opt/redis/data/6379$ ls -lhtotal 24M-rw-r--r-- 1 root root 15M Sep 27 12:06 appendonly.aof-rw-r--r-- 1 root root 9.2M Sep 27 12:06 dump.rdb
等待数据插入完成以后，首先确认当前的数据量。redis 127.0.0.1:6379> info
01 redis_version:2.4.17
02 redis_git_sha1:00000000
03 redis_git_dirty:0
04 arch_bits:64
0506 gcc_version:4.4.5
07 process_id:27623
0809 uptime_in_seconds:1541
10 uptime_in_days:0
11 lru_clock:650187
12 used_cpu_sys:69.28
13 used_cpu_user:7.67
14 used_cpu_sys_children:0.00
15 used_cpu_user_children:0.00
16 connected_clients:1
17 connected_slaves:1
18 client_longest_output_list:0
19 client_biggest_input_buf:0
20 blocked_clients:0
21 used_memory:33055824
22 used_memory_human:3123 used_memory_rss:34717696
24 used_memory_peak:33055800
25 used_memory_peak_human:3126 mem_fragmentation_ratio:1.05
27 mem_allocator:jemalloc-3.0.0
28 loading:0
29 aof_enabled:0
30 changes_since_last_save:250000
31 bgsave_in_progress:0
32 last_save_time:1348677645
33 bgrewriteaof_in_progress:0
34 total_connections_received:250007
35 total_commands_processed:750019
36 expired_keys:0
37 evicted_keys:0
38 keyspace_hits:0
39 keyspace_misses:0
40 pubsub_channels:0
41 pubsub_patterns:0
42 latest_fork_usec:246
43 vm_enabled:0
4445 slave0:10.6.1.144,637946 db1:keys=250000,expires=0
当前的数据量为25万条key，占用内存31.52M。
然后我们直接Kill掉Master的Redis进程，模拟灾难。dongguo@redis:/opt/redis/data/6379$ sudo killall -9 redis-server
我们到Slave中查看状态：redis 127.0.0.1:6379> info
01 redis_version:2.4.17
02 redis_git_sha1:00000000
03 redis_git_dirty:0
04 arch_bits:64
0506 gcc_version:4.4.5
07 process_id:13003
0809 uptime_in_seconds:1627
10 uptime_in_days:0
11 lru_clock:654181
12 used_cpu_sys:29.69
13 used_cpu_user:1.21
14 used_cpu_sys_children:1.70
15 used_cpu_user_children:1.23
16 connected_clients:1
17 connected_slaves:0
18 client_longest_output_list:0
19 client_biggest_input_buf:0
20 blocked_clients:0
21 used_memory:33047696
22 used_memory_human:3123 used_memory_rss:34775040
24 used_memory_peak:33064400
25 used_memory_peak_human:3126 mem_fragmentation_ratio:1.05
27 mem_allocator:jemalloc-3.0.0
28 loading:0
29 aof_enabled:1
30 changes_since_last_save:3308
31 bgsave_in_progress:0
32 last_save_time:1348718951
33 bgrewriteaof_in_progress:0
34 total_connections_received:4
35 total_commands_processed:250308
36 expired_keys:0
37 evicted_keys:0
38 keyspace_hits:0
39 keyspace_misses:0
40 pubsub_channels:0
41 pubsub_patterns:0
42 latest_fork_usec:694
43 vm_enabled:0
4445 aof_current_size:17908619
46 aof_base_size:16787337
47 aof_pending_rewrite:0
48 aof_buffer_length:0
49 aof_pending_bio_fsync:0
50 master_host:10.6.1.143
51 master_port:6379
5253 master_last_io_seconds_ago:-1
54 master_sync_in_progress:0
55 master_link_down_since_seconds:25
56 slave_priority:100
57 db1:keys=250000,expires=0
可以看到master_link_status的状态已经是down了，Master已经不可访问了。而此时，Slave依然运行良好，并且保留有AOF与RDB文件。
下面我们将通过Slave上保存好的AOF与RDB文件来恢复Master上的数据。
首先，将Slave上的同步状态取消，避免主库在未完成数据恢复前就重启，进而直接覆盖掉从库上的数据，导致所有的数据丢失。redis 127.0.0.1:6379> SLAVEOF NO ONEOK
确认一下已经没有了master相关的配置信息：redis 127.0.0.1:6379> INFO
01 redis_version:2.4.17
02 redis_git_sha1:00000000
03 redis_git_dirty:0
04 arch_bits:64
0506 gcc_version:4.4.5
07 process_id:13003
0809 uptime_in_seconds:1961
10 uptime_in_days:0
11 lru_clock:654215
12 used_cpu_sys:29.98
13 used_cpu_user:1.22
14 used_cpu_sys_children:1.76
15 used_cpu_user_children:1.42
16 connected_clients:1
17 connected_slaves:0
18 client_longest_output_list:0
19 client_biggest_input_buf:0
20 blocked_clients:0
21 used_memory:33047696
22 used_memory_human:3123 used_memory_rss:34779136
24 used_memory_peak:33064400
25 used_memory_peak_human:3126 mem_fragmentation_ratio:1.05
27 mem_allocator:jemalloc-3.0.0
28 loading:0
29 aof_enabled:1
30 changes_since_last_save:0
31 bgsave_in_progress:0
32 last_save_time:1348719252
33 bgrewriteaof_in_progress:0
34 total_connections_received:4
35 total_commands_processed:250311
36 expired_keys:0
37 evicted_keys:0
38 keyspace_hits:0
39 keyspace_misses:0
40 pubsub_channels:0
41 pubsub_patterns:0
42 latest_fork_usec:1119
43 vm_enabled:0
4445 aof_current_size:17908619
46 aof_base_size:16787337
47 aof_pending_rewrite:0
48 aof_buffer_length:0
49 aof_pending_bio_fsync:0
50 db1:keys=250000,expires=0
在Slave上复制数据文件：dongguo@redis-slave:/opt/redis/data/6379$ tar cvf /home/dongguo/data.tar *appendonly.aofdump.rdb
将data.tar上传到Master上，尝试恢复数据:可以看到Master目录下有一个初始化Slave的数据文件，很小，将其删除。dongguo@redis:/opt/redis/data/6379$ ls -ltotal 4-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdbdongguo@redis:/opt/redis/data/6379$ sudo rm -f dump.rdb
然后解压缩数据文件：dongguo@redis:/opt/redis/data/6379$ sudo tar xf /home/dongguo/data.tardongguo@redis:/opt/redis/data/6379$ ls -lhtotal 29M-rw-r--r-- 1 root root 18M Sep 27 01:22 appendonly.aof-rw-r--r-- 1 root root 12M Sep 27 01:22 dump.rdb
启动Master上的Redis；dongguo@redis:/opt/redis/data/6379$ sudo /etc/init.d/redis startStarting Redis server...
查看数据是否恢复：redis 127.0.0.1:6379> INFO
01 redis_version:2.4.17
02 redis_git_sha1:00000000
03 redis_git_dirty:0
04 arch_bits:64
0506 gcc_version:4.4.5
07 process_id:16959
0809 uptime_in_seconds:22
10 uptime_in_days:0
11 lru_clock:650292
12 used_cpu_sys:0.18
13 used_cpu_user:0.20
14 used_cpu_sys_children:0.00
15 used_cpu_user_children:0.00
16 connected_clients:1
17 connected_slaves:0
18 client_longest_output_list:0
19 client_biggest_input_buf:0
20 blocked_clients:0
21 used_memory:33047216
22 used_memory_human:3123 used_memory_rss:34623488
24 used_memory_peak:33047192
25 used_memory_peak_human:3126 mem_fragmentation_ratio:1.05
27 mem_allocator:jemalloc-3.0.0
28 loading:0
29 aof_enabled:0
30 changes_since_last_save:0
31 bgsave_in_progress:0
32 last_save_time:1348680180
33 bgrewriteaof_in_progress:0
34 total_connections_received:1
35 total_commands_processed:1
36 expired_keys:0
37 evicted_keys:0
38 keyspace_hits:0
39 keyspace_misses:0
40 pubsub_channels:0
41 pubsub_patterns:0
42 latest_fork_usec:0
43 vm_enabled:0
4445 db1:keys=250000,expires=0
可以看到25万条数据已经完整恢复到了Master上。
此时，可以放心的恢复Slave的同步设置了。redis 127.0.0.1:6379> SLAVEOF 10.6.1.143 6379OK
查看同步状态：redis 127.0.0.1:6379> INFO
01 redis_version:2.4.17
02 redis_git_sha1:00000000
03 redis_git_dirty:0
04 arch_bits:64
0506 gcc_version:4.4.5
07 process_id:13003
0809 uptime_in_seconds:2652
10 uptime_in_days:0
11 lru_clock:654284
12 used_cpu_sys:30.01
13 used_cpu_user:2.12
14 used_cpu_sys_children:1.76
15 used_cpu_user_children:1.42
16 connected_clients:2
17 connected_slaves:0
18 client_longest_output_list:0
19 client_biggest_input_buf:0
20 blocked_clients:0
21 used_memory:33056288
22 used_memory_human:3123 used_memory_rss:34766848
24 used_memory_peak:33064400
25 used_memory_peak_human:3126 mem_fragmentation_ratio:1.05
27 mem_allocator:jemalloc-3.0.0
28 loading:0
29 aof_enabled:1
30 changes_since_last_save:0
31 bgsave_in_progress:0
32 last_save_time:1348719252
33 bgrewriteaof_in_progress:1
34 total_connections_received:6
35 total_commands_processed:250313
36 expired_keys:0
37 evicted_keys:0
38 keyspace_hits:0
39 keyspace_misses:0
40 pubsub_channels:0
41 pubsub_patterns:0
42 latest_fork_usec:12217
43 vm_enabled:0
4445 aof_current_size:17908619
46 aof_base_size:16787337
47 aof_pending_rewrite:0
48 aof_buffer_length:0
49 aof_pending_bio_fsync:0
50 master_host:10.6.1.143
51 master_port:6379
5253 master_last_io_seconds_ago:0
54 master_sync_in_progress:0
55 slave_priority:100
56 db1:keys=250000,expires=0
master_link_status显示为up，同步状态正常。
在此次恢复的过程中，我们同时复制了AOF与RDB文件，那么到底是哪一个文件完成了数据的恢复呢？实际上，当Redis服务器挂掉时，重启时将按照以下优先级恢复数据到内存：1. 如果只配置AOF,重启时加载AOF文件恢复数据；2. 如果同时 配置了RDB和AOF,启动是只加载AOF文件恢复数据;3. 如果只配置RDB,启动是将加载dump文件恢复数据。
也就是说，AOF的优先级要高于RDB，这也很好理解，因为AOF本身对数据的完整性保障要高于RDB。
在此次的案例中，我们通过在Slave上启用了AOF与RDB来保障了数据，并恢复了Master。
但在我们目前的线上环境中，由于数据都设置有过期时间，采用AOF的方式会不太实用，过于频繁的写操作会使AOF文件增长到异常的庞大，大大超过了我们实际的数据量，这也会导致在进行数据恢复时耗用大量的时间。因此，可以在Slave上仅开启Snapshot来进行本地化，同时可以考虑将save中的频率调高一些或者调用一个计划任务来进行定期bgsave的快照存储，来尽可能的保障本地化数据的完整性。在这样的架构下，如果仅仅是Master挂掉，Slave完整，数据恢复可达到100%。如果Master与Slave同时挂掉的话，数据的恢复也可以达到一个可接受的程度。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
相关推荐
文章浏览阅读1.3k次。在 Redis 中，键（Keys）是非常重要的概念，它们代表了存储在数据库中的数据的标识符。对键的有效管理和操作是使用 Redis 数据库的关键一环，它直接影响到数据的存取效率、系统的稳定性和开发的便利性。本文将深入探讨 Redis 中键的管理和操作，包括键的命名规范、常用的键操作命令以及一些最佳实践。我们将详细介绍如何合理命名键、如何使用键的过期和持久化特性、如何批量删除键等技巧，旨在帮助读者更好地理解并灵活运用 Redis 中的键，从而提高数据管理和操作的效率和可靠性。
文章浏览阅读3.3k次，点赞44次，收藏88次。本篇是对单节点的应用，但从中我们也能推断出一些关于集群的应用，不过大多数公司能搞个主从就已经是不错了，所以你能学会这个已经算是很有用了，关于ES，博主前面也讲过一些基础应用，创建一个工具类利用ES的数据模型进行存储就可以达到一个canal同时对Redis和ES的同步，如果担心出问题，可以把Canal搞成集群的形式，这个后续有时间博主再给大家做讲解。今天就到这里了，觉得不错就支持一下吧。_canal redis
文章浏览阅读8.4k次，点赞8次，收藏18次。Spring Boot 整合Redis实现消息队列，RedisMessageListenerContainer的使用，Pub/Sub模式的优缺点_springboot redis 消息队列
文章浏览阅读978次，点赞25次，收藏21次。在Centos上安装Redis5.0保姆级教程！_centos7 安装redis5.0服务器
文章浏览阅读1.2k次，点赞21次，收藏22次。Docker-Compose部署Redis(v7.2)主从模式首先需要有一个redis主从集群，才能接着做redis哨兵模式。_warning: sentinel was not able to save the new configuration on disk!!!: dev
文章浏览阅读2.2k次，点赞59次，收藏38次。合理的JedisPool资源池参数设置能为业务使用Redis保驾护航，本文将对JedisPool的使用、资源池的参数进行详细说明，最后给出“最合理”配置。_jedispool资源池优化
文章浏览阅读1.9k次。批量删除指定前缀的Key有两中方法，一种是借助 redis-cli，另一种是通过 SCAN命令来遍历所有匹配前缀的 key，并使用 DEL命令逐个删除它们。_redis删除前缀的key
文章浏览阅读890次，点赞18次，收藏20次。1. Redis时一个key-cakye的数据库，key一般是String类型，不过value类型有很多。eg.String Hash List Set SortedSet (基本) | GEO BitMap HyperLog (特殊)2.Redis为了方便学习，将操作不同类型的命令做了分组，在官网可以进行查询。
文章浏览阅读1.1k次，点赞19次，收藏26次。若不使用Redisson，而是用synchronized(this)，此时会造成对服务器的加锁，若开始大量查询ID为1的商品，每台机器都会先跑一遍加个锁，然后在查询ID为2的数据，此时需要等待ID为1的锁释放，所以需要将this对象调整为全局商品ID。若在执行bgsave命令时，还有其他redis命令被执行(主线程数据修改)，此时会对数据做个副本，然后bgsave命令执行这个副本数据写入rdb文件，此时主线程还可以继续修改数据。在当前redis目录下会生成aof文件，对redis修改数据的命令进行备份。
文章浏览阅读1.5k次，点赞39次，收藏24次。本文全面剖析Redis集群在分布式环境下的数据一致性问题，从基础原理到高级特性，涵盖主从复制、哨兵模式、持久化策略等关键点，同时也分享了关于监控、故障模拟与自适应写一致性策略的实践经验。_redis集群一致性
文章浏览阅读1k次。RDB因为是二进制文件，在保存的时候体积也是比较小的，它恢复的比较快，但是它有可能会丢数据，我们通常在项目中也会使用AOF来恢复数据，虽然AOF恢复的速度慢一些，但是它丢数据的风险要小很多，在AOF文件中可以设置刷盘策略，我们当时设置的就是每秒批量写入一次命令。AOF的含义是追加文件，当redis操作写命令的时候，都会存储这个文件中，当redis实例宕机恢复数据的时候，会从这个文件中再次执行一遍命令来恢复数据。：在Redis中提供了两种数据持久化的方式：1、RDB 2、AOF。
文章浏览阅读1k次，点赞24次，收藏21次。NoSQL(No only SQL)数据库,泛指非关系型数据库,实现对于传统数据库而言的。NoSQL 不依赖业务逻辑方式进行存储,而以简单的 key-value 模式存储。因此大大增加了数据库的扩展能力。不遵循SQL标准不支持ACID远超于SQL的性能Redis是当前比较热门的NOSQL系统之一，它是一个开源的使用ANSI c语言编写的key-value存储系统（区别于MySQL的二维表格的形式存储。
文章浏览阅读988次，点赞17次，收藏19次。在上面的步骤中，我们已经开启了 MySQL 的远程访问功能，但是，如果使用 MySQL 管理工具 navicat 连接 MySQL 服务端时，还是可能会出现连接失败的情况。在实际工作中，如果我们需要从其他地方访问和管理 MySQL 数据库，就需要开启 MySQL 的远程访问功能并设置相应的权限。这对于我们的工作效率和数据安全都有很大的帮助。通过查看 MySQL 用户表，我们可以看到’host’为’%’，说明 root 用户登录 MySQL 的时候，可以允许任意的 IP 地址访问 MySQL 服务端。
文章浏览阅读956次。Redis Desktop Manager（RDM）是一款用于管理和操作Redis数据库的图形化界面工具。提供了简单易用的界面，使用户能够方便地执行各种Redis数据库操作，并且支持多个Redis服务器的连接_redisdesktopmanager安装包
文章浏览阅读1.9k次，点赞52次，收藏27次。缓存击穿指的是数据库有数据，缓存本应该也有数据，但是缓存过期了，Redis 这层流量防护屏障被击穿了，请求直奔数据库。缓存穿透指的是数据库本就没有这个数据，请求直奔数据库，缓存系统形同虚设。缓存雪崩指的是大量的热点数据无法在 Redis 缓存中处理（大面积热点数据缓存失效、Redis 宕机），流量全部打到数据库，导致数据库极大压力。
文章浏览阅读1.2k次。一次命令时间（borrow|return resource + Jedis执行命令(含网络) ）的平均耗时约为1ms，一个连接的QPS大约是1000，业务期望的QPS是50000，那么理论上需要的资源池大小是50000 / 1000 = 50个，实际maxTotal可以根据理论值合理进行微调。JedisPool默认的maxTotal=8，下面的代码从JedisPool中借了8次Jedis，但是没有归还，当第9次(jedisPool.getResource().ping())3、发生异常可能的情况。_redis.clients.jedis.exceptions.jedisconnectionexception: could not get a res
文章浏览阅读1k次，点赞27次，收藏18次。在这篇文章中，你将了解到如何在 CentOS 系统上安装 Redis 服务，并且掌握通过自定义域名来访问 Redis 服务的技巧。通过使用自定义域名，你可以方便地管理和访问你的 Redis 数据库，提高工作效率。无论你是开发者、系统管理员还是对 Redis 感兴趣的读者，这篇文章都会为你提供清晰的指导和实用的技巧。阅读本文，轻松搭建自己的 Redis 服务，并体验自定义域名带来的便捷！_redis怎么自定义域名
文章浏览阅读1.1k次，点赞15次，收藏18次。我们post请求,拦截器要预先读取HtppServletRequest里面的body的数据,是通过io的方式,都知道io读取完毕之后,之前的数据是变为null的，但是，当我么后面的接口来委派的时候,也是通过io读取body。我们要考虑一个事情，就是我们要验证数据的重复提交: 首先第一次提交的数据肯定是要被存储的，当而第二次往后,每次提交数据都会与之前的数据产生比对从而验证数据重复提交,我们要具体判断数据是否重复提交的子类。发现数据是成功存入的,剩余7s过期,在10s之内,也就是数据没过期之前，在发送一次。_json.parseobject(str, clazz, auto_type_filter);
文章浏览阅读3.9k次，点赞3次，收藏7次。PHP使用Redis实战实录系列：我们首先检查$redis->connect()方法的返回值来确定是否成功连接到Redis服务器。如果连接失败，我们可以输出相应的错误信息。如果连接成功，我们再执行一些操作，如$redis->set()、$redis->get()等，并检查每个操作的返回结果来判断是否发生了异常。_php redis
文章浏览阅读1.5w次，点赞23次，收藏51次。Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。Redis 是一个高性能的key-value数据库。redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。_redisdesktopmanager下载
