Redis

最新推荐文章于 2023-12-14 08:57:11 发布

一只大马猴呀

最新推荐文章于 2023-12-14 08:57:11 发布

阅读量725

点赞数

文章标签： sql 数据库 database

本文链接：https://blog.csdn.net/weixin_59096287/article/details/121426210

版权

概述

Redis是一个key-value存储系统（官网：http://redis.io），是一个分布式缓存数据库。

背景

我们现在的项目架构中，基本上是Web服务器(Tomcat)和数据库独立部署，独占服务器资源，随着用户数的增长，并发读写数据库，会加大数据库访问压力，导致性能的下降，严重时直接导致系统宕机，例如

启动redis服务

Docker 环境下的启动(docker环境启动多个需要运行多个容器)：

docker start redis01 #底层也是通过redis-server启动，start单词后的redis01为容器名

Redis数据存储操作

简易数据存取

基于查看redis中的key

127.0.0.1:6379> keys *
(empty list or set)

基于key/value形式存储数据

127.0.0.1:6379> set test1 123
OK
127.0.0.1:6379> set test2 ab
OK
127.0.0.1:6379> keys *
1) "test1"
2) "test2"

基于key获取redis中存储的数据

127.0.0.1:6379> get test1
"123"
127.0.0.1:6379> get test2
"ab"
127.0.0.1:6379> get test3
(nil)
127.0.0.1:6379>

清除redis中的数据

清除当前数据库数据

127.0.0.1:6379> flushdb
OK

清除所有数据库数据

127.0.0.1:6379> flushall
OK

Redis 数据持久化实践

持久化方式

Redis中为了保证在系统宕机(类似进程被杀死)情况下，能更快的进行故障恢复，设计了两种数据持久化方案，分别为rdb和aof方式。

Rdb方式持久化

概述

Rdb方式是通过手动(save-阻塞式，bgsave-异步)或周期性方式保存redis中key/value的一种机制,Rdb方式一般为redis的默认数据持久化方式.系统启动时会自动开启这种方式的持久化机制。

Redis中的save和bgsave有什么不同？

Redis Save 命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。
BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。

RDB持久化机制有哪些优点？

第一：RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据.
第二：RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
第三：相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速。

RDB持久化机制有哪些缺点？

假如redis故障时，要尽可能少的丢失数据，那么RDB方式不太好，它都是每隔5分钟或更长时间做一次快照，这个时候一旦redis进程宕机，那么会丢失最近几分钟的数据。

Aof方式数据持久化

概述

Aof方式是通过记录写操作日志的方式,记录redis数据的一种持久化机制,这个机制默认是关闭的。

AOF持久化机制有哪些优点？

第一：AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据.
第二：AOF日志文件通常以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，并且文件不容易破损，即使文件尾部破损，也很容易修复。
第三：AOF日志文件过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的日志进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
第四：AOF日志文件的命令通过易读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据.

AOF持久化机制有哪些缺点？

第一：对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。
第二：AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。
第三：AOF这种基于命令日志方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。

如何选择redis的持久化方式？

第一：不要仅仅使用RDB，因为那样会导致你丢失很多数据。
第二：也不要仅仅使用AOF，因为AOF做冷备没有RDB做冷备进行数据恢复的速度快,并且RDB简单粗暴的数据快照方式更加健壮。
第三：综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备。