目录

• 简介
• 持久化
• 主从复制
• 高可用 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种：

1. RDB：快照方式，相当于 MySQL 中的 dump
2. AOF：写日志方式，相当于 MySQL 中的 binlog，推荐使用

注意：

1. 当同时开启 RDB 和 AOF 的时候，redis启动的时候会读取 AOF 还原数据。
2. 推荐：关闭 RDB 持久化机制,开启 AOF

RDB

RDB是什么：

1. RDB方式的持久化是通过快照(snapshortting)完成的，当符合一定条件时Redis会自动将内存中所有数据完整的压缩存储到硬盘上。
2. RDB开启条件由2个参数 时间 和 改动次数构成。如：save 900 1
3. RDB文件由2个参数 dir 和 dbfilename 分别指定目录 和 文件名
4. RDB方式是Redis默认的持久化方式。

触发命令：

1. save 命令(阻塞)
2. bgsave 命令(fork过程阻塞)

主要触发方式:

1. 自动触发规则(内部调用bgsave，不推荐开启)
2. 全量复制(内部调用bgsave)

过程：

1. 执行 save 或 bgsave 命令
2. 生成新的 rdb 文件，如：temp-36985.rdb
3. 覆盖 rdb 文件，如：dump-6379.rdb

优点：

1. 启动速度快
2. 占用空间小

缺点：

1. 容易丢失数据
2. 时间复杂度O(n)

关闭RDB方式：

redis-cli config set save ""

注意：

RDB并不能真正的关闭，在主从复制时主从都会生成RDB文件

AOF

AOF是什么:

1. AOF是纯文本文件，会记录 Redis 的每次改动命令(不记录查询)。
2. AOF开启条件：appendonly yes
3. AOF文件由2个参数 dir 和 appendfilename 分别指定目录 和 文件名
4. AOF方式 默认情况下Redis并没有开启。

由于每次改动都会记录，产生2个问题：

1. 每次改动都写入硬盘，普通硬盘只能承受几百次qps。通过写入策略来调整
2. 对同1个key执行几次操作就记录几次，冗余量特别大。通过 aof 文件重写来调整

AOF文件有3种写入策略：

1. always(每次写入都会fsync同步到硬盘)
2. everysec(默认，1s写1次)
3. no(并非不写，交给系统控制预计30s写1次)

AOF重写：

1. 重写方式
   1. 手动执行 bgrewriteaof 命令
   2. 自动触发规则(通过指定最小aof文件和aof增长率来自动内部调用 bgrewriteaof)
2. 过程
   1. fork 出子进程
   2. 子进程执行 bgrewriteaof 命令
   3. 父进程将新接收的命令，同时写到 aof 文件和 aof_rewrite_buffer文件中。(在 aof 重写时，可配置关闭aof写入)
   4. 子进程将 aof_rewrite_buffer 文件追加到新 aof 文件中。
   5. 覆盖旧的 aof 文件

注意：

1. 采用 everysec 方式，最多可能丢失 2s 的数据。

主从复制

为什么需要主从复制：

通过持久化保证 Redis 在服务器重启的情况下数据也不会丢失。但数据在一台服务器上，如果服务器的硬盘坏了,也会导致数据丢失。为了避免单点故障，Redis 提供了主从复制高可用方案。

主从复制结构：

1. 1个 master 可以有多个 slave
2. 1个 slave 只能有1个 master
3. 数据流向单向 master -> slave

开启复制：

1. 命令：--slaveof ip port
2. 配置：slaveof ip port(默认配置都是master)

关闭复制：

slaveof no one

复制类型：

1. 全量复制(首次 或者 网络断开时间比较长)
2. 部分复制(在网络抖动一定范围的情况下,v2.8以上可配置复制缓存区repl-backlog-size)

全量复制过程：

1. slave 节点 发起 psync runid offset：psync ? -1
2. master 节点 返回 fullresync runid offset
3. master 节点 bgsave 保存当前数据到 rdb
4. master 节点 在此期间接收到新的数据存储到 buffer 中
5. master 节点 send RDB、send buffer
6. slave 节点 flush old data
7. slave 节点 load RDB、load buffer

在master重启(master 的run_id更新)和slave重启(slave 的run_id丢失)时都会发生全量复制,通过 info server 可以查看run_id。

部分复制过程：

1. slave 节点 发起 psync runid offset
2. master 节点 确认 runid 和 offset没问题后，发送增量数据
3. slave 节点 接收同步数据。

当全量复制完成 或 网络抖动一定范围 时，master 相当于 slave 的 client 进行增量更新数据。

Redis Sentinel

Redis-Sentinel是什么？

1. Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案
2. Redis-Sentinel本身也是一个独立运行的进程，它能监控多个 master-slave 集群，发现 master宕机 后能进行自动故障转移。

sentinel工作原理：

1. 准备多个Redis Sentinel节点(建议至少3个节点，避免单点故障)
2. 多个 Sentinel 节点发现并确认 master 主观下线
3. 超过 quorum 个 sentinel 判定确认 客观下线
4. 选出 1个 sentinel 节点作为领导
5. 选出 1个 slave 节点作为 master
6. 切换 slave 节点的 master 为新的 master
7. 通知 client 主从变化
8. 等待故障的 master 复活成为新的 slave
9. Client 不直接连接 Redis 节点，应该连接 Sentinel 节点获取 Redis Info

2种下线判定：

1. sdown(subjectively down,主观下线)：每个 sentinel 判定 redis 节点下线。
2. odown