当前位置： 首页 > news >正文

Redis——运维篇

news 2025/8/4 9:23:08

Redis安装

  • redis本身并没有提供Windows系统的支持，且工作中redis一般都部署在Linux系统中，这里演示centos7安装redis
  • 学习阶段推荐使用Windows下的Docker Desktop部署redis容器，提高学习效率

安装redis依赖

  • 如果yum不超过，可能因为centos已经停止维护，需要先对yum换源，这里采用阿里云源
wget -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
#或者
curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo

yum clean all
yum makecache
yum -y update
yum install -y gcc tcl

下载redis并解压

  • 下载 - Redis ，推荐选择redis6
  • 这里解压到/usr/local/redis6中方便管理，也有不指定安装目录，默认安装在/usr/local/redis/bin
tar -zxvf redis-6.2.14.tar.gz
mv redis-6.2.14.tar.gz /usr/local/redis6

安装redis

#在解压的安装文件下执行编译，假设安装包为/usr/local/redis6
make PREFIX=/usr/local/redis6 install

配置环境变量

  • 如果使用默认安装位置则不用配置环境变量
vim /etc/profile

export REDIS_HOME=/user/local/redis6
export PATH=$PATH::$REDIS_HOME/bin

source /etc/profile

检查版本

redis-server -v

修改redis配置文件

  • 位置：解压的redis安装包内redis.conf
#进入redis安装包内，为了防止配置文件被改坏，建议先拷贝一份
cp redis.conf redis.conf.backup
#修改redis.conf
vim redis.conf

#设置远程连接，一般应设置为应用所在服务器的地址，这里0.0.0.0表示任意地址
bind 0.0.0.0
#开启保护模式，这样只有bind设置的客户端才可以连接
protected-mode no
#端口号默认6379，工作中建议修改端口号增加安全性
port 6379
#开启密码
requirepass 123456
#开启守护线程，即后台启动
daemonize yes
#指定工作目录，否则在哪里执行开启redis命令哪里就是工作目录
dir /usr/local/redis
#开启日志，地址前缀是redis工作目录
logfile /usr/local/redis6/redis.log
#数据库数量，redis不能主动创建库，但可以设置数据库的数量，默认16个库
databases 16

开放防火墙

firewall-cmd --zone=public --add-port=6379/tcp --permanentfirewall-cmd --reload

启动redis

#进入redis安装目录
cd /usr/local/redis6
#后台启动
redis-server redis.conf

#查看redis是否运行
ps -ef|grep redis
#强制停止redis
kill -9 查询的redis进程码
#进入服务端停止redis
redis-cli -a 密码 -h IP地址 -p 端口号
#停止redis
shutdown
#退出客户端
exit

Redis客户端

命令行客户端

  • 安装redis完成后，redis就自带了一个命令行客户端redis-cli
  • redis-cli可以连接其他主机的redis
  • 进入命令行客户端后就可以进行redis相关操作
#测试客户端能否成功连接redis，成功会返回pong
redis-cli -h ip地址 -p 端口号 -a 连接密码 ping
#进入redis命令行客户端
redis-cli -h ip地址 -p 端口号 -a 连接密码
#不带密码也可以连接到redis，但没有操作权限
redis-cli -h ip地址 -p 端口号
#要操作再输入密码
auth 123456
#退出redis-cli
exit

#redis-cli操作数据示例
select 1
set name wyh
get name
flash all

图形化界面客户端

  • redis6以前不支持多用户，redis6后可以设置多用户，如果不在redis.cnf中特意设置用户名则默认default

AnotherRedisDesktopManager 发行版 - Gitee.com

Java客户端

  • 类似于JDBC，通过编程语言连接redis实现自动化数据操纵

    1. Jedis
    2. Lettuce
    3. Redisson

  • redis支持几乎市面上所有的编程语言，可以在官网 （连接 Redis 客户端 |文档 ）查询到各种编程语言的连接和操作手册

Redis集群

  • 目的：单点redis有性能瓶颈，redis集群架构可以更好的应对高并发环境

主从架构

  • 原理

    1. 主从第一次连接会进行一次全量同步，原理是将master节点直接将RDB文件发送给slave节点实现全量同步

    2. 主从连接成功以后的同步方式都是增量同步，原理是master节点把命令日志发送给slave节点实现增量同步

  • 常见主从架构

    1. 一主多从：适用于读多写少场景，从节点可级联复制
    2. 薪火相传：主节点 → 从节点1 → 从节点2（从节点作为其他从节点的主节点），减少主节点负载

主从部署

1.环境准备

  • 一主一从：主节点6379，从节点6380
# 6379.conf
bind 0.0.0.0
protected-mode no
port 6379
# 启用持久化
appendonly yes
requirepass "123456"
# 以守护进程运行
daemonize yes
# 日志路径
logfile "/var/log/redis/redis-master.log"

# 6380.conf
bind 0.0.0.0
port 6380
# 指定同步主节点IP和端口
replicaof 127.0.0.1 6379
# 主节点如果有密码必须设置密码
masterauth "123456"
# 从节点只读（默认开启）
replica-read-only yes
# 启用持久化
appendonly yes
requirepass "123456"
# 优先使用磁盘进行全量同步（避免内存占用过高）
repl-diskless-sync no

2.启动节点

# 启动主节点
redis-server /path/to/6379.conf
# 启动从节点
redis-server /path/to/6380.conf

3.验证主从状态

# 主节点上查看同步状态
redis-cli -h 127.0.0.1 -p 6379 -a 123456 info replication
# 示例
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,...

# 从节点上查看同步状态
redis-cli -h 127.0.0.1 -p 6380 -a 123456 info replication
# 示例
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up

4.数据操作

# 主节点添加数据
redis-cli -h 127.0.0.1 -p 6379 -a 123456 SET test_key "hello"
# 从节点查询数据
redis-cli -h 127.0.0.1 -p 6380 -a 123456 GET test_key # 应返回 "hello"

# 如果设置从节点只读，从节点添加数据会失败
redis-cli -h 127.0.0.1 -p 6380 -a 123456 SET test_key
# 示例
(error) READONLY You cant write against a read only replica.

哨兵机制

  • 目的：解决redis主从架构中，主节点宕机的风险问题

  • 原理

    1. 加入哨兵节点，负责监控节点状态，当主节点宕机时，哨兵可以“选举”出其他节点作为新的主节点
    2. 哨兵选出新的主节点后，从节点会自动重新配置，同步新的主节点

1.环境准备

  • 一主二从二哨兵：主节点6379，从节点6380、6381，哨兵26379、26380
  • 哨兵需要远程连接节点，节点配置bind要加入哨兵的地址，或者直接关闭保护模式protected-mode no
# 6379.conf
bind 0.0.0.0
port 6379
requirepass 123456
# 开启AOF持久化
appendonly yes
daemonize yes

# 6380.conf
bind 0.0.0.0
port 6380
# 指定主节点地址和端口号
slaveof 127.0.0.1 6379
requirepass 123456
# 主节点密码
masterauth 123456
appendonly yes
daemonize yes

# 6381.conf
bind 0.0.0.0
port 6381
# 指定主节点地址和端口号
slaveof 127.0.0.1 6379
requirepass 123456
# 主节点密码
masterauth 123456
appendonly yes
daemonize yes

# 26379.conf
bind 0.0.0.0
port 26379
daemonize yes
# 监控主节点，mymaster为主节点名称，2表示当有2个哨兵认为主节点下线时，则认为主节点客观下线
sentinel monitor mymaster 127.0.0.1 6379 2  
# 主节点密码
sentinel auth-pass mymaster 123456    
# 主节点超时时间
sentinel down-after-milliseconds mymaster 5000  
# 故障转移超时时间
sentinel failover-timeout mymaster 15000           

# 26380.conf
bind 0.0.0.0
port 26380
daemonize yes
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster 123456
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 15000

2.启动节点

# 启动主节点
redis-server /path/to/6379.conf
# 启动从节点
redis-server /path/to/6380.conf
# 启动从节点
redis-server /path/to/6381.conf
# 启动哨兵
redis-sentinel /path/to/26379.conf
# 启动哨兵
redis-sentinel /path/to/26379.conf

3.验证哨兵模式状态

# 在任意哨兵节点上查看集群状态
redis-cli -p 26379
# 查看监控的主节点信息
SENTINEL masters
# 查看主节点mymaster下的所有从节点信息
SENTINEL slaves mymaster
# 查看监控主节点mymaster的其他哨兵节点信息
SENTINEL sentinels mymaster

4.故障转移

  • 将主节点宕机，发现哨兵检测到了，并选举一个从节点成为新的主节点
# 模拟主节点下线
redis-cli -h 127.0.0.1 -p 6379 SHUTDOWN
# 哨兵会选择从节点会自动晋升为主节点
redis-cli -p 26379 SENTINEL masters
# 原主节点恢复后，不会恢复原本主节点的位置，而是成为新的从节点
redis-server 6379.conf

数据分片

  • Redis 分片架构原理

    1. 数据分片机制：Redis 集群采用 16384 个哈希槽（Hash Slot） 实现数据分片，每个节点负责一部分槽位
    2. 集群扩容：键通过 CRC16(key) % 16384 计算哈希槽位置，支持在线扩容/缩容（通过迁移哈希槽实现）
    3. 节点通信机制：Gossip 协议，节点间每秒随机交换消息（PING/PONG），维护集群状态，收敛速度较慢但负载低
    4. 客户端路由：客户端直接与目标节点通信，缓存哈希槽-节点映射关系

  • 数据分片（Redis Cluster）已经实现高可用，不建议再加入哨兵机制

分片部署

1. 环境准备

  • 三主节点：6379、6380、6381，三从节点（一个主节点至少有一个从节点）：6382、6383、6384

    # 6379.conf为例
bind 0.0.0.0
port 6379
requirepass 123456
appendonly yes
daemonize yes
# 启用Redis集群模式
cluster-enabled yes
# 指定Redis集群节点的配置文件（自动生成）
cluster-config-file nodes.conf
# 设置Redis集群中节点之间通信的超时时间
cluster-node-timeout 15000

    # 从节点以6382.conf为例
bind 0.0.0.0 
port 6380
daemonize yes 
# 持久化配置
appendonly yes
# 必须启用集群模式，负责故障转移后新主节点无法处理原有槽位的请求，导致集群部分数据不可用
cluster-enabled yes  
# 集群节点配置文件
cluster-config-file "/opt/redis/6380/nodes-6380.conf"  
# 节点超时时间（毫秒）
cluster-node-timeout 15000  
# 主从配置（静态指定主节点）
replicaof 127.0.0.1 6379

2. 启动节点

redis-server /path/to/6379.conf
redis-server /path/to/6380.conf
# 依次启动所有节点...

3. 创建集群

#-cluster-replicas 1 的含义：表示每个主节点分配 1 个从节点，因此前三个是主节点，后三个是从节点
#在任意一个主节点下执行
redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 \127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 \--cluster-replicas 1

4. 验证集群状态

# 连接任意主节点
CLUSTER NODES  # 查看节点与槽分布
CLUSTER INFO   # 查看集群整体状态

5.数据操作

# 写入数据（自动路由到对应节点）
redis-cli -c -h 127.0.0.1 -p 7000 SET user:1001 "Alice"
# 读取数据
redis-cli -c -h 127.0.0.1 -p 7000 GET user:1001

6.故障转移

# 模拟节点下线
redis-cli -h 127.0.0.1 -p 6379 SHUTDOWN
# Redis Cluster会自动选举一个从节点成为新的主节点
redis-cli -h 127.0.0.1 -p 6380 CLUSTER NODES
# 原主节点恢复后，不会恢复原本主节点的位置，而是成为新的从节点
redis-server 6379.conf
# 也可以手动指定原主节点成为哪一个节点的从节点
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER REPLICATE <新主节点ID>

集群扩容

  1. 启动新节点（如 7006）

    redis-server 7006.conf

  2. 加入集群

    # 127.0.0.1:7006是新的节点，127.0.0.1:6379是任意一个集群中的节点
redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:6379
# 如果希望新加入的节点是从节点
redis-cli -p 6385 CLUSTER REPLICATE <master-node-id>

  3. 分配哈希槽：如果新节点是主节点但无槽位，需通过从其他节点迁移部分槽到新节点

    redis-cli --cluster reshard 127.0.0.1:6379

监控与维护

  • 核心监控指标

    1. 节点状态：通过redis-cli -c -p <port> cluster nodes命令查看所有节点的状态信息
    2. 性能指标：
      • QPS（每秒查询数）：反映Redis集群的处理能力。
      • 内存使用情况：包括used_memory（已分配内存）、used_memory_rss（操作系统视角的已分配内存）、mem_fragmentation_ratio（内存碎片率）等。监控内存使用情况，避免内存溢出或内存碎片过多导致性能下降
      • 网络延迟：监控客户端与Redis集群之间的网络延迟，确保低延迟的数据传输
    3. 数据同步状态：
      • 在Redis集群模式下，每个节点都需要进行数据同步以达到数据一致性。监控数据同步状态，确保数据同步正常进行
      • 通过cluster nodes命令查看每个节点的复制状态，如master、slave以及复制偏移量等

  • 常用监控工具

    1. Redis Insight：
      • Redis Labs开发的一款免费开源的Redis集群监控工具，通过Web界面展示Redis集群的各种指标和状态信息
      • 支持实时监控、历史数据分析、性能调优等功能
    2. Prometheus + Grafana：
      • Prometheus是一个开源的监控和告警系统，可以采集Redis集群的监控数据
      • Grafana是一个可视化工具，可以将Prometheus采集的数据以图表形式展示出来，便于直观分析
      • 通过redis_exporter将Redis集群的监控数据暴露给Prometheus进行采集
    3. Zabbix：
      • 一款企业级的开源监控解决方案，支持对Redis集群进行多维监控
      • 通过配置Zbbix Agent或Zabbix Agent 2收集Redis集群的监控数据，并在Zabbix Server的Web界面进行展示和分析
    4. CacheCloud：
      • 专为Redis设计的运维工具，提供了一系列便捷的管理和监控功能
      • 支持应用统计信息查看、实例列表展示、慢查询分析、配置查询等功能

Redis持久化

  • 目的：redis虽然运行在内存中，但仍然具备持久化策略，当redis遭遇故障时可以最大程度恢复数据

  • 原理

    1. RDB：数据备份，RDB是redis默认的持久化策略
    2. AOF：日志重放

RDB

  • 描述：RDB是数据备份文件，redis会定时将内存中的数据保存到磁盘中，遇故障重启时，会根据RDB文件恢复数据

  • RDB持久化方式

    1. 同步持久化：由redis主进程执行持久化
    2. 异步持久化：redis会fork一个子进程进行数据备份，这时间主进程依然可以响应客户端，但此时数据可能不全

  • 触发机制

    1. 手动触发：SAVE（阻塞主线程）或 BGSAVE（后台子进程生成）

      #由redis主线程执行一次RDB，此时会阻塞所有其他命令
save
#开启一个子线程异步执行RDB
bgsave

    2. 自动触发：配置文件redis.conf设置，自动触发 BGSAVE异步备份数据

      # 3600秒内执行一次set操作则持久化1次、 300秒内执行10次set操作则持久化1次 、 60秒内执行10000次set操作,则持久化1次
save 3600 1
save 300 100
save 60 10000

  • 特点

    1. RDB恢复数据较快
    2. RDB还是有数据丢失的风险（例如未来得及备份就宕机）
    3. 虽然RDB实现了copy-on-write技术，数据量庞大时RDB持久化还是比较耗时

AOF

  • 描述：AOF是追加文件，也可以认为是日志文件，遇故障重启时，会根据日志文件的内容将重写指令，完成数据的恢复工作

  • AOF功能默认关闭，需要在配置文件中开启

    # 1. 启用AOF持久化（默认关闭）
appendonly yes# 2. 指定AOF文件名（默认即为appendonly.aof）
# 设置工作目录（所有持久化文件，包括RDB和AOF，都会存储在此目录下）
dir /path/to/your/data/directory
appendfilename "appendonly.aof"# 3. 设置AOF同步策略（推荐everysec）
# always: 每个写命令都同步到磁盘（最安全，性能最低）
# everysec: 每秒同步一次（平衡安全与性能，默认值）
# no: 由操作系统决定同步时机（性能最好，但可能丢失数据）
appendfsync everysec# 4. AOF重写配置（自动压缩AOF文件）
# 当AOF文件增长百分比超过设定值且文件大小超过最小值时触发重写
auto-aof-rewrite-percentage 100  # 相比上次重写后的增长比例
auto-aof-rewrite-min-size 64mb   # 触发重写的最小文件大小# 5. 是否在AOF重写时继续执行写命令（默认yes）
# 若为no，重写期间会阻塞所有请求
no-appendfsync-on-rewrite no# 6. AOF文件损坏时的修复策略
# 若AOF文件损坏，Redis启动时会报错，可通过以下命令修复：
# redis-check-aof --fix appendonly.aof
aof-load-truncated yes  # 允许加载截断的AOF文件（避免启动失败）# 7. 启用RDB+AOF混合模式（Redis 4.0+）
# 开启后，AOF重写时直接生成RDB格式数据，再追加增量AOF日志
aof-use-rdb-preamble yes

  • 特点

    1. 虽然AOF采用的文件追加重写机制，但较于RDB，恢复数据速度还是较慢
    2. 数据不易丢失
    3. AOF本质上是日志文件，可以根据实际情况选择部分恢复

RDB + AOF 混合模式

  • 描述：AOF 重写时生成 RDB 数据，直接将内存数据以 RDB 格式写入 AOF 文件开头，后续追加增量 AOF 日志

  • 原理

    1. 先加载 RDB 部分快速恢复全量数据
    2. 再回放增量 AOF 日志修复到最新状态

  • 配置文件

    appendonly yes
# 启用混合模式
aof-use-rdb-preamble yes  
# 推荐同步策略
appendfsync everysec

  • 特点

    1. 恢复速度快：RDB 部分加速全量恢复，AOF 部分保证数据最新
    2. 安全性高：结合了 RDB 的紧凑性和 AOF 的低丢失率
    3. 注意，混合模式仅 Redis 4.0+ 支持：旧版本无法使用

RDB和AOF选择

场景推荐方案理由
缓存，允许少量丢失仅 RDB高性能，恢复快，适合非关键数据
数据不能丢失仅 AOF（everysec）或混合模式平衡安全性和性能，混合模式恢复更快
大规模数据 + 高安全RDB（定期） + AOF（everysec）RDB 用于快速备份，AOF 防止数据丢失
极低延迟要求禁用持久化 + 定期 BGSAVE 备份牺牲安全性换取性能（需接受数据丢失风险）
http://www.lryc.cn/news/608912.html

相关文章：

  • Linux | i.MX6ULL移植 Gdb+Gdbserver 调试(第十四章)
  • day50预训练模型 CBAM注意力
  • 蛇形卷积介绍
  • 实战案例：容器数据卷四部曲（三）目录数据卷
  • 【C++】面向对象编程：继承与多态的魅力
  • 对大脑功能连接进行功能注释
  • git配置公钥/密钥
  • FasrCGI
  • 【ROS2】常用命令
  • Python中的import和from...import有什么区别？
  • 北京-4年功能测试2年空窗-报培训班学测开-第六十六天
  • FFT/STFT/小波/HHT：振动诊断工具生死局，选错=灾难
  • 构造类型--结构体，共同体联合体，枚举
  • 多模态大模型综述：BLIP-2详解（第二篇）
  • jconsole与jvisualvm监控
  • Python 动态属性和特性(特性全解析)
  • 前端 拼多多4399笔试题目
  • RabbitMQ面试精讲 Day 8：死信队列与延迟队列实现
  • 数据分析—numpy库
  • JS逆向 - （国外）川航 - Reese84（cookie）
  • Mongo索引
  • git相关配置问题汇总
  • Linux 文件与目录操作详解
  • 从Docker衔接到导入黑马商城以及前端登录显示用户或密码错误的相关总结(个人理解，仅供参考)
  • PyTorch生成式人工智能（24）——使用PyTorch构建Transformer模型
  • accept4系统调用及示例
  • ABP VNext + CloudEvents：事件驱动微服务互操作性
  • 数据治理：DQC（Data Quality Center，数据质量中心）概述
  • [每周一更]-(第153期)：**PDF终极防护指南：命令行全栈加密+一键权限锁死实战（附脚本模板）**
  • Docker--解决x509: certificate signed by unknown authority