NoSQL之Redis配置与优化（持久化、主从复制、哨兵模式、集群模式）
一、关系数据库和非关系数据库
1. 关系数据库
一个结构化的数据库，创建在关系模型基础上
一般面向与记录
包括：Oracle、MySQL、SQL Server、Microsoft Access、DB2等
优点：
① 安全性高（持久化）
② 事务处理能力强
③ 任务控制能力强
④ 可以做日志备份、恢复、融资的能力更强一点
数据流向：
实例 ---> 数据库 ---> 表（table）---> 记录行（row）、数据字段（column）---> 存储数据
2. 非关系数据库
除了主流的关系型数据库外的数据库，都认为是非关系型数据库
包括：Redis、 MongBD、Hbase、CouhDB等
非关系型数据库产生背景
可用于应对web2.0纯动态网站类型的三高问题。
（1）High performance—对数据库高并发读写需求
（2）Huge storage——对海量数据高效存储与访问需求
（3）High Scalability && High Availability—对数据库高可扩展性与高可用性需求
优点：
关系型数据库和非关系型数据库都有各自的特点与应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上，非关系型数据库关注在存储上。例如，在读写分离的MysQL数据库环境中，可以把经常访问的数据存储在非关系型数据库中，提升访问速度。
① 数据库保存在缓存中，利于读取速度/查询数据
② 架构位置灵活
③ 分部署、扩展性高
数据流向：
实例 ---> 数据库 ---> 集合 ---> 键值对
注：非关系型数据库不需要手动建数据库和集合
3. 关系数据库与非关系数据库区别
（1）数据存储方式不同
关系型和非关系型数据库的主要差异是数据存储的方式。关系型数据天然就是表格式的，因此存储在数据表的行和列中。数据表可以彼此关联协作存储，也很容易提取数据。
与其相反，非关系型数据不适合存储在数据表的行和列中，而是大块组合在一起。非关系型数据通常存储在数据集中，就像文档、键值对或者图结构。你的数据及其特性是选择数据存储和提取方式的首要影响因素。
（2）扩展方式不同
SQL和NoSQL数据库最大的差别可能是在扩展方式上，要支持日益增长的需求当然要扩展。要支持更多并发量，SQL数据库是纵向扩展，也就是说提高处理能力，使用速度更快速的计算机，这样处理相同的数据集就更快了。因为数据存储在关系表中，操作的性能瓶颈可能涉及很多克服。虽然SQL数据库有很大扩展空间，但最终肯定会达到纵向扩展的上限个表，这都需要通过提高计算机性能来。
而NoSQL数据库是横向扩展的。因为非关系型数据存储天然就是分布式的，NoSgL数据库的扩展可以通过给资源池添加更多普通的数据库服务器（节点）来分担负载。
关系：纵向比如说硬件中添加内存
非关：横向天然分布式
（3）对事务性的支持不同
如果计数据操作需要高事务性或者复杂数据查询需要控制执行划，那么传统的SQL数据库从性能和稳定性方面考虑是你的最佳选择。SQL数据库支持对事务原子性细粒度控制，并且易于回滚事务。
虽然NoSQL数据库也可以使用事务操作，但稳定性方面没法和关系型数据库比较，所以它们真正闪亮的价值是在操作的扩展性和大数据量处理方面。
| 区别 | 关系型数据库（MySQL）-SQL数据库 | 非关系型数据库（redis、 MongoDB）-NoSQL数据库 |
|---|---|---|
| 存储方式不同（主要差异） | 二维表格式 | 存储在数据集中，就像文档、键值对或者图结构 |
| 扩展方式不同（最大的差别） | 纵向扩展，扩展CPU等性能磁盘空间 | 横向扩展，非关系型数据存储天然就是分布式的 |
| 对事物的支持不同 | 支持对事务原子性细粒度控制，并且易于回滚事务 | 稳定性方面没法和关系型数据库比较 |
| 应用场景 | 特别适合高事务性要求和需要控制执行计划的任务 | 此处会稍显弱势，其价值点在于高扩展性和大数据量处理方面 |
4. 了解 redis
Redis基于内存运行并支持持久化
采用key-value（键值对）的存储形式
Redis服务器程序是单进程模型，也就是在一台服务器上可以同时启动多个Redis进程，Redis的实际处理速度则是完全依靠于主进程的执行效率。若在服务器上只运行一个Redis进程，当多个客户端同时访问时，服务器的处理能力是会有一定程度的下降;若在同一台服务器上开启多个Redis进程，Redis在提高并发处理能力的同时会给服务器的CPU造成很大压力。即：在实际生产环境中，需要根据实际的需求来决定开启多少个Redis进程。若对高并发要求更高一些，可能会考虑在同一台服务器上开启多个进程。若CPU资源比较紧张，采用单进程即可。
5. redis 优点
（1）具有极高的数据读写速度
数据读取的速度最高可达到 110000次/s，数据写入速度最高可达到 81000次/s。
（2）支持丰富的数据类型
支持 key-value、strings、Lists、Hashes、Sets 及 Sorted Sets等数据类型操作。
（3）支持数据的持久化
可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
（4）原子性
Redis 所有操作都是原子性的。
（5）支持数据备份
即master-salve模式的数据备份。
Redis作为基于内存运行的数据库，缓存是其最常应用的场景之一。除此之外，Redis常见应用场景还包括获取最新N个数据的操作、排行榜类应用、计数器应用、存储关系、实时分析系统、日志记录。
6. redis 为什么这么快
（1）Redis是一款纯内存结构，避免了磁盘I/O等耗时操作。
（2）Redis命令处理的核心模块为单线程，减少了锁竞争，以及频繁创建线程和销毁线程的代价，减少了线程上下文切换的消耗。
（3）采用了I/O多路复用机制，大大提升了并发效率。
注：在 Redis 6.0 中新增加的多线程也只是针对处理网络请求过程采用了多线性，而数据的读写命令，仍然是单线程处理的。
二、Redis安装部署
1. 下载Redis安装包
cd /opt
ls
2. 安装Redis编译安装环境
yum -y install gcc gcc-c++ make
3. 解压 Redis 安装包
tar zxf /opt/redis-5.0.7.tar.gz -C /opt
4. 编译及安装
cd /opt/redis-5.0.7
make -j 4 && make prefix=/usr/local/redis install
5. 设置Redis服务所需要的相关配置文件
cd /opt/redis-5.0.7/utils
./install_server.sh
# 一直回车，在Please select the redis executable path时设置选择的 Redis 可执行文件路径是
/usr/local/redis/bin/redis-server
6. 配置Redis的可执行命令的环境变量
ln -s /usr/local/redis/bin/* /usr/local/bin
7. Redis 服务控制
# 当install_server.sh 脚本运行完毕，Redis 服务就已经启动，默认侦听端口为6379
netstat -natp | grep redis
# Redis服务控制
# 停止
/etc/init.d/redis_6379 stop
# 启动
/etc/init.d/redis_6379 start
# 重启
/etc/init.d/redis_6379 restart
# 状态
/etc/init.d/redis_6379 status
8. 修改配置 /etc/redis/6379.conf 参数
vim /etc/redis/6379.conf
# 70行，添加监听的主机地址
bind 127.0.0.1 192.168.23.50
# 93行，Redis默认的监听端口
port 6379
# 137行，启用守护进程
daemonize yes
# 159行，指定PID文件
pidfile /var/run/redis_6379.pid
# 167行，日志级别
loglevel notice
# 172行，指定日志文件
logfile /var/log/redis_6379.log
:wq!
# 修改配置文件之后要重启服务
/etc/init.d/redis_6379 restart
三、Redis数据库常用命令
| 工具 | 作用 |
|---|---|
| redis-server | 用于启动Redis 的工具 |
| redis-benchmark | 用于检测Redis在本机的运行效率 |
| redis-cli | Redis 命令行工具（远程登录） |
| redis-check-aof | 修复AOF持久化文件 |
| redis-check-rdb | 修复RDB持久化文件 |
1. 启动redis服务
redis-server
2. 检测Redis本机在本机的运行效率
redis-benchmark是官方自带的 Redis性能测试工具，可以有效的测试Redis服务的性能。基本的测试语法: redis-benchmark [选项] [选项值]
-h：指定服务器主机名。
-p：指定服务器端口。
-s：指定服务器socket
-c：指定并发连接数。
-n：指定请求数。
-d：以宁节的形式指定SET/GET值的数据大小。
-k：1=keep alive 0=reconnect 。
-r：SET/GET/INCR使用随机key,SADD使用随机值。
-P：通过管道传输<numreq>请求。
-q：强制退出redise_仅显示query/sec值。
--csv：以csv 格式输出。
-l：生成循环，永久执行测试。
-t：仅运行以逗号分隔的测试命令列表。
-I：Idle 模式。仅打开N个idle 连接并等待。
实例：
向IP地址为 192.168.10.23、端口为 6379的 Redis服务器发送100个并发连接与 10000个请求测试性能
redis-benchmark -h 192.168.23.50 -p 6379 -c 100 -n 100000
执行了 MSET 命令设置了 10 个键值对的情况：
- 完成了 100,000 个请求，共耗时 0.61 秒。
- 使用了 100 个并发客户端进行操作。
- 每个键值对的值大小为 3 字节。
- 设置保持活跃状态（keep alive）的时间为 1 秒。
具体的性能指标如下：
- 97.36% 的请求的响应时间在 1 毫秒以内。
- 99.99% 的请求的响应时间在 2 毫秒以内。
- 100.00% 的请求的响应时间在 2 毫秒以内。
- 平均每秒处理了约 162,866.44 个请求。
这些结果表明，在给定的条件下，Redis 服务器能够以很高的速度处理 MSET 命令请求。大部分请求的响应时间非常低，小于等于 2 毫秒。平均每秒处理了约 162,866.44 个请求，说明 Redis 具有快速的处理能力。
3. redis-cli 命令行工具
语法: redis-cli -h host -p port -a password
-h：指定远程主机
-p：指定Redis 服务的端口号
-a：指定密码，未设置数据库密码可以省略-a选项
若不添加任何选项表示，则使用127.0.0.1:6379连接本机上的 Redis 数据库
redis-cli -h 192.168.23.50 -p 6379
Redis数据库常用命令
| 命令 | 作用 |
|---|---|
| set 键 值 | 存放数据 |
| get 键 | 获取数据 |
| renamenx 旧键名 新键名 | 对已有 旧key 进行重命名，并检测新名是否存在，如果目标 新key 存在则不进行重命名。（不覆盖） |
| exists 键 | 查看键、键值是否存在 |
| dbsize | 查看键的个数 |
| config set requirepass 密码 | 设置密码 |
| config get requirepass | 查看密码 |
| select 序号 | 多数据库间切换 |
| * | 表示所有 |
| ? | 表示任意单个字符 |
| move 键 序号 | 多数据库间移动数据，将当前的库的键移到序号库 |
| flushdb | 清空当前数据库数据 |
| flushall | 清空所有数据库的数据，慎用！ |
四、Redis 优化介绍
在redis中，实现高可用的技术主要包括持久化、主从复制、哨兵和cluster集群，下面分别说明他们的作用，以及解决了什么样的问题。
持久化
持久化是最简单的高可用方法（有时甚至不被归为高可用的手段），主要作用是数据备份，即将数据存储在磁盘，保证数据不会因为进程的退出而丢失。
主从复制
主从复制是高可用redis的基础，哨兵和集群都是在主从复制基础上实现的高可用。主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障修复。
缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。
哨兵
在主从复制的基础上，哨兵实现了自动化的故障恢复。
Cluster集群
通过集群，redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。
五、Redis 持久化
1. 持久化的功能
redis是内存数据库，数据都是存储在内存中，为了避免服务器服务器断电等导致redis进程异常退出后数据的永久丢失，需要定期将redis中的数据以某种形式（数据或命令）从内存保存到硬盘；
当下次redis重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置。
2. Redis 的两种持久化方式
RDB 持久化
原理是将 Reids在内存中的数据库记录定时保存到磁盘上
AOF 持久化（append only file）
原理是将 Reids 的操作日志以追加的方式写入文件，类似于MySQL的binlog
由于AOF持久化的实时性更好，即当进程意外退出时丢失的数据更少，因此AOF是目前主流的持久化方式，不过RDB持久化仍然有其用武之地。
3. RDB 持久化
RDB持久化是指在指定的时间间隔内将内存中当前进程中的数据生成快照保存到硬盘（因此也称作快照持久化）
用二进制压缩存储，保存的文件后缀是rdb
当Redis重新启动时，可以读取快照文件恢复数据
（1）触发条件
RDB持久化的触发分为手动触发和自动触发两种
① 手动触发
save命令和bgsave命令都可以生成RDB文件。
- save 命令
save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。（因为redis是单进程的）
- bgsave 命令
而bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程（即Redis主进程）则继续处理请求。
bgsave命令执行过程中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用。
注：fork进程就是redis创建子进程过程的进程名
② 自动触发
在自动触发RDB持久化时，Redis也会选择bgsave而不是save来进行持久化。
save m n
自动触发最常见的情况是在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave。
vim /etc/redis/6379.conf
# 219行，以下三个save条件满足任意一个时，都会引起bgsave的调用
save 900 1
# 当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 300 10
# 当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
save 60 10000
# 当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave
# 254行，指定RDB文件名
dbfilename dump.rdb
# 264行，指定RDB文件和AOF文件所在目录
dir /var/lib/redis/6379
# 242行，是否开启RDB文件压缩
rdbcompression yes
③ 其他自动触发机制
除了save m n 以外，还有一些其他情况会触发bgsave
在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令，并将rdb文件发送给从节点。
执行shutdown命令时，自动执行rdb持久化。
（2）执行流程
① Redis父进程首先判断：当前是否在执行save，或bgsave/bgrewriteaof的子进程，如果在执行则bgsave命令直接返回。bgsave/bgrewriteaof的子进程不能同时执行，主要是基于性能方面的考虑： 两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。
② 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令
③ 父进程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令
④ 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换
⑤ 子进程发送信号给父进程表示完成，父进程更新统计信息
（3）启动时加载
RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更高，因此当AOF开启时，Redis会优先载入 AOF文件来恢复数据；只有当AOF关闭时， 才会在Redis服务器启动时检测RDB文件，并自动载入。服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。
Redis载入RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。
4. AOF 持久化
RDB持久化是将进程数据写入文件，而AOF持久化，则是将Redis执行的每次写、删除命令记录到单独的日志文件中，查询操作不会记录；
当Redis重启时，再次执行AOF文件中的命令来恢复数据。
与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案。
（1）开启AOF 持久化
## 开启AOF
# Redis服务器默认开启RDB，关闭RDB；要开启AOF，需要在配置文件中配置：
vim /etc/redis/6379.conf
# 700行修改，开启AOF
appendonly yes
# 704行，指定AOF文件名称
appendfilename "appendonly.aof"
# 796行是否忽略最后一条可能存在问题的指令
aof-load-truncated yes
:wq!
# 重启 redis
/etc/init.d/redis_6379 restart
（2）执行流程
由于需要记录Redis的每条写命令，因此AOF不需要触发，下面介绍AOF的执行流程。
AOF的执行流程包括：
- 命令追加(append)：将Redis的写命令追加到缓冲区aof_buf；
- 文件写入(write)和文件同步(sync)：根据不同的同步策略将aof_buf中的内容同步到硬盘；
- 文件重写(rewrite)：定期重写AOF文件，达到压缩的目的。
1）命令追加（append）
Redis先将写命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO成为Redis负载的瓶颈。
命令追加的格式是：Redis命令请求的协议格式，它是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单避免二次开销等优点。在AOF文件中，除了用于指定数据库的select命令（如select 0为选中0号数据库）是由Redis添加的，其他都是客户端发送来的写命令。
2）文件写入（write）和文件同步（sync）
Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write函数和fsync函数，说明如下：
为了提高文件写入效率，在现代操作系统中，当用户调用write函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。这样的操作虽然提高了效率，但也带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失；因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。
AOF缓存区的同步文件策略存在三种同步方式
vim /etc/redis/6379.conf
第729行
● appendfsync always[一直触发]： 命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。
● appendfsync no【不触发】 ： 命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。
● appendfsync everysec【每秒触发】： 命令写入aof_buf后调用系统write操作，write完成后线程返回；fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。
3）文件重写（rewrite）
随着时间流逝，Redis服务器执行的写命令越来越多，AOF文件也会越来越大；过大的AOF文件不仅会影响服务器的正常运行，也会导致数据恢复需要的时间过长。
文件重写是指定期重写AOF文件，减小AOF文件的体积。需要注意的是，AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件；不会对旧的AOF文件进行任何读取、写入操作!
关于文件重写需要注意的另一点是： 对于AOF持久化来说，文件重写虽然是强烈推荐的，但并不是必须的；即使没有文件重写，数据也可以被持久化并在Redis启动的时候导入；因此在一些现实中，会关闭自动的文件重写，然后通过定时任务在每天的某一时刻定时执行。
文件重写之所以能够压缩AOF文件，原因在于：
- 过期的数据不再写入文件
- 无效的命令不再写入文件：如有些数据被重复设值(set mykey v1, set mykey v2)、有些数据被删除了(set myset v1, del myset)等。
- 多条命令可以合并为一个：如sadd myset v1, sadd myset v2, sadd myset v3可以合并为sadd myset v1 v2 v3。
通过上述内容可以看出，由于重写后AOF执行的命令减少了，文件重写既可以减少文件占用的空间，也可以加快恢复速度。
文件重写的触发，分为手动触发和自动触发：
手动触发：
直接调用bgrewriteaof命令，该命令的执行与bgsave有些类似：都是fork子进程进行具体的工作，且都只有在fork时阻塞。
自动触发：
通过设置auto-aof-rewrite-min-size选项和auto-aof-rewrite-percentage选项来自动执行BGREWRITEAOF。 只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个选项同时满足时，才会自动触发AOF重写，即bgrewriteaof操作。
vim /etc/redis/6379.conf
第729行
auto-aof-rewrite-percentage 100
当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作
auto-aof-rewrite-min-size 64mb
当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF
关于文件重写的流程，有两点需要特别注意：
重写由父进程fork子进程进行；
重写期间Redis执行的写命令，需要追加到新的AOF文件中，为此Redis引入了aof_rewrite_buf缓存。
4）文件重新的流程
（1）Redis父进程首先判断当前是否存在正在执行bgsave/bgrewriteaof的子进程，如果存在则bgrewriteaof命令直接返回，如果存在 bgsave命令则等bgsave执行完成后再执行。
（2）父进程执行fork操作创建子进程，这个过程中父进程是阻塞的。
（3.1）父进程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父进程，并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制的正确。
（3.2）由于fork操作使用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令，因此Redis使用AOF重写缓冲区(aof_rewrite_buf)保存这部分数据，防止新AOF文件生成期间丢失这部分数据。也就是说，bgrewriteaof执行期间，Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区。
（4）子进程根据内存快照，按照命令合并规则写入到新的AOF文件。
（5.1）子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息，具体可以通过info persistence查看。
（5.2）父进程把AOF重写缓冲区的数据写入到新的AOF文件，这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。
（5.3）使用新的AOF文件替换老文件，完成AOF重写。
（3）启动时加载
当AOF开启时，Redis启动时会优先载入AOF文件来恢复数据；只有当AOF关闭时，才会载入RDB文件恢复数据。
当AOF开启，但AOF文件不存在时，即使RDB文件存在也不会加载。
Redis载入AOF文件时，会对AOF文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。但如果是AOF文件结尾不完整(机器突然宕机等容易导致文件尾部不完整)，且aof-load-truncated参数开启，则日志中会输出警告，Redis忽略掉AOF文件的尾部，启动成功。aof-load-truncated参数默认是开启的。
5. RDB和AOF的优缺点
（1）RDB持久化
优点：
RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AOF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小。
缺点：
RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF持久化成为主流。此外，RDB文件需要满足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。
对于RDB持久化，一方面是bgsave在进行fork操作时Redis主进程会阻塞，另一方面，子进程向硬盘写数据也会带来IO压力。
（2）AOF持久化
与RDB持久化相对应，AOF的优点在于支持秒级持久化、兼容性好，缺点是文件大、恢复速度慢、对性能影响大。对于AOF持久化，向硬盘写数据的频率大大提高(everysec策略下为秒级)，IO压力更大，甚至可能造成AOF追加阻塞问题。
AOF文件的重写与RDB的bgsave类似，会有fork时的阻塞和子进程的IO压力问题。相对来说，由于AOF向硬盘中写数据的频率更高，因此对 Redis主进程性能的影响会更大。
六、Redis 性能管理
1. 查看Redis内存使用
# 登录redis
info memory
2. 内存碎片率
操作系统分配的内存值 used_memory_rss 除以 Redis 使用的内存总量值 used_memory 计算得出。 内存值used_memory_rss 表示该进程所占物理内存的大小，即为操作系统分配给 Redis 实例的内存大小。
除了用户定义的数据和内部开销以外，used_memory_rss 指标还包含了内存碎片的开销，内存碎片是由操作系统低效的分配/回收物理内存导致的（不连续的物理内存分配）。
举例来说：
Redis 需要分配连续内存块来存储 1G 的数据集。如果物理内存上没有超过 1G 的连续内存块， 那操作系统就不得不使用多个不连续的小内存块来分配并存储这 1G 数据，该操作就会导致内存碎片的产生。
跟踪内存碎片率对理解Redis实例的资源性能是非常重要的
内存碎片率稍大于1是合理的，这个值表示内存碎片率比较低，也说明 Redis 没有发生内存交换。
内存碎片率超过1.5，说明Redis消耗了实际需要物理内存的150%，其中50%是内存碎片率。需要在redis-cli工具上输入shutdown save 命令，让 Redis 数据库执行保存操作并关闭 Redis 服务，再重启服务器。
内存碎片率低于1的，说明Redis内存分配超出了物理内存，操作系统正在进行内存交换。需要增加可用物理内存或减少 Redis 内存占用。
3. 内存使用率
redis实例的内存使用率超过可用最大内存，操作系统将开始进行内存与swap空间交换。
避免内存交换发生的方法：
针对缓存数据大小选择安装 Redis 实例
尽可能的使用Hash数据结构存储
设置key的过期时间
4. 回收key
内存清理策略，保证合理分配redis有限的内存资源。
当达到设置的最大阀值时，需选择一种key的回收策略，默认情况下回收策略是禁止删除。
配置文件中修改 maxmemory-policy 属性值：
vim /etc/redis/6379.conf
第598行
maxmemory-policy noenviction
volatile-lru：使用LRU算法从已设置过期时间的数据集合中淘汰数据(移除最近最少使用的key，
针对设置了TTL的key)
volatile-ttl：从已设置过期时间的数据集合中挑选即将过期的数据淘汰（移除最近过期的key）
volatile-random：从已设置过期时间的数据集合中随机挑选数据淘汰（在设置了TTL的key里随机移除）
allkeys-lru：使用LRU算法从所有数据集合中淘汰数据（移除最少使用的key，针对所有的key）
allkeys-random：从数据集合中任意选择数据淘汰（随机移除key）
noenviction：禁止淘汰数据（不删除直到写满时报错）
七、Redis 主从复制
1. Redis 主从复制的概念
主从复制是指：将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(Master)，后者称为从节点(Slave)；数据的复制是单向的，只能由主节点到从节点。默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。
2. Redis 主从复制的作用
数据冗余： 主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复： 当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
负载均衡： 在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
高可用基石： 除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
3. Redis 主从复制的流程
若启动一个Slave机器进程，则它会向Master机器发送一个“sync command”命令，请求同步连接。
无论是第一次连接还是重新连接，Master机器都会启动一个后台进程，将数据快照保存到数据文件中（执行rdb操作），同时Master还会记录修改数据的所有命令并缓存在数据文件中。
后台进程完成缓存操作之后，Maste机器就会向Slave机器发送数据文件，Slave端机器将数据文件保存到硬盘上，然后将其加载到内存中，接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若Slave出现故障导致宕机，则恢复正常后会自动重新连接。
Master机器收到Slave端机器的连接后，将其完整的数据文件发送给Slave端机器，如果Mater同时收到多个Slave发来的同步请求，则Master会在后台启动一个进程以保存数据文件，然后将其发送给所有的Slave端机器，确保所有的Slave端机器都正常。
主从复制、SYNC同步：
从Redis服务器启动，向主服务器发送SYNC同步数据请求
主redis会fork一个子进程，然后产生出一个RDB文件（完全备份的过程）
客户端还在持续写入redis
RDB文件持久化完后，主Redis会将RDB文件和缓存起来的命令推送给服务器
复制、推送完成后，主Redis会持续同步操作命令，利用AOF增备的部分做持久化功能
在下一台从Redis接入主从复制的集群之前，会持续利用AOF的方式同步数据给从Redis
八、Redis 主从复制的搭建
1. 环境
| 主机 | 操作系统 | IP地址 | 软件 |
|---|---|---|---|
| Master | CentOS-7 | 192.168.23.10 | redis-5.0.7.tar.gz |
| Slave1 | CentOS-7 | 192.168.23.15 | redis-5.0.7.tar.gz |
| Slave2 | CentOS-7 | 192.168.23.20 | redis-5.0.7.tar.gz |
2. 安装 Redis
Master、Slave1、Slave2都要安装Redis
# 关闭防火墙和selinux安全机制
systemctl stop firewalld
setenforce 0
# 安装依赖环境
yum install -y gcc gcc-c++ make
# 解压源码包
tar zxvf redis-5.0.7.tar.gz -C /opt/
# 编译及编译安装
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install
# 安装 redis-server
cd /opt/redis-5.0.7/utils
./install_server.sh
# 回车四次
# 出现 Please select the redis executable path []，下一步需要手动输入
/usr/local/redis/bin/redis-server
# 配置环境变量
ln -s /usr/local/redis/bin/* /usr/local/bin/
3. 修改Master节点Redis配置文件
vim /etc/redis/6379.conf
bind 0.0.0.0 # 70行，修改bind 项，0.0.0.0监听所有网段
daemonize yes # 137行，开启守护进程
logfile /var/log/redis_6379.log # 172行，指定日志文件目录
dir /var/lib/redis/6379 # 264行，指定工作目录
appendonly yes # 700行，开启AOF持久化功能
/etc/init.d/redis_6379 restart
4. 修改Slave节点 Redis 配置文件
vim /etc/redis/6379.conf
bind 0.0.0.0 #70行，修改bind 项，0.0.0.0监听所有网卡
daemonize yes #137行，开启守护进程
logfile /var/log/redis_6379.log #172行，指定日志文件目录
dir /var/lib/redis/6379 #264行，指定工作目录
replicaof 192.168.23.10 6379 #288行，指定要同步的Master节点IP和端口
appendonly yes #700行，开启AOF持久化功能
/etc/init.d/redis_6379 restart
5. 验证主从效果
进入Master节点，查看日志
tail -f /var/log/redis_6379.log
在Master节点上验证从节点
redis-cli into relication
九、Redis 哨兵模式
主从切换技术的方法是： 当服务器宕机后，需要手动一台从机换为主机，这需要人工干预，不仅费时费力而且还会造成一段时间内服务器不可用。为了解决主从复制的缺点，就有了哨兵机制。
哨兵的核心功能： 在主从复制的基础上，哨兵引入了主节点的自动故障转移
1. 哨兵模式原理
哨兵(sentinel)：是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的 Master并将所有slave连接到新的 Master。所以整个运行哨兵的集群的数量不得少于3个节点。
2. 哨兵模式的作用
监控：哨兵会不断地检查主节点和从节点是否运作正常。
自动故障转移：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其它从节点改为复制新的主节点。
通知（提醒）：哨兵可以将故障转移的结果发送给客户端。
3. 哨兵结构由两部分组成，哨兵节点和数据节点
哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。
数据节点：主节点和从节点都是数据节点。
4. 故障转移机制
（1）由哨兵节点定期监控发现主节点是否出现了故障
每个哨兵节点每隔1秒会向主节点、从节点及其它哨兵节点发送一次ping命令做一次心跳检测。如果主节点在一定时间范围内不回复或者是回复一个错误消息，那么这个哨兵就会认为这个主节点主观下线了（单方面的）。当超过半数哨兵节点认为该主节点主观下线了，这样就客观下线了。
（2）当主节点出现故障，此时哨兵节点会通过Raft算法（选举算法）实现选举机制共同选举出一个哨兵节点为leader，来负责处理主节点的故障转移和通知。所以整个运行哨兵的集群的数量不得少于3个节点。
（3）由leader哨兵节点执行故障转移，过程如下
- 将某一个从节点升级为新的主节点，让其它从节点指向新的主节点；
- 若原主节点恢复也变成从节点，并指向新的主节点；
- 通知客户端主节点已经更换。
需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。
5. 主节点的选举
（1）过滤掉不健康的（已下线的），没有回复哨兵 ping 响应的从节点。
（2）选择配置文件中从节点优先级配置最高的。（replica-priority，默认值为100）
（3）选择复制偏移量最大，也就是复制最完整的从节点。
哨兵的启动依赖于主从模式，所以须把主从模式安装好的情况下再去做哨兵模式
十、搭建 Redis 哨兵
1. 环境
| 主机 | 操作系统 | IP地址 | 软件 |
|---|---|---|---|
| Master | CentOS-7 | 192.168.23.10 | redis-5.0.7.tar.gz |
| Slave1 | CentOS-7 | 192.168.23.15 | redis-5.0.7.tar.gz |
| Slave2 | CentOS-7 | 192.168.23.20 | redis-5.0.7.tar.gz |
注：基于主从复制已搭建完成
2. 修改 Redis 配置文件
修改所有节点
systemctl stop firewalld
setenforce 0
# Redis Sentinel 是 Redis 的高可用性解决方案之一，用于监控和管理 Redis 主从集群
vim /opt/redis-5.0.7/sentinel.conf
protected-mode no # 17行，关闭保护模式
port 26379 # 21行，Redis哨兵默认的监听端口
daemonize yes # 26行，指定sentinel为后台启动
logfile "/var/log/sentinel.log" # 36行，指定日志存放路径
dir "/var/lib/redis/6379" # 65行，指定数据库存放路径
sentinel monitor mymaster 192.168.23.10 6379 2 # 84行，修改 指定该哨兵节点监控192.168.23.10:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel down-after-milliseconds mymaster 30000 # 113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 180000 # 146行，故障节点的最大超时时间为180000（180秒）
3. 启动哨兵模式
先启动Master，再启动Slave
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &
# 注意！先启动主服务器，再启动从服务器
4. 故障模拟
查看redis-server进程号
ps aux | grep redis
杀死 Master 节点上 redis-server，模拟master宕机
kill -9 13186
5. 验证结果
tail -f /var/log/sentinel.log
十一、Redis 集群模式
1. 集群概述
集群，即Redis Cluster，是Redis 3.0开始引入的分布式存储方案。
集群由多个节点(Node)组成，Redis的数据分布在这些节点中。
2. 节点
集群中的节点分为主节点和从节点：
- 只有主节点负责读写请求和集群信息的维护
- 从节点只进行主节点数据和状态信息的复制
3. 集群的作用
集群的作用，可以归纳为两点：
（1）数据分区：数据分区(或称数据分片)是集群最核心的功能。
集群将数据分散到多个节点，一方面突破了Redis单机内存大小的限制，存储容量大大增加；另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力。
Redis单机内存大小受限问题，在介绍持久化和主从复制时都有提及；例如，如果单机内存太大，bgsave和bgrewriteaof的fork操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出。
（2）高可用：
- 集群支持主从复制和主节点的自动故障转移（与哨兵类似）
- 当任一节点发生故障时，集群仍然可以对外提供服务
4. 数据分片
Redis集群的数据分片
Redis集群引入了哈希槽的概念
Redis集群有16384个哈希槽（编号0-16383）
集群的每个节点负责一部分哈希槽
每个Key通过CRC16校验后对16384取余来决定放置哪个哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作
以3个节点组成的集群为例：
- 节点A包含0到5460号哈希槽
- 节点B包含5461到10922号哈希槽
- 节点C包含10923到16383号哈希槽
5. Redis集群的主从复制模型
集群中具有A、B、C三个节点，如果节点B失败了，整个集群就会因缺少5461-10922这个范围的槽而不可以用。
为每个节点添加一个从节点A1、B1、C1整个集群便有三个Master节点和三个slave节点组成，在节点B失败后，集群选举B1位为的主节点继续服务。当B和B1都失败后，集群将不可用。
十二、搭建 Redis 集群模式
redis的集群一般需要6个节点，3主3从。方便起见，这里所有节点在同一台服务器上模拟
以端口号进行区分：3个主节点端口号：6001/6002/6003
对应的从节点端口号：6004/6005/6006
1. 环境
先搭建一台redis服务
2. 创建6台redis主机
cd /etc/redis/
mkdir -p redis-cluster/redis600{1..6}
for i in {1..6}
do
cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$i
cp /opt/redis-5.0.7/src/redis-cli /etc/redis/redis-cluster/redis600$i
cp /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
done
3. 开启群集功能
其他5个文件夹的配置文件以此类推修改，注意6个端口都要不一样
cd /etc/redis/redis-cluster/redis6001
vim redis.conf
#bind 127.0.0.1 # 69行，注释掉bind 项，默认监听所有网卡
protected-mode no # 88行，修改，关闭保护模式
port 6001 # 92行，修改，redis监听端口，
daemonize yes # 136行，开启守护进程，以独立进程启动
cluster-enabled yes # 832行，取消注释，开启群集功能
cluster-config-file nodes-6001.conf # 840行，取消注释，群集名称文件设置
cluster-node-timeout 15000 # 846行，取消注释群集超时时间设置
appendonly yes # 700行，修改，开启AOF持久化
4. 启动redis节点
分别进入那六个文件夹，执行命令：redis-server redis.conf ，来启动redis节点
cd /etc/redis/redis-cluster/redis6001
redis-server redis.conf
for d in {1..6}
do
cd /etc/redis/redis-cluster/redis600$d
redis-server redis.conf
done
ps -ef | grep redis
5. 启动集群
redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1
这个命令将使用 redis-cli 客户端来创建 Redis 集群，并指定了 6 个节点的地址。每个节点的地址由 IP 地址和端口号组成，例如 127.0.0.1:6001 表示第一个节点的地址。
--cluster-replicas 1 参数指定了副本节点的数量为 1，这意味着每个主节点都会有一个副本节点。
请注意，在执行该命令之前，您需要确保已经启动了 6 个 Redis 节点，并且节点的地址和端口号与命令中提供的一致。另外，确保 redis-cli 命令能够正确地找到并执行。
执行完命令后，Redis 集群将被创建，并且每个主节点都会自动分配一个副本节点。
六个实例分为三组，每组一主一从，前面的做主节点，后面的做从节点。下面交互的时候 需要输入 yes 才可以创建。
--replicas 1 表示每个主节点有1个从节点。
6. 测试集群
redis-cli -p 6001 -c # 加-c参数，节点之间就可以互相跳转
127.0.0.1:6001> cluster slots # 查看节点的哈希槽编号范围
