redis相关

1.redis持久化

redis有两种持久化方式：RDB和AOF，默认的是RDB

RDB

在默认的配置中，redis将内存中的数据库快照保存在dump.rdb的二进制文件中，在配置文件中可以配置两次快照的间隔。save 60 1就是在60秒内有一次改动就触发快照。也可以通过命令手动触发快照，命令分别为save和bgsave。其中save命令会阻塞其他命令，进行持久化，而bgsave会另外fork一个线程来进行持久化，只会在fork的时候短暂阻塞，但是在持久化过程中新改动的数据不会进入快照。
RDB方式的优点是，持久化生成的文件是二进制文件，当进行恢复时，很快就能将数据恢复到内存中。缺点是每次需要将所有的数据写入文件，当数据量很大的时候会很消耗性能，而且如果两次快照之间服务器宕机，会丢失数据。

AOF

在使用AOF方式时，redis每执行一次修改数据命令，都会将该命令追加到appendonly.aof文件中（先写入os cache，然后通过fsync写入磁盘）。

AOF的三种策略：

appendfsync always：每次执行写命令都会刷盘，非常慢，也非常安全。
appendfsync everysec：每秒刷盘一次，兼顾性能和安全。
appendfsync no：将刷盘操作交给系统，很快，不安全。

当需要恢复redis数据的时候，会根据.aof文件中的命令进行数据恢复。

AOF重写

因为aof文件中存储的是执行命令，所以随着时间的推移，会产生很多没用的数据，redis会定期根据最新的内存数据生成新的aof文件，我们可以通过配置控制aof文件重写的频率。

auto‐aof‐rewrite‐min‐size 64mb：	-- aof文件至少达到了64m才会触发重写
 auto‐aof‐rewrite‐percentage 100：	-- 距离上次重写增长了100%才会再次触发重写

和rdb的持久化方式一样，aof也可以手动触发（bgrewriteof）。和rdb的bgsave一样，redis也是fork一个子进程进行持久化，不会对主进程有太大的影响。

混合持久化

重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重
放，但是重放 AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很
长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。
通过如下配置可以开启混合持久化(必须先开启aof)：

 aof‐use‐rdb‐preamble yes

如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。
于是在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的AOF 全量文件重放，因此重启效率大幅得到提升。

2.redis的主从复制

Redis Replication是一种 master-slave 模式的复制机制，这种机制使得 slave 节点可以成为与 master 节点完全相同的副本，可以采用一主多从或者级联结构。主从复制的配置要点是：配从不配主。

主从复制的好处

（1）数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
（2）故障恢复：如果master宕掉了，使用哨兵模式，可以提升一个 slave 作为新的 master，进而实现故障转移，实现高可用。
（3）负载均衡：可以轻易地实现横向扩展，实现读写分离，一个 master 用于写，多个 slave 用于分摊读的压力，从而实现高并发。

主从复制的过程

简单来说，Redis主从复制的策略就是：当主从服务器刚建立连接的时候，进行全量同步；全量复制结束后，进行增量复制。slave 在任何时候都可以发起全量同步。

1.主从全量复制的流程

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份，具体步骤如下：
（1）slave服务器连接到master服务器，便开始进行数据同步，发送psync命令。
（2）master服务器收到psync命令之后，开始执行bgsave命令生成RDB快照文件并使用缓存区记录此后执行的所有写命令。

如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是每个连接都执行一次，然后再把这一份持久化的数据发送给多个并发连接的slave。
如果RDB复制时间超过60秒（repl-timeout），那么slave服务器就会认为复制失败，可以适当调节大这个参数

（3）master服务器bgsave执行完之后，就会向所有Slava服务器发送快照文件，并在发送期间继续在缓冲区内记录被执行的写命令

client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败

（4）slave服务器收到RDB快照文件后，会将接收到的数据写入磁盘，然后清空所有旧数据，在从本地磁盘载入收到的快照到内存中，同时基于旧的数据版本对外提供服务。
（5）master服务器发送完RDB快照文件之后，便开始向slave服务器发送缓冲区中的写命令。
（6）slave服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令。
（7）如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF。

增量复制

Redis的增量复制是指在初始化的全量复制并开始正常工作之后，master服务器将发生的写操作同步到slave服务器的过程，增量复制的过程主要是master服务器每执行一个写命令就会向slave服务器发送相同的写命令，slave服务器接收并执行收到的写命令。

断点续传

当master-slave网络连接断掉后，slave重新连接master时，会触发全量复制，但是从2.8版本开始，slave与master能够在网络连接断开重连后，只从中断处继续进行复制，而不必重新同步，这就是所谓的断点续传。

断电续传这个新特性使用psync命令，旧的实现中使用sync命令。Redis2.8版本可以检测出它所连接的服务器是否支持PSYNC命令，不支持的话使用SYNC命令。master服务器收到slave发送的psync命令后，会根据自身的情况做出对应的处理，可能是FULLRESYNC runid offset触发全量复制，也可能是CONTINUE触发增量复制
命令格式：psync runid offset

工作原理

（1）master服务器在内存缓冲区中给每个slave服务器都维护了一份同步备份日志（in-memory backlog），缓存最近一段时间的数据，默认大小1m，如果超过这个大小就会清理掉。

（2）同时，master 和 slave 服务器都维护了一个复制偏移量（replication offset）和 master线程ID（master run id），每个slave服务器在跟master服务器进行同步时都会携带master run id 和 最后一次同步的复制偏移量offset，通过offset可以知道主从之间的数据不一致的情况。

（3）当连接断开时，slave服务器会重新连接上master服务器，然后请求继续复制。假如主从服务器的两个master run id相同，并且指定的偏移量offset在同步备份日志中还有效，复制就会从上次中断的点开始继续。如果其中一个条件不满足，就会进行完全重新同步，因为主运行id不保存在磁盘中，如果从服务器重启的话就只能进行完全同步了。
master服务器维护的offset是存储在backlog中，msater就是根据slave发送的offset来从backlog中获取数据的
（4）在部分同步过程中，master会将本地记录的同步备份日志中记录的指令依次发送给slave服务器从而达到数据一致。

3.redis的哨兵模式