redis持久化
Redis支持两种方式的持久化，一种是RDB方式，另一种是AOF方式。前者会根据指定的规则定时将内存中的数据存储到硬盘上，后者在每次执行命令后将命令本身记录下来。
RDB方式
将某个时间点的所有数据都存放到硬盘上，如果系统发生故障，将会丢失最后一次创建快照之后的数据。如果数据量很大，保存快照的时间会很长。
Redis会在以下几种情况下对数据进行快照
根据配置规则进行自动快照
用户执行SAVE或BGSAVE命令
执行FLUSHALL命令
执行复制时
快照原理
redis使用fork函数复制当前进程的副本
原进程继续处理客户端请求，副本进程开始将内存中的数据写入硬盘中的临时文件
写完所有数据之后用临时文件替换旧的RDB文件（RDB文件存储的是fork执行那一刻的内存数据，如果中间数据修改，操作系统会将该数据复制一份以保证副本进程不受影响）
AOF方式
将写命令添加到硬盘中的 AOF 文件（Append Only File）的末尾。
使用 AOF 持久化需要设置同步选项，从而确保写命令同步到磁盘文件上的时机。这是因为对文件进行写入并不会马上将内容同步到磁盘上，而是先存储到缓冲区，然后由操作系统决定什么时候同步到磁盘。有以下同步选项：
| 选项 | 同步频率 |
|---|---|
| always | 每个写命令都同步 |
| everysec | 每秒同步一次 |
| no | 让操作系统来决定何时同步 |
always 选项会严重减低服务器的性能；
everysec 选项比较合适，可以保证系统崩溃时只会丢失一秒左右的数据，并且 Redis 每秒执行一次同步对服务器性能几乎没有任何影响；
no 选项并不能给服务器性能带来多大的提升，而且也会增加系统崩溃时数据丢失的数量。
随着服务器写请求的增多，AOF 文件会越来越大。Redis 提供了一种将 AOF 重写的特性，能够去除 AOF 文件中的冗余写命令。
redis复制
通过使用 slaveof host port 命令来让一个服务器成为另一个服务器的从服务器。一个主服务器可以有多个从服务器，而一个从服务器只能有一个主服务器。
原理
从服务器启动，向主服务器法发送SYNC命令，主服务器保存快照，并将保存快照期间接受到的命令缓存起来，然后把快照文件和缓存时的命令一并发送给从服务器
从服务器丢弃所有旧数据，载入主服务器发来的快照文件，再执行缓存时的命令
主服务器每一次执行写命令，就向从服务器发送相同的写命令（异步，故是乐观复制）
主从链
主从链是通过创建中间层来分担主服务器的复制工作。
为了降低主服务器的压力，可以让主服务器只负责写操作，而从服务器实现读操作。
无硬盘复制
开启该选项时，Redis在与从服务器进行复制初始化时不会将快照内容存储到硬盘上，而是直接通过网络发送给从数据库，避免了硬盘的性能瓶颈。
增量复制
主数据库只需将断线重连期间执行的命令传送给从数据库即可，通过积压队列和偏移量实现。
哨兵（Sentinel）
Sentinel（哨兵）可以监听集群中的服务器，并在主服务器进入下线状态时，自动从从服务器中选举出新的主服务器。
原理
每10s哨兵会向主数据库和从数据库发送info命令。（用来更新主从数据库的角色信息，只连接主数据库也能找到所有的从数据库）
每2s哨兵会向主数据库和从数据库的碰到发送自己的信息。（检测有无新的哨兵出现）
每1s哨兵向主数据库、从数据库和其他哨兵结点发送PING命令
判定服务器下线时，达到指定数量（自己设定），哨兵会认为期客观下线
选举哨兵结点恢复故障时采用Raft算法（一半的哨兵投票通过）
分片
分片是将数据划分为多个部分的方法，可以将数据存储到多台机器里面，这种方法在解决某些问题时可以获得线性级别的性能提升。
假设有 4 个 Redis 实例 R0，R1，R2，R3，还有很多表示用户的键 user:1，user:2，... ，有不同的方式来选择一个指定的键存储在哪个实例中。
最简单的方式是范围分片，例如用户 id 从 0~1000 的存储到实例 R0 中，用户 id 从 1001~2000 的存储到实例 R1 中，等等。但是这样需要维护一张映射范围表，维护操作代价很高。
还有一种方式是哈希分片，使用 CRC32 哈希函数将键转换为一个数字，再对实例数量求模就能知道应该存储的实例。
根据执行分片的位置，可以分为三种分片方式：
客户端分片：客户端使用一致性哈希等算法决定键应当分布到哪个节点。
代理分片：将客户端请求发送到代理上，由代理转发请求到正确的节点上。
服务器分片：Redis Cluster。
