Redis详解：内存数据库、持久化与集群应用-CSDN博客

本文链接：https://blog.csdn.net/zbyyym/article/details/129820901

本文详细介绍了Redis，一个高性能的内存数据存储系统，支持多种数据结构如键值对、列表、集合等。Redis利用单线程模型实现高效操作，并提供了RDB和AOF两种持久化策略确保数据安全。此外，文章讨论了NoSQL的特点和Redis的适用场景，包括缓存、发布订阅、地理位置分析等。同时，文中深入探讨了Redis的线程模型、事务处理、数据类型及其操作，如String、List、Set等，并提到了位图、HyperLogLog等高级特性的应用。最后，文章讲解了Redis的持久化策略、AOF重写机制和发布订阅功能，以及如何通过主从复制构建高可用的Redis集群。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1.1.1redis介绍

Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。从2013年5月开始，Redis的开发由Pivotal赞助。

redis能做什么？

1. 内存存储，持久化，断电即丢失，所以持久化很重要，redis采用两种机制（RDB和AOF）

2. 效率高，可以用于高速缓存

3. 发布订阅系统

4. 地图信息分析

5. 计数器等，网站浏览量

redis特点/特性

1. 多样的数据类型

2. 持久化

3. 集群

4. 事务等...

1.1.2NoSQL特点

扩展方便，数据与数据之间没有必然联系，0耦合。

大数据量和高性能（redis => 单秒写10万次读取11万次） QPS

数据类型的多样化（5+3） String、List、Set、Hash、Zset | geo(地理位置信息) 、hyperloglog（访客信息）、bitmap 位图(常用计算活跃粉丝和不活跃粉丝、登录和未登录、是否打卡等)

不需要提前设计数据库，随取随用。

1.1.3NoSQL的四大类

KV类型

- 新浪 redis

- 美团 Redis + Tair

- 阿里、百度 redis + memcached

档类型数据库(BSON 和 JSON一样)- MongoDB (目前企业需求也是比较大的) 是一个给予分布式存储的数据库，主要用于处理大量的文档，是一个介于关系型和非关系型数据库的中间产品，本身属于非关系型。

列存储的数据库

- 大数据的HBase

- 分布式文件系统(一个业务分拆多个子业务，部署在不同的服务器上)

图形关系数据库

- 图示 - 存储的是图形关系，类似与朋友圈或社交平台

- Neo4J InfoGrid

1.1.4关于redis线程问题

redis的单线程的，那么单线程为什么还这么快？

Redis 的数据结构并不全是简单的 Key-Value，还有 list，hash 等复杂的结构。这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在 hash 当中添加或者删除一个对象。这些操作可能就需要加非常多的锁，导致的结果是同步开销大大增加。

总之，在单线程的情况下，代码更清晰，处理逻辑更简单，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗，不存在多进程或者多线程导致的切换而消耗 CPU。

单线程多进程的集群方案

单线程的威力实际上非常强大，每核效率也非常高。多线程自然是可以比单线程有更高的性能上限，但是在今天的计算环境中，即使是单机多线程的上限也往往不能满足需要了，需要进一步摸索的是多服务器集群化的方案，这些方案中多线程的技术照样是用不上的。所以单线程、多进程的集群不失为一个时髦的解决方案。

CPU 消耗

采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU。但是如果 CPU 成为 Redis 瓶颈，或者不想让服务器其他 CPU 核闲置，那怎么办？

可以考虑多起几个 Redis 进程，Redis 是 key-value 数据库，不是关系数据库，数据之间没有约束。只要客户端分清哪些 key 放在哪个 Redis 进程上就可以了。

2.1redis 基础命令

2.1.1数据库切换操作

2.1.2 查看当前数据库

2.1.3清除数据库中的数据

flushdb 删除当前库 -- 前提进入当前数据库中

flushall 删除所有库

2.1.4设置过期时间

2.1.5查看key类型

type key

2.1.6 查看key是否存在

EXISTS key

3.1redis数据类型

redis存在5种基本数据类型和三种特殊类型

3.1.2String类型

例举：分布式锁、Session相关、验证码相关、计数相关(点击量/阅读量/关注)等单一的值。

3.1.3取值赋值

关键词：set get append strlen

3.1.4加减操作

increment 自增1 decrement 自减

incrby 固定增量自定义

decrby 固定减量自定义

3.1.5范围操作 range

getrange key index1 index2 获取当前指定范围如果最大长度 index2 可替为-1

3.1.6替换操作

setrange key offset index 内容 ##offset 偏移量指定位置开始替换

3.1.7判断是否存在

EXISTS t6 判断值是否存在

#set with expire #如果存在设置消失时间及信息值 -- 订单

setex key time v 既能增加过期时间还能够重新指定新的值，如果当前key不存在创建一个新的key和值并指定过期时间

#set if not expire #如果不存在默认会创建一个新的，存在不操作 ///// 及判断存在不存在同时也能根据结果进行进一步操作 setnx key v

3.1.8批量值操作

more set

mset k1 v1 k2 v2

mget k1 k2

3.1.9关于对象的存储

3.2.1取值赋值操作

getset 先取值，再赋值

3.2.2关于浮点类型的增减操作

3.2.3删除数据

del key ...

4.1.1List列表类型

list列表类型，特点：所有的命令操作都是使用l开始。和链表/队列比较相似，可以通过首尾进行操作。

4.1.2基本赋值和取值操作

保留案例：导航信息存储

默认左侧插入值： lpush l意思 list

右侧插入值：rpush r意思 right

查询数据：lrange key start end

获取长度 llen key

2 list结构的删除数据操作

4.1.4索引相关 index

通过索引获取数据 lindex key index

127.0.0.1:6379> lindex stu 1

截取列表中一部分值

trim 在Java和脚本中是去掉前后空格，本身意思修剪、整理。在redis中作用域截取部分值，截取完成只保留获取的内容

5.1.1Set集合类型

特点：无序、不能重复所有命令 s 开头

用途：点赞，签到，like等功能、抽奖功能

5.1.2基本操作

添加值 sadd key v......

查询值 smembers members 成员组成

通用删除 del key 将整个集合直接删除

删除指定指定的元素 srem key value

5.1.3其他操作

判断当前集合中是否存在指定的值 s is member 是否是成员

语法 sismember key v

查看当前集合中值个数 s card

语法：sacrd key

随机获取和随机删除

随机获取： srandmember [ s random member ]

语法：srandmember key count

随机删除： spop

语法： spop key count

5.1.4特殊操作

解决中文问题

差集 diff 差异只返回第一个集合的差值

交集 sinter 交集

并集 s union 联盟工会 ---- 去重复

6.1.1 Hash类型（map结构）

key-value（map）比较适合对象类型的数据存储 key -（key-value）

6.1.2基础语法

存值(key (key - value))

语法： hset key k1 v1 k2 v2 k3 v3

hget key k -- 获取单个值

6.1.3其他用法

判断是否存在

读取所有的key ----- 1w条数据取某一些特定的数据，取到所有key 循环取值判断筛选。

取所有的value --- 案例：Java中想将redis中的hash结构转化为set结构

7.1.1Zset

有序不重复集合，在set的基础上多增加一个值 set k1 * v1 (zset k1 排序的值(score) v1)

有序不可重复的set集合

主要使用方向：工资、班级成绩等等之类的数据。或者权重处理 0 普通 1 重要

7.1.2基本语法

增加和查询

删除数据

删除整个key del key

7.1.3zset 复杂查询

#显示所有信息，从小到大（范围） -inf 负无穷 +inf正无穷

语法：** z range by score** key min max --- min max使用的是排序字段的值

升序操作

降序操作

z rev range k start stop start stop取索引的范围。

8.1.1geospatial 地理位置

作用：朋友圈定位，附近的人，打车距离计算。

添加地理位置信息 GEOADD

geoadd key 精度纬度名称

查询指定位置的经纬度 GEOPOS

查询两地点之间的距离

GEODIST geodist key 地点1 地点2 单位(默认米)

查询附近的城市（定位） GEORADIUS

查询附近的城市（定位）--显示到中间的距离 GEORADIUS

关键词： withdist

查询附近的城市（定位）--显示他人精准信息 GEORADIUS

关键词：withcoord

查询附近的城市（定位）--显示他人精准信息并指定返回个数 GEORADIUS

关键词： count

8.1.2HyperLogLog基数统计

Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64(long类型的最大值) 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素

什么是基数?

比如数据集 {1, 3, 5, 7, 5, 7, 8}，那么这个数据集的基数集为 {1, 3, 5 ,7, 8}, 基数重复元素为5（个数）。基数(不估计就是在误差可接受的范围内，快速计算基数。

8.1.3Bitmaps位图

1Byte=8bit(比特) 1KB=1024Byte(字节)=8*1024bit 1MB=1024KB 1GB=1024MB 1TB=1024GB 1PB=1024TB 位存储：给大家举个例子，比如中国有14亿人口，那么我们用位图中使用0表示每一个人 127.0.0.1:6379> pfadd clazz zhangsan lisi wangwu zhaoliu tianqi 99 2111 99.9 1 127.0.0.1:6379> pfadd clazz zhangsan lisi wangwu zhaoliu 0 127.0.0.1:6379> pfadd clazz zhangsan lisi wangwu zhaoliu 33 1 127.0.0.1:6379> pfcount clazz 11 127.0.0.1:6379> pfadd stu xiongda xionger zhangsan 1 127.0.0.1:6379> pfmerge clazz stu OK 127.0.0.1:6379> pfcount clazz 11 127.0.0.1:6379> pfcount stu 3 0 0 0 0 0 0 x 14亿 ,这种数据其实即使是14亿占用内存也是不多的，那么接下来我们使用位图表示当前疫情下哪些人被感染了，那么我们就可以将位图更改为 0 1 0 0 1 0 x 14亿 . 我们就能通过 0 和 1 判断没有感染的和传染人的数量。在我们日常的开发过程中，位图经常用作于统计用户活跃or不活跃、登录or未登陆、上班族一年的打卡记录，只要有两个状态的都可以使用位图计算。案例:是否打卡（一周） 0 未打卡 1 打卡一年为例 365 = 365bit 1字节=8bit 约46字节左右。

首先增加基础数据 setbit

统计打卡的天数 bitcount

9.1.1redis事务

理论

redis 事务可以一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。redis事务没有隔离级别的概念，所以不会出现脏读、幻读、不可重复读，因为队列就有序列化的概念，你可以认为默认就是MySQL 序列化级别。

redis采用了乐观锁方式进行事务控制，它使用watch命令监视给定的key，当exec（提交事务）时候如果监视的key从调用watch后发生过变化，则整个事务会失败。也可以调用watch多次监视多个key。注意watch的 key是对整个连接有效的，如果连接断开，监视和事务都会被自动清除。当然exec，discard，unwatch命令都会清除连接中的所有监视。

redis保证一个事务中的所有命令要么都执行，要么都不执行。如果在发送EXEC命令前客户端断线了，则 Redis会清空事务队列，事务中的所有命令都不会执行。而一旦客户端发送了EXEC命令，所有的命令就都会被执行，即使此后客户端断线也没关系，因为Redis中已经记录了所有要执行的命令。 -------前面话述中看似 redis是能够保证原子性，但是保证原子性是有特殊的前提的，首先单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。可能有人问redis 因为使用watch命令监视再加上乐观锁应该能保证原子性了，但实际事务执行过程中因为编译(命令)导致的错误可以保证原子性（出现的概率极低）多线程出现干扰问题，但是运行的错误(命令正确，但是结果出错误) 就不能够保证原子性了。实操部分会给大家演示。

实践

事务从开始到执行会经历以下三个阶段：

1. 开始事务(MULTI)

2. 命令入队(输出queued)

3. 执行事务(EXEC) / 取消事务(DISCARD)

9.1.2标准事务执行 EXEC

9.1.3放弃事务执行DISCARD

在关系型数据库中，之所以有回滚的方法是因为在事务执行的过程中（增加）在commit之前已经操作了数据库，那么一旦出现问题，我们必须提供一个回滚的方法来回到最初的状态。 --- 占ID

reids中，我们执行的命令都在队列中(没有执行)，所以就没有回滚的概念，此时你只要放弃提交（取消执行），那么数据就是最初状态了。

9.1.4redis事务保证原子性测试

redis事务中执行编译错误(命令错误)是保证原子性的，但是redis运行错误（命令正确，但是结果出错误），事务是不保证原子性的。相当于Java中两种异常状态编译异常运行异常1/0

redis事务不保证原子性测试

9.1.5测试redis乐观锁

redis默认使用的是乐观锁保证事务原子性。

悲观锁：认为什么时候都会出问题，无论做什么都需要加锁。synchronized -- 特别消耗性能

乐观锁：认为什么时候都不会出现问题，所以不会上锁，但是执行的时候会经过判断是否有修改， MySQL中使用version判断，正确提交，错误不提交。

redis 中通过 Watch监视器实现

正常执行

异常执行案例

关于废弃锁处理

9.1.6性能测试

测试1

redis启动后进入到bin目录中，执行以下命令进行性能测试：

说明：因为测试的是本机的redis性能，所以没有指定IP和端口号。

-t：表示执行以逗号分隔的命令，执行的是set操作和get操作，如果不指定具体的值，测试的结果较多

执行结果如下：

测试2

在实际生产中，我们需要关心在应用场景中，redis能够处理的QPS是多少。我们需要估计生产的报文大小，使用benchmark工具指定-d数据块大小来模拟：

指定并发数为100，数据大小为2048字节，在实际生产中，每个业务处理的数据大小不一致，取出一个最大的数据为基数进行测试即可，在程序里将数据的字节大小打印出来，使用redis-benchmark的-d参数指定数据大小。

执行结果：

信息检测

使用redis客户端登录到redis服务中，执行info命令查看redis的信息

10.1.1redis持久化

理论

前面我们说过，Redis 相对于 Memcache 等其他的缓存产品，有一个比较明显的优势就是 Redis 不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。这几种丰富的数据类型我们接下来我们要介绍 Redis 的另外一大优势——持久化。

由于 Redis 是一个内存数据库，所谓内存数据库，就是将数据库中的内容保存在内存中，这与传统的MySQL，Oracle等关系型数据库直接将内容保存到硬盘中相比，内存数据库的读写效率比传统数据库要快的多（内存的读写效率远远大于硬盘的读写效率）。但是保存在内存中也随之带来了一个缺点，一旦断电或者宕机，那么内存数据库中的数据将会全部丢失。

为了解决这个缺点，Redis提供了将内存数据持久化到硬盘，以及用持久化文件来恢复数据库数据的功能。 Redis 支持两种形式的持久化，一种是RDB快照（snapshotting），另外一种是AOF（append-only-file）

10.1.2RDB快照（redis DateBase）

概述

RDB是Redis用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里。

触发方式

RDB 有两种触发方式，分别是自动触发和手动触发。

自动触发

save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如 “save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave（这个命令下面会介绍，手动触发RDB持久化的命令）。

rdbcompression ：默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话， redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。

stop-writes-on-bgsave-error ：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了。

rdbchecksum ：默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

dbfilename ：设置快照的文件名，默认是 dump.rdb

dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。默认是和当前配置文件保存在同一目录

测试自动触发

1 添加数据测试，查找数据库文件

2 改变文件名称

3 查看快照路径

手动触发

手动触发Redis进行RDB持久化的命令有两种：

save：该命令会阻塞当前Redis服务器，执行save命令期间，redis不能处理其他命令，直到RDB过程完成为止。显然该命令对于内存比较大的实例会造成长时间阻塞，这是致命的缺陷，为了解决此问题，redis提供了第二种方式。(不建议使用)

bgsave：执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是 Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在创建子进程fork阶段，一般时间很短。

基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。

还有两种特殊的操作也能触发RDB的持久化，但是因为情况特殊，所以不作为手动触发条件

# 执行执行 flushall.flushdb 命令，也会产生dump.rdb文件，但里面是空的，无意义

# 关闭redis 服务同样会生成 --- 规则使用 bgsave 保存数

10.1.3RDB数据恢复(企业管理者经常用的手段)

将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis就会自动加载文件数据至内存了。 Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。启动服务器的当前目录一定是redis-*** 否则快照生成的路径就会发生错误！

停止 RDB 持久化

有些情况下，我们只想利用Redis的缓存功能，并不像使用 Redis 的持久化功能，那么这时候我们最好停掉 RDB 持久化。可以通过上面讲的在配置文件 redis.conf 中，可以注释掉所有的 save 行来停用保存功能或者直接一个空字符串来实现停用：save ""

11.1.1AOF

概述

Redis的持久化方式之一RDB是通过保存数据库中的键值对来记录数据库的状态。而另一种持久化方式 AOF 则是通过保存Redis服务器所执行的写命令来记录数据库状态。

AOF以协议文本的方式，将所有对数据库进行写入的命令（及其参数）记录到 AOF 文件，以此达到记录数据库状态的目的。

用日志的形式来记录每个操作，将redis执行过的所有的指令都记录下来(读操作不记录)，只许追加文件但不可以写文件，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次，已完成数据文件的恢复工作

AOF配置

appendonly：默认值为no，也就是说redis 默认使用的是rdb方式持久化，如果想要开启 AOF 持久化方式，需要将appendonly 修改为 yes。

appendfilename ：aof文件名，默认是"appendonly.aof"

appendfsync**：**aof持久化策略的配置；

1. no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全；

2. always表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低；

3. everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。通常选择 everysec ，兼顾安全性和效率。(默认)

no-appendfsync-on-rewrite：在aof重写或者写入aof文件的时候，会执行大量IO，此时对于everysec和 always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。默认值为no。

auto-aof-rewrite-percentage：默认值为100。aof自动重写配置，当目前aof文件大小超过上一次重写的 aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候，Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。 64M - 40M - 80M(55M) - 110M(70M)

auto-aof-rewrite-min-size：64mb。设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。

aof-load-truncated：aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，出现这种现象 redis宕机或者异常终止不会造成尾部不完整现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。默认值为 yes。

开启AOF

默认不开启，需要手动开启 - AOF和RDB同时开启，默认走AOF策略

appendonly yes

注意配置完成后重启redis，并set几个值，# vim查看aof文件

AOF文件故障修复

关闭redis

删除dump.rdb

随便修改点aof文件

重新启动redis

AOF文件重写机制

AOF 文件包含三类文件：基本文件、增量文件与清单文件。其中基本文件一般为 rdb 格式，就是 rdb 持久化的数据文件。

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令 bgrewriteaof 来重写。