深入理解Redis、主从

一、redis简介

redis是具有原子性的，在读写的操作时由一个线程完成，但redis在持久化、异步删除、集群同步时是由额外线程执行的。redis读写速度快，主要原因是数据都存储在内存中，所有的运算都是内存级别的，并且由一个线程完成，避免了线程切换的消耗。

redis在处理并发客户端连接请求时，采用I/O多路复用的策略，将连接信息和队列依次放到队列中，然后依次放入文件事件分派器中，然后依次交给事件处理器处理。在事件处理器处理事件时，队列和事件分派器仍然在读取其他事件，高效利用redis服务器的处理能力。如图：

Info可查看redis服务运行信息，分为 9 大块，每个块都有非常多的参数，这 9 个块分别是:

• Server 服务器运行的环境参数
• Clients 客户端相关信息
• Memory 服务器运行内存统计数据
• Persistence 持久化信息
• Stats 通用统计数据
• Replication 主从复制相关信息
• CPU CPU 使用情况
• Cluster 集群信息
• KeySpace 键值对统计数量信息

二、redis持久化

redis持久化有两种方式：RDB和AOF。在4.0之后，支持混合持久化（基于AOF）。

RDB：可以通过设置save 60 1000来触发RDB的规则。也可以通过令save或bgsave命令来触发。bgsave为写实复制技术（Copy-On-Write），在备份时采用其他线程来备份数据，并不影响主线程的读写，但是会存在更多的内存消耗。很明显RDB方式在机器故障时，会丢失一部分数据。

AOF：该方式为将修改的每一条指令记录到aof文件中（其实是先写到os cache中，根据设置每隔一段时间异步写入到磁盘中）。生产上一般采用appendfsync everysec（每秒写入依次的方式）。

AOF会导致磁盘文件过大的问题，一般会采用

auto‐aof‐rewrite‐min‐size 64mb //超过64M触发重写
auto‐aof‐rewrite‐percentage 100 //增长了100%则再次触发重写

混合持久化：如果开启的该模式，在触发AOF时，会生成一个RDB快照，将快照的内容以二进制的方式存在AOF文件中，然后再紧接着写入AOF的RESP命令，大大缩小文件大小。于是在redis重启恢复数据时，效率大大提升。

三、redis主从、哨兵

主从工作原理：当master配置了一个slave，不管从节点是否第一次连接master，都会发送一个命令请求复制数据。当master收到命令时，会用bgsave异步生成一个RDB快照文件，在此期间主节点修改的数据集会缓存到内存中，当slave持久化完RDB文件后，再将RDB初始化到内存中，进而接受在此期间主节点缓存到内存中修改的数据集。注意：多个slave发起多个请求并不会使主节点生成多个快照文件，而是将一个RDB快照发送给其他的从节点。如图：

 在redis2.8之后，如果slave断开重连之后，采用的是断点续传的方式，而不是全量传输。实现方式是slave会发起一个带有偏移量offset和masterID的备份请求，但是如果maserId发生变化时，也会是全量复制。

哨兵工作原理：哨兵是一种redis的特殊服务，相当于监控redis主从的健康状态。哨兵架构下，当第一次从sentinel发现主节点后，后续就直接访问主节点，而不是每次都通过sentinel来访问主节点。当主节点变动时，sentinel会第一时间感知到，这时会将新的主节点推送给其他redis的client端。哨兵模式的工作原理图为：