SpringCloud（13）— 分布式缓存(Redis集群)

分布式缓存(Redis集群)

前言 单节点Redis的问题

1.数据丢失

Redis基于内存存储，服务器重启可能会导致数据丢失

2.并发能力

单节点Redis的并发能力虽然已经很不错，但是依然无法满足大型的高并发场景

3.故障恢复

如果Redis宕机，则服务将不可用。因此需要一种自动的故障恢复手段

4.存储能力

Redis基于内存，单节点存储的数据量有限，难以满足海量数据的需求

5.解决Redis问题的方案

一 搭建单节点Redis

1.使用安装包搭建单节点

先下载 Redisan安装包，笔者编辑此文档时，最新版为redis-6.0.6.tar.gz，下载完成之后将安装包放置在虚拟机或服务器的指定位置下。

#1.安装依赖
yum install -y gcc tcl
#2.解压文件
tar -xvf redis-6.0.6.tar.gz
#3.进入redis文件目录
cd /redis-6.0.6
#4.编译安装
make && make install

安装过程中出现以下错误时，可以按照以下方案解决

‘struct redisServer’ has no member named ‘sentinel_mode’
         if (server.sentinel_mode && configfile && *configfile == '-')

解决方案：Redis: 部署redis6.0.6 出现问题_天黑请赶路的博客-优快云博客

处理完成以后，重新运行make && make install命令即可完成安装

2.Docker搭建单节点 Redis

使用Docker创建一个Redis容器并且运行即可

docker run --name myredis \
            -v /usr/local/redis:/usr/local/etc/redis \
            -p 6379:6379 \
            -d redis:latest \
            redis-server /usr/local/etc/redis/redis.conf

• -v：挂载自己的redis配置文件目录到容器指定目录
• -p：对外映射访问端口
• redis-server /usr/local/etc/redis/redis.conf：指定要使用的redis.conf

更多用法参考DockerHub：redis - Official Image | Docker Hub

踩坑点：redis.conf文件需要手动创建

Redis及配置文件下载地址：redis下载 – Redis中国用户组（CRUG）

二 Redis持久化

1.RDB持久化

1.RDB基础

RDB全称为Redis Database Backup file（Redis数据备份文件），也叫作Redis数据快照。

简单来说就是把内存中的所有数据都记录到磁盘中，当Redis实例故障后，从磁盘读取快照文件，恢复数据。

2.RDB存储

RDB存储方式默认由Redis开启

快照文件称之为RDB文件，默认保存在当前运行目录。

通过 save命令来实现RDB持久化,该命令由Redis主进程来执行，会阻塞所有命令。

使用save保存数据，当数据过大时，会导致其他线程无法访问Redis，缺点尤为明显

这里推荐使用bgsave命令，使用后台保存命令。该命令是在后台异步执行的，且由子进程执行RDB，不会造成主进程的阻塞。

注意：Redis停机时会自动执行一次RDB

Redis内部有触发RDB的机制，可以在 redis.conf 文件夹中找到。其中关于RDB的默认配置如下：

# 含义：900s内如果有1个key被修改，则执行 bgsave,其他行同理。
# 如果是 save "" 则表示删除所有的保存点。
# 禁用所有 save 表示完全禁用 RDB
#   save ""
save 900 1
save 300 10
save 60 10000

#其他配置信息
#是否压缩
rdbcompression yes
#是否校验和
rdbchecksum yes
#压缩文件名称
dbfilename dump.rdb
#是否删除非持久性实例中的rdb文件
rdb-del-sync-files no
#RDB文件保存位置，默认为当前目录
dir ./

3.RDB原理

bgsave命令开始执行时，会 fork 主进程得到子进程，子进程共享主进程的内存数据。

完成 fork 后读取内存数据并写入RDB文件中。

fork 底层采用了 copy-on-write 技术：

• 当主进程执行读操作时，访问共享内存
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作

整体流程：

1. fork主进程得到一个子进程，共享内存空间
2. 子进程读取内存数据并且写入RDB文件
3. 使用新的RDB文件替换旧的RDB文件

RDB的缺点：

• RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险
• fork子进程，压缩，写入RDB文件都比较耗时

2.AOF持久化

1.AOF基础

AOF全称为Append Only FIle（追加文件）。Redis处理的每一个命令都会记录在AOF中，可以看做是命令日志文件。

2.AOF存储

AOF默认是关闭状态，需要修改redis.conf配置文件开开启AOF：

#是否开启AOF功能，默认为 no
appendonly yes

#AOF文件默认名称
appendfilename "appendonly.aof"

# AOF文件记录频率，Redis提供了三种方案，分别是 always,everysec,no
appendfsync everysec

• everysec：写命令执行完先放入缓冲区，然后每隔1秒将缓冲区的数据写到AOF文件，是默认方案。牺牲一定的可靠性，但性能较好
• no：写命令执行完先放入缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。性能最好，但是安全性最差
• always：每执行一次写命令，立即记录到AOF文件，数据得到绝对的安全保障，但是性能最差
  

3.存储示例

注意：Redis的RDB和AOF可以共同存在，一起保障数据的安全

修改redis.conf的关键配置如下：

# 注释掉所有 save 行，开启 AOF 存储
appendonly yes

重启Redis服务，此时默认目录下会生成 appendonlydir 文件，真对于 redis 的操作记录，全都记录在这个文件夹中。

# 进入 redis 容器内部
docker exec -it myredis bash
# 查看当前目录下的文件
ls
# 利用redis-cli工具操作redis,并且存储一个String数据
set name tony;

其中 /appendonlydir/appendonly.aof.1.incr.aof中就保存着我们操作redis的记录。

使用 cat 命令查看文件内容

# 切换至 appendonlydir 目录下
cd /appendonlydir
# 查看文件内容
cat appendonly.aof.1.incr.aof

${num}表示输入命令的字符串长度，例如 $6 表示输入了一个长度为 6 的信息。

以上文件内容表示执行了以下Redis 命令：

# 选择 0 号库
select 0
# 存储一个key=name,value=tony的字符串数据
set name tony

因为是记录命令，AOF文件会比RDB文件大很多。而且对同一个key的多次操作，只有最后一次才有意义。这样一来就存储了很多无用的数据。

通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同的效果。

bgrewriteaof

自动重写功能默认为开启状态，我们可以通过配置文件，设置触发自动重写的条件：

# 相比上次文件大小，超过指定百分比则触发重写
auto-aof-rewrite-percentage 100
# aof文件的大小达到指定大小时开始触发重写
auto-aof-rewrite-min-size 64mb

3.持久化模式对比

实际生产环境下往往采用两者结合的方式来使用。

三 Redis主从

单节点Redis的并发能力是有上线的，要进一步提高Redis的并发能力，就需要搭建主从架构，实现读写分离。

在一台服务器上开启多个端口，模拟实现搭建Redis主从架构。

1.搭建Redis主从架构

创建3个文件目录，使得它们分别去运行，彼此之间互不干扰

mkdir 7001 7002 7003

准备一份原始的redis配置文件redis.conf，然后将它复制3份，分别放在3个文件夹下面

可以通过 查找，获取到刚才安装的Redis的配置文件，恢复至原始状态，然后将其复制到创建的3个目录下,

find / -name redis.conf