Redis操作实践

编程入门 行业动态 更新时间:2024-10-09 02:26:09

Redis<a href=https://www.elefans.com/category/jswz/34/1770947.html style=操作实践"/>

Redis操作实践

目录

一、数据持久化

RDB方式

AOF方式

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

二、事物处理 

常用指令

三、框架设计 

主从复制

哨兵模式

集群模式


一、数据持久化

Redis是一种内存数据库,在断电时数据可能会丢失。为了保证在系统宕机(类似进程被杀死)情况下,能更快的进行故障恢复,Redis设计了两种数据持久化方案,分别为rdb和aof方式。

RDB方式

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

 Rdb配置:

RDB方式的持久化是默认开启的,也可按规则自己配置,例如,打开redis.conf文件,修改如下内容:

# 这里表示每隔60s,如果有超过1000个key发生了变更,那么就生成一个新的dump.rdb文件,就是当前redis内存中完整的数据快照,这个操作也被称之为snapshotting(快照)。save 60 1000# 持久化 rdb文件遇到问题时,主进程是否接受写入,yes 表示停止写入,如果是no 表示redis继续提供服务。
stop-writes-on-bgsave-error yes# 在进行快照镜像时,是否进行压缩。yes:压缩,但是需要一些cpu的消耗。no:不压缩,需要更多的磁盘空间。
rdbcompression yes
# 一个CRC64的校验就被放在了文件末尾,当存储或者加载rbd文件的时候会有一个10%左右的性能下降,为了达到性能的最大化,你可以关掉这个配置项。
rdbchecksum yes# 快照的文件名
dbfilename dump.rdb# 存放快照的目录
dir /var/lib/redis

AOF方式

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

aof配置:

在redis.conf文件内,修改如下内容:

# 是否开启AOF,默认关闭
appendonly yes
# 指定 AOF 文件名
appendfilename appendonly.aof
# Redis支持三种刷写模式:
# appendfsync always #每次收到写命令就立即强制写入磁盘,类似MySQL的sync_binlog=1,是最安全的。但该模式下速度也是最慢的,一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次,在性能和持久化方面做平衡,推荐该方式。
# appendfsync no     #完全依赖OS的写入,一般为30秒左右一次,性能最好但是持久化最没有保证,不推荐。#在日志重写时,不进行命令追加操作,而只是将其放在缓冲区里,避免与命令的追加造成DISK IO上的冲突。
#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入,默认为no,建议yes
no-appendfsync-on-rewrite yes
#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时,自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
#当前AOF文件启动新的日志重写过程的最小值,避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb

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

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

二、事物处理 

Redis采用了乐观锁方式进行事务控制,它使用watch命令监视给定的key(可以调用watch多次监视多个key),当exec(提交事务)的时候,如果监视的key从调用watch后发生过变化,则整个事务会失败。

注意:watch监视的key是对整个连接有效的,如果连接断开,监视和事务都会被自动清除。当然exec,discard,unwatch命令都会清除连接中的所有监视。
 

常用指令

multi         开启事务

exec         提交事务

discard     取消事务

watch             监控,如果监控的值发生变化,则提交事务时会失败

unwatch         去掉监控

Redis保证一个事务中的所有命令要么都执行,要么都不执行(原子性)。如果在发送EXEC命令前客户端断线了,则Redis会清空事务队列,事务中的所有命令都不会执行。而一旦客户端发送了EXEC命令,所有的命令就都会被执行,即使此后客户端断线也没关系,因为Redis中已经记录了所有要执行的命令。
 

三、框架设计 

主从复制

单个Redis支持的读写能力还是有限的,此时我们可以使用多个redis来提高redis的并发处理能力,首先从主从(Master/Slave)架构进行分析和实现。其中,master负责读写,并将数据同步到salve,从节点负责读操作。

操作实践:

基于redis,设计一主从架构,一个Master,两个Slave,其中Master负责Redis读写操作,并将数据同步到Slave,Slave只负责读

第一步:将redis01拷贝两份。

cp -r redis01/ redis02cp -r redis01/ redis03

 第二步:启动新的redis容器。

假如已有redis服务,先将原先所有redis服务停止(docker rm -f redis容器名)。

docker run -p 6379:6379 --name redis6379 \
-v /usr/local/docker/redis01/data:/data \
-v /usr/local/docker/redis01/conf/redis.conf:/etc/redis/redis.conf \
-d redis redis-server /etc/redis/redis.conf \
--appendonly yesdocker run -p 6380:6379 --name redis6380 \
-v /usr/local/docker/redis02/data:/data \
-v /usr/local/docker/redis02/conf/redis.conf:/etc/redis/redis.conf \
-d redis redis-server /etc/redis/redis.conf \
--appendonly yesdocker run -p 6381:6379 --name redis6381 \
-v /usr/local/docker/redis03/data:/data \
-v /usr/local/docker/redis03/conf/redis.conf:/etc/redis/redis.conf \
-d redis redis-server /etc/redis/redis.conf \
--appendonly yes

第三步:检测redis服务角色

启动三个客户端,分别登陆三台redis容器服务,通过  info replication  指令进行角色查看,默认新启动的服务角色都为master。

第四步:检测redis6379的ip设置

docker inspect redis6379

第五步:设置Master/Slave架构

假如master有密码,需要在slave的redis.conf配置文件中添加"masterauth 你的密码"这条语句,然后重启redis再执行slaveof 指令操作.

分别登陆需要设置的slave容器,执行:slaveof  + ip + post

slaveof 172.17.0.2 6379 

主从复制原理分析: 

Redis的主从结构可以采用一主多从结构,Redis主从复制可以根据是否是全量分为全量同步和增量同步。

Redis全量同步:
Redis全量复制一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。具体步骤如下:
1)从服务器连接主服务器,发送SYNC命令;
2)主服务器接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令;
3)主服务器BGSAVE执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令;
4)从服务器收到快照文件后丢弃所有旧数据,载入收到的快照;
5)主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令;
6)从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令;

Redis增量同步:
Redis增量复制是指Slave初始化后,开始正常工作时主服务器发生的写操作同步到从服务器的过程。 增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令。

哨兵模式

哨兵模式(Sentinel)是Redis的主从架构模式下,实现高可用性(high availability)的一种机制。

操作实践:

第一步:创建配置文件。

# 分别进入3台redis容器内部,在容器指定目录/etc/redis创建sentinel.conf文件,进行如下配置:
sentinel monitor redis6379 172.17.0.2 6379 1
# 参数:
# redis6379               为服务名
# 172.17.0.2和6379        为master的ip和端口
# 1  表示多少个sentinel认为一个master失效时,master才算真正失效。

 注:创建文件如果出现command not found,可进行如下操作:

# 方法一:(在线安装)可依次执行如下两个指令来安装vim
apt-get update 
apt-get install vim
# 方法二:(离线安装)如网络不好,也可以在宿主机对应的挂载目录去创建文件,或者在容器中执行:
cat <<EOF > /etc/redis/sentinel.conf 
sentinel monitor redis6379 172.17.0.2 6379 1
EOF

 第二步:启动哨兵服务。

# 在每个redis容器内部的/etc/redis目录下执行如下指令(最好是在多个客户端窗口执行)
redis-sentinel sentinel.conf

 进阶配置:

1.sentinel.conf文件增强配置

sentinel monitor redis6379 172.17.0.2 6379 1 
daemonize yes #后台运行
logfile "/var/log/sentinel_log.log" #运行日志
sentinel down-after-milliseconds redis6379 30000 #默认30秒
# 其中:
# 1)daemonize yes表示后台运行(默认为no)
# 2)logfile 用于指定日志文件位置以及名字
# 3)sentinel down-after-milliseconds 表示master失效了多长时间才认为失效

 如基于cat指令创建sentinel.conf文件的话,使用如下指令:

cat <<EOF > /etc/redis/sentinel.conf
sentinel monitor redis6379 172.17.0.2 6379 1
daemonize yes 
logfile "/var/log/sentinel_log.log"
sentinel down-after-milliseconds redis6379 30000 
EOF

 哨兵模式原理分析:

1):每个Sentinel以每秒钟一次的频率向它所知的Master,Slave以及其他 Sentinel 实例发送一个 PING 命令。

2):如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值(这个配置项指定了需要多少失效时间,一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒,默认为30秒), 则这个实例会被 Sentinel 标记为主观下线。

3):如果一个Master被标记为主观下线,则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

4):当有足够数量的 Sentinel(大于等于配置文件指定的值)在指定的时间范围内确认Master的确进入了主观下线状态, 则Master会被标记为客观下线 。

5):在一般情况下, 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master,Slave发送 INFO 命令 。

6):当Master被 Sentinel 标记为客观下线时,Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 。

7):若没有足够数量的 Sentinel 同意 Master 已经下线, Master 的客观下线状态就会被移除。
8): 若 Master 重新向 Sentinel 的 PING 命令返回有效回复, Master 的主观下线状态就会被移除。
 

集群模式

Redis单机模式可靠性保证不是很好,容易出现单点故障,同时其性能也受限于CPU的处理能力,实际开发中Redis必然是高可用的,所以我们需要对目前redis的架构模式进行升级。
Sentinel模式做到了高可用,但是实质还是只有一个master在提供服务(读写分离的情况本质也是master在提供服务),当master节点所在的机器内存不足以支撑系统的数据时,就需要考虑集群了。
Redis集群架构实现了对redis的水平扩容,即启动N个redis节点,将整个数据分布存储在这N个redis节点中,每个节点存储总数据的1/N。redis集群通过分区提供一定程度的可用性,即使集群中有一部分节点失效或无法进行通讯,集群也可以继续处理命令请求。

Redis集群(Cluster),一般最少设置为6个节点,3个master,3个slave。

操作实践:

第一步:创建网卡

# 创建虚拟网卡,主要是用于redis-cluster能于外界进行网络通信,一般常用桥接模式。
docker network create redis-net
# 查看docker的网卡信息,可使用如下指令
docker network ls
# 查看docker网络详细信息,可使用命令
docker network inspect redis-net

 第二步:创建节点配置模板

# 1创建目录
mkdir -p /usr/local/docker/redis-cluster
# 2进入目录
cd /usr/local/docker/redis-cluster
# 3创建文件
vim redis-cluster.tmpl
# 4在redis-cluster.tmpl中输入以下内容
port ${PORT}
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-announce-ip 192.168.126.129
cluster-announce-port ${PORT}
cluster-announce-bus-port 1${PORT}
appendonly yes
# 各节点解释如下所示:
# port:节点端口,即对外提供通信的端口
# cluster-enabled:是否启用集群
# cluster-config-file:集群配置文件
# cluster-node-timeout:连接超时时间
# cluster-announce-ip:宿主机ip
# cluster-announce-port:集群节点映射端口
# cluster-announce-bus-port:集群总线端口
# appendonly:持久化模式

 第三步:创建节点配置文件

for port in $(seq 8010 8015); \
do \mkdir -p ./${port}/conf  \&& PORT=${port} envsubst < ./redis-cluster.tmpl > ./${port}/conf/redis.conf \&& mkdir -p ./${port}/data; \
done
# 其中
# for 变量 in $(seq var1 var2);do …; done为linux中的一种shell 循环脚本
# 指令envsubst <源文件>目标文件,用于将源文件内容更新到目标文件中

查看配置文件内容

cat /usr/local/docker/redis-cluster/801{0..5}/conf/redis.conf# 801{0..5} 表示打开从 8010开始到8015 的全部文件(六个文件)

 第四步:创建集群节点容器

for port in $(seq 8010 8015); \
do \docker run -it -d -p ${port}:${port} -p 1${port}:1${port} \--privileged=true -v /usr/local/docker/redis-cluster/${port}/conf/redis.conf:/usr/local/etc/redis/redis.conf \--privileged=true -v /usr/local/docker/redis-cluster/${port}/data:/data \--restart always --name redis-${port} --net redis-net \--sysctl net.core.somaxconn=1024 redis redis-server /usr/local/etc/redis/redis.conf; \
done
# 其中 :
# --privileged=true  表示让启动的容器用户具备真正root权限
# --sysctl net.core.somaxconn=1024  这是一个linux的内核参数,用于设置请求队列大小,默认为128。
# 后续启动redis的启动指令需要先放到这个请求队列中,然后依次启动.
# 创建成功以后,通过docker ps指令查看节点内容。

第五步:创建集群节点配置

# 1进入容器
docker exec -it redis-8010 bash
# 2集群创建
redis-cli --cluster create 192.168.126.128:8010 192.168.126.128:8011 192.168.126.128:8012 192.168.126.128:8013 192.168.126.128:8014 192.168.126.128:8015 --cluster-replicas 1
# 其中最后的 1 表示主从比例
# 当出现选择提示信息时,输入 yes 即可

查看集群:

cluster nodes   #查看集群节点数
cluster info    #查看集群基本信息

第六步:连接集群

redis-cli -c -h 192.168.126.128 -p 8010
# 其中:
# -c表示集群(cluster)
# -h表示host(一般写ip地址)
# -p为端口(port)

注:在搭建过程,可能在出现问题后,需要停止或直接删除docker容器,可以进行如下操作

# 1批量停止docker 容器
docker ps -a | grep -i "redis-801*" | awk '{print $1}' | xargs docker stop
# 2批量删除docker 容器
docker ps -a | grep -i "redis-801*" | awk '{print $1}' | xargs docker rm -f
# 3批量删除文件,目录
rm -rf 801{0..5}/conf/redis.conf
rm -rf 801{0..5}

更多推荐

Redis操作实践

本文发布于:2024-02-06 09:11:55,感谢您对本站的认可!
本文链接:https://www.elefans.com/category/jswz/34/1747968.html
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
本文标签:操作   Redis

发布评论

评论列表 (有 0 条评论)
草根站长

>www.elefans.com

编程频道|电子爱好者 - 技术资讯及电子产品介绍!