目录
- 简介
- 持久化
- 主从复制
- 高可用 Redis-Sentinel
- .NET Core开发
- 分布式 Redis-Cluster
- 配置说明
- 常见问题
简介
本节内容基于 CentOS 7.4.1708,Redis 3.2.12 环境实验。
Redis 是一个开源的高性能键值对数据库。
安装:yum install -y redis
特性:
- 高性能 Key-Value 服务器
- 多种数据结构
- 丰富功能
- 缓存(get|set)
- 计数器(incre)
- 消息队列(publish|subcrib)
- 高可用(v2.8 redis-sentinel)
- 分布式(v3.0 redis-cluster)
可执行文件:
- redis-server:服务端
- redis-cli:客户端
- redis-benchmark:性能测试工具
- redis-check-aof:aof修复工具
- redis-check-dump:rdb修复工具
- redis-sentinel:sentinel服务端
启动方式:
- 最简启动:默认配置直接启动redis-server
- 动态参数启动:命令行指定配置启动redis-server
- 配置文件启动(推荐):指定配置文件启动redis-server
启动验证:
ps -ef|grep redis
redis-cli -h locahost -p 6379 ping
由于 redis 是单线程的,推荐在一台多核CPU机器上部署多个 redis 实例充分发挥。
持久化
redis 持久化支持2种:
- RDB:快照方式,相当于 MySQL 中的 dump
- AOF:写日志方式,相当于 MySQL 中的 binlog,推荐使用
注意:
- 当同时开启 RDB 和 AOF 的时候,redis启动的时候会读取 AOF 还原数据。
- 推荐:关闭 RDB 持久化机制,开启 AOF
RDB
RDB是什么:
- RDB方式的持久化是通过快照(snapshortting)完成的,当符合一定条件时Redis会自动将内存中所有数据完整的压缩存储到硬盘上。
- RDB开启条件由2个参数 时间 和 改动次数构成。如:save 900 1
- RDB文件由2个参数 dir 和 dbfilename 分别指定目录 和 文件名
- RDB方式是Redis默认的持久化方式。
触发命令:
- save 命令(阻塞)
- bgsave 命令(fork过程阻塞)
主要触发方式:
- 自动触发规则(内部调用bgsave,不推荐开启)
- 全量复制(内部调用bgsave)
过程:
- 执行 save 或 bgsave 命令
- 生成新的 rdb 文件,如:temp-36985.rdb
- 覆盖 rdb 文件,如:dump-6379.rdb
优点:
- 启动速度快
- 占用空间小
缺点:
- 容易丢失数据
- 时间复杂度O(n)
关闭RDB方式:
redis-cli config set save ""
注意:
RDB并不能真正的关闭,在主从复制时主从都会生成RDB文件
AOF
AOF是什么:
- AOF是纯文本文件,会记录 Redis 的每次改动命令(不记录查询)。
- AOF开启条件:appendonly yes
- AOF文件由2个参数 dir 和 appendfilename 分别指定目录 和 文件名
- AOF方式 默认情况下Redis并没有开启。
由于每次改动都会记录,产生2个问题:
- 每次改动都写入硬盘,普通硬盘只能承受几百次qps。通过写入策略来调整
- 对同1个key执行几次操作就记录几次,冗余量特别大。通过 aof 文件重写来调整
AOF文件有3种写入策略:
- always(每次写入都会fsync同步到硬盘)
- everysec(默认,1s写1次)
- no(并非不写,交给系统控制预计30s写1次)
AOF重写:
- 重写方式
- 手动执行 bgrewriteaof 命令
- 自动触发规则(通过指定最小aof文件和aof增长率来自动内部调用 bgrewriteaof)
- 过程
- fork 出子进程
- 子进程执行 bgrewriteaof 命令
- 父进程将新接收的命令,同时写到 aof 文件和 aof_rewrite_buffer文件中。(在 aof 重写时,可配置关闭aof写入)
- 子进程将 aof_rewrite_buffer 文件追加到新 aof 文件中。
- 覆盖旧的 aof 文件
注意:
- 采用 everysec 方式,最多可能丢失 2s 的数据。
主从复制
为什么需要主从复制:
通过持久化保证 Redis 在服务器重启的情况下数据也不会丢失。但数据在一台服务器上,如果服务器的硬盘坏了,也会导致数据丢失。为了避免单点故障,Redis 提供了主从复制高可用方案。
主从复制结构:
- 1个 master 可以有多个 slave
- 1个 slave 只能有1个 master
- 数据流向单向 master -> slave
开启复制:
- 命令:
--slaveof ip port
- 配置:
slaveof ip port
(默认配置都是master)
关闭复制:
slaveof no one
复制类型:
- 全量复制(首次 或者 网络断开时间比较长)
- 部分复制(在网络抖动一定范围的情况下,v2.8以上可配置复制缓存区repl-backlog-size)
全量复制过程:
- slave 节点 发起 psync runid offset:
psync ? -1
- master 节点 返回 fullresync runid offset
- master 节点 bgsave 保存当前数据到 rdb
- master 节点 在此期间接收到新的数据存储到 buffer 中
- master 节点 send RDB、send buffer
- slave 节点 flush old data
- slave 节点 load RDB、load buffer
在master重启(master 的run_id更新)和slave重启(slave 的run_id丢失)时都会发生全量复制,通过 info server 可以查看run_id。
部分复制过程:
- slave 节点 发起 psync runid offset
- master 节点 确认 runid 和 offset没问题后,发送增量数据
- slave 节点 接收同步数据。
当全量复制完成 或 网络抖动一定范围 时,master 相当于 slave 的 client 进行增量更新数据。
Redis Sentinel
Redis-Sentinel是什么?
- Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案
- Redis-Sentinel本身也是一个独立运行的进程,它能监控多个 master-slave 集群,发现 master宕机 后能进行自动故障转移。
sentinel工作原理:
- 准备多个Redis Sentinel节点(建议至少3个节点,避免单点故障)
- 多个 Sentinel 节点发现并确认 master 主观下线
- 超过 quorum 个 sentinel 判定确认 客观下线
- 选出 1个 sentinel 节点作为领导
- 选出 1个 slave 节点作为 master
- 切换 slave 节点的 master 为新的 master
- 通知 client 主从变化
- 等待故障的 master 复活成为新的 slave
- Client 不直接连接 Redis 节点,应该连接 Sentinel 节点获取 Redis Info
2种下线判定:
- sdown(subjectively down,主观下线):每个 sentinel 判定 redis 节点下线。
- odown