Redis相关学习

最新推荐文章于 2025-05-28 15:51:16 发布

新手程序员畅宇啸

最新推荐文章于 2025-05-28 15:51:16 发布

阅读量126

点赞数

分类专栏： Redis 文章标签： java

本文链接：https://blog.youkuaiyun.com/m0_49976286/article/details/108957441

版权

Redis 专栏收录该内容

1 篇文章

订阅专栏

1.Redis（REmote DIctionary Server）介绍

是用C语言开发的一个开源的高性能键值对（key-value）（非关系型）数据库
特征:

数据间没有必然的关联关系
内部采用单线程机制进行工作
高性能
支持多种数据类型
- string（字符串）、
- list（列表）、
- hash（哈希）、
- set（集合）、
- sorted_set（有序集合）
支持持久化

2.jedis介绍和使用

jedis是java操作redis的一种工具
1）配置pom.xml文件

<dependency>
 <groupId>redis.clients</groupId>
 <artifactId>jedis</artifactId>
 <version>2.9.0</version>
</dependency>

2）代码流程

连接redis
//配置域名跟端口号
Jedis jedis = new Jedis(“127.0.0.1”, 6379);
操作redis
//对数据进行操作，（存入取出什么的）
jedis.set(“name”, “cyx”);
jedis.get(“name”);
关闭redis连接
jedis.close();

Jedis的API文档: http://xetorthio.github.io/jedis/.

3.Linux操作Redis

3.1基于Center OS7安装Redis

下载安装包的指令
wget http://download.redis.io/releases/redis-版本号.tar.gz
解压的指令
tar –xvf 文件名.tar.gz
编译的指令
make
安装的指令
make install [destdir=/目录名]

3.2Redis基础环境设置

创建软链接
ln -s 原始目录名快速访问目录名
创建配置文件管理目录
mkdir conf
mkdir config
创建数据文件管理目录
mkdir data

3.3Redis服务启动

默认配置启动
redis-server
redis-server –-port 6379
redis-server –-port 6380 ……
指定配置文件启动
redis-server redis.conf
redis-server redis-6379.conf
redis-server redis-6380.conf ……
redis-server conf/redis-6379.conf
redis-server config/redis-6380.conf ……

3.4Redis客户端连接

默认连接
redis-cli
连接指定服务器
redis-cli -h 127.0.0.1
redis-cli –port 6379
redis-cli -h 127.0.0.1 –port 6379

3.5Redis服务端配置

基本配置
daemonize yes

以守护进程方式启动，使用本启动方式，redis将以服务的形式存在，日志将不再打印到命令窗口中

port 6379

设定当前服务启动端口号
dir “/自定义目录/redis/data“
设定当前服务文件保存位置，包含日志文件、持久化文件（后面详细讲解）等

logfile “6379.log”

设定日志文件名，便于查阅

4.Redis的持久化的方式

4.1RDB（快照形式）

将当前的数据以二进制的形式保存。

操作方式A使用save命令
每保存一次生成一个.rdb文件
作用:手动执行一次保存操作
save指令的相关配置（虚拟机）

1） dbfilename dump.rdb
说明：设置本地数据库文件名，默认值为 dump.rdb
经验：通常设置为dump-端口号.rdb
2） dir
说明：设置存储.rdb文件的路径
经验：通常设置成存储空间较大的目录中，目录名称data
3） rdbcompression —> yes
说明：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF 压缩
经验：通常默认为开启状态，如果设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）
4） rdbchecksum —>yes
说明：设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行
经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险

save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。

操作命令B使用bgsave命令
作用:手动启动后台保存操作，但不是立即执行

流程 :
1）执行bgsave命令，redis返回一条消息Background saving started（但是不一定立刻执行）
2）什么时候执行，在返回消息的时候抽空调用Linux的fork函数生成一个子进程，由它创建一个rdb文件，来处理（完成）这件事
3）然后，返回一个消息（日志文件中）Background saving terminated with success

bgsave的配置除了save的四个文件外，还要配置stop-writes-on-bgsave-error —> yes

作用 : 后台存储过程中如果出现错误现象，是否停止保存操作，默认为开启状态

bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。

操作方式C使用save配置（自动化出发RDB持久化的方式）

配置方式
save second changes（使用的是bgsave）
作用
满足限定时间范围内key的变化数量达到指定数量即进行持久化
参数
second：监控时间范围
changes：监控key的变化量
位置
在conf文件中进行配置

rdb特殊启动形式
1）全量复制
2）服务器运行过程中重启
debug reload
3）关闭服务器时指定保存数据
shutdown save

默认情况下执行shutdown命令时，自动执行
bgsave(如果没有开启AOF持久化功能)

RDB的优缺点

RDB优点
1) RDB是一个紧凑压缩的二进制文件，存储效率较高
2) RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
3) RDB恢复数据的速度要比AOF快很多
4) 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

Rdb缺点
1) RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
2) bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
3) Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

4.2AOF（日志形式）

将数据的操作过程保存下来

4.2.1AOF功能开启

配置
appendonly yes/no

默认是no
作用 : 是否开启AOF持久化功能，默认为不开启状态

配置
appendfsync always/everysec/no

作用 : AOF写数据策略
AOF写数据三种策略(appendfsync)
1） always(每次）
每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用。
2） everysec（每秒）
每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高，建议使用，也是默认配置
在系统突然宕机的情况下丢失1秒内的数据
3） no（系统控制）
由操作系统控制每次同步到AOF文件的周期，整体过程不可控

4.2.2AOF相关配置

配置appendfilename filename
- 作用AOF持久化文件名，默认文件名未appendonly.aof，建议配置为appendonly-端口号.aof
配置dir
- 作用AOF持久化文件保存路径，与RDB持久化文件保持一致即

5.Redis出现的缓存三大问题

5.1缓存穿透

key对应的数据并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据库去找，从而可能压垮数据库。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

5.1.1缓存穿透的解决方法

方式①采用布隆过滤器，将可能出现问题的数据存储到一个集合內，将其拦截掉

方式②如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），仍然把这个空结果进行缓存，然后给它设置一个失效时间

5.2缓存击穿

key对应的数据存在，但在redis中过期（查询不到），此时若有大量并发请求过来，这些请求发现缓存过期（中没有，）一般都会前往后端数据库加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端数据库压垮。

5.2.1缓存击穿的解决方法

设置value永不过期

使用互斥锁。在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果。

5.3缓存雪崩

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

5.3.1缓存雪崩的解决方法

给每个key设置不同的失效时间，避免

6.Redis集群

何为集群？
集群就是通过增加服务器的数量，提供相同的服务，从而让服务器更加稳定，高效。

6.1为什么要使用redis集群

若单个redis宕机了，就没服务可用了，而且单个redis的读写能力也是有限的。redis可以强化redis的读写能力。

6.2Redis的介绍

1）在redis集群中，每个redis都是一个节点
2）节点分为主节点和从节点
3）redis集群基于redis的主从复制

6.2Redis的主从复制

主从复制模型中，有多个redis节点。
其中，有且仅有一个为主节点Master。从节点Slave可以有多个。

6.2.1主从复制的特点

特点
（1）主节点Master可读、可写.
（2）从节点Slave只读。（read-only）

因此，主从模型可以提高读的能力，在一定程度上缓解了写的能力。因为能写仍然只有Master节点一个，可以将读的操作全部移交到从节点上，变相提高了写能力。

6.3Redis的哨兵模式

当主节点宕机了，整个集群就没有可写的节点了。这时候，通过哨兵机制，将一个从节点（从节点上备份了主节点的所有数据）变成了主节点。

6.3.1Redis哨兵模式的三个任务

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance），该系统执行以下三个任务：

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作，它会进行选举，将其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器