Redis的五件小事，Redis保证高并发及高可用

如果采用这种主从架构，那么必需要开启主节点的持久化，如果用从节点做热点备份，如果主节点宕机，那么主节点的数据就会丢失。如果恢复主节点后，主节点的数据就是空的，从节点复制主节点的数据就会是空的，这样的话，所有节点的数据都会丢失。要对备份文件做多种冷备份，防止整个机器坏了，备份的rdb数据也丢失的情况。

Redis主从复制原理，断点续传，无磁盘化复制，过期key处理。

主从复制原理

当启动一个从节点的时候，他会发送一个PSYNC（部分同步）命令给主节点
如果这个从节点是重新连接主节点，那么主节点仅复制从节点缺失的部分数据，如果是第一次连接主节点，那么就会触发一次full resynchronization(完全重新同步)
开始full resynchronization的时候，主节点会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端接收到的所有写命令缓存在内存当中
主节点将生成的RDB文件送给从节点，从节点写入到本地磁盘，然后再从磁盘中加载到内存当中。然后主节点会将缓存的写命令发送给从节点，从节点也会同步这份数据
从节点跟主节点因为网络故障断开连接，会自动重连
主节点发现有多个从节点来重新连接，仅仅会启动一个rdb save操作(根据主节点生成一份rdb快照文件)，用一份的数据服务所有的从节点。

主从复制的断点续传

从redis2.8开始支持断点续传，如果在主从复制的过程中，网络突然撕掉了，那么可以接着上次复制的地方，继续复制，而不是从头复制一份。

原理

主节点会在内存中创建一个backlog，主节点和从节点都会保存一个replica offset(偏移量)还有一个master id,offset就保存在backlog中，如果主节点和从节点网络连接断掉了，从节点会让主节点从上次的replica offset 开始继续复制。但是如果没有找到offset，就会执行一次full resynchronization操作

无磁盘化复制

无磁盘化复制是指主节点直接创建RDB快照文件发送给从节点，不会在自己本地磁盘保存数据

设置方式

配置repl-diskless-sync和repl-diskless-sync-deplay参数

repl-diskless-sync:该参数保证进行无磁盘化复制

repl-diskless-sync-delay：该参数表示等待一定时常在开始复制，这样可以等待多个从节点重新连接上来。

过期key处理

从节点不会过期key，，只有等待master过期key

如果主节点过期了一个key，或者淘汰了一个key，那么主节点会模拟发送一条del指令给从节点，从节点接收到之后会删除该key

Redis replication的完整的运行流程和原理的再次深入剖析

复制的完整流程

从节点启动，保存了主节点的信息，但是数据复制还没有开始，主节点的ip和端口保存在redis.conf里的slaveOf中配置的
从节点内部有一个定时任务，每秒检查是否有新的主节点需要连接复制，如果有，就会与主节点建立socket网络连接
从节点发送一个ping命令给主节点
如果主节点设置了requirepass(这个参数用来设置密码)，那么从节点必须发送master auth口令进行口令验证
主节点第一次执行全量复制，将所有数据发送给slave node
主节点持续接收写命令，异步复制给从节点

数据同步机制

指的是从节点第一次连接主节点的情况，执行的是全量复制

1.从节点和主节点都会维护一个offset

master会在自身不断累加offset，salve也会在自身不断累加offset，从节点每秒都会上报自己的offset给主节点，同时，主节点也会保存从节点的offset

这个倒不是说特定用在全量复制的，主要是主节点和从节点都要知道各自的数据的offset，才能知道互相之间的数据不一致的情况。

2.backlog

主节点会有一个backlog在内存中，默认是1m

主节点在给从节点复制数据时，通常会将数据保存在backlog中一份

backlog主要是在做全量复制中断时的增量复制的

Master run id

Redis可以通过info server来查看master run id

用途:从节点根据其来定位唯一的主节点

为什么不用host+ip:因为使用host+ip来定位主节点是不靠谱的，如果主节点重启或数据出现了变化，那么从节点就会根据不同的master run id进行区分，run id不同就需要进行一次全量复制。

如果需要不更改run id重启redis，可以使用redis-cli debug reload命令。

全量复制流程与机制

主节点执行bgsave命令，生成RDB快照
主节点将RDB快照发送给从节点，如果RDB文件的复制时间超过60秒(repl-timeout),那么从节点任务就会复制失败，可以适当调整这个参数
对于千兆网卡的机器，一般每秒传输100M(1000Mbps = 125MBps, 1Mbps = 0.125MBps不算网络阐述损耗的话)，传输6G的文件很可能超过60秒
主节点在生成RDB文件的同时，会将接收到的写命令缓存在内存中，在从节点保存了RDB文件之后，再将这些命令复制到从节点
查看client-output-buffer-limit salve参数，比如[client-output-buffer-limit slave 256MB 64MB 60],表示在复制期间，内存缓存持续消耗超过64M，或者一次性超过256M,那么停止复制，复制失败
从节点接收到RDB文件后，清空自己的数据，然后重新加载RDB文件到内存中，这个过程，从节点基于旧数据对外提供服务
如果从节点开启了AOF，那么会立即执行BRREWRITEAOF命令，重新生成AOF

rdb生成，rdb通过网络拷贝，从节点旧数据清理，从节点重新开启AOF，都很耗费时间

如果复制的数据量在4g-6g之间，那么很可能全量复制时间消耗到1分半到两分钟

PS:

上面第5点：

client-output-buffer-limit:这个参数，用于控制在复制过程中，主节点向从节点发送数据的速率和缓冲区大小

Client-output-buffer-limit salve:指定了对从节点的输出缓冲区的限制

256MB:表示从节点的输出缓冲区的硬限制大小，即一次性发送的数据不能超过256MB

64MB:表示从节点输出缓冲区的软限制大小，当从节点的输出缓冲区的数据超过这个值时，主节点会停止发送数据给从节点，直到缓冲区中的数据低于该值

60：表示软限制触发的时间(单位为秒),当从节点的输出缓冲区持续超过软限制的时间，主节点会停止发送数据给从节点，直到缓冲区的数据低于该限制

因此，如果在复制期间，从节点的输出持续消耗超过64MB的空间，或者一次性消耗超过256MB的空间，那么主节点会停止向从节点发送数据，从而导致复制失败，这有助于避免从节点处理能力不足，造成数据堆积和丢失的情况。

上面第2点：

如果主节点将RDB快照文件发送给从节点，但复制过程的时间超过了配置的复制超时时间(repl-timeout),那么从节点会认为复制失败。

默认情况下，repl-timeout的默认值是60秒，如果复制操作未在这个时间内完成，从节点会认为主节点无法提供数据，从而停止复制，并记录相应的日志信息。

可以通过调整配置文件的repl-timeout参数来调整复制超时时间，使其适应你的特定需求。例如，将他增加到更长的时间以容忍更长的网络延迟或大型数据传输时间。但是，需要谨慎调整这个值，以确保不会导致复制过程太长而影响系统的稳定性和可用性

增量复制流程与机制

如果全量复制过程中，master和slave网络连接断掉，那么从节点连接主节点就会触发增刊复制

主节点直接从自己的backlog中获取部分丢失数据，发送给从节点

主节点就是根据从节点发送的psync中的offset来从backlog中获取数据的

心跳

主节点和从节点互相都会发送heartbeat信息

主节点默认每隔10s发送一次，从节点默认每隔1s发送一次

异步复制

主节点每次接收到写命令之后，先在内部写入数据，然后异步发送给从节点

Redis主从架构下如何才能做到99.99%的高可用性？

高可用性(英语： high availability,缩写为HA),IT术语，指系统无中断地执行其功能的能力，代表系统的可用性程度。是进行系统设计时的准则之一。高可用性系统与构成该系统的各个组件相比可以更长时间运行。

高可用性通常通过提高系统的容错能力来实现。定义一个系统怎样才算具有高可用性往往需要根据每一个案例的具体情况来具体分析

其度量方式，是根据系统损害，无法使用的时间，以及由无法运作恢复到可运作状况的时间，与系统总运作时间的比较。计算公式为：

A（可用性),MTBF(平均故障间隔),MDT(平均修复时间)

在线系统和执行关键任务的系统通常要求其可用性要达到5个9标准(99.999%)

Redis不可用

redis不可用包含了redis单例不可用，主从架构不可用

不可用情况：

主从架构的主节点挂了，如果主节点挂了那么缓存数据就无法写入，从节点里的数据也就无法过期，这样就导致了不可用。

如果是单实例，那么有可能redis进程死了，或者部署redis的机器坏了。

不可用后果：

首先缓存不可用了，那么请求就会直接走数据库，如果涌入大量请求超过了数据库的承载能力，那么数据库就挂掉了，这时候如果不能及时处理好缓存问题，那么由于请求过多，数据库重启之后就又会挂掉，直接导致整个系统不可用。

如何实现高可用

保证每个redis都有备份
保证在当前redis出故障后，可以很快切换到备份redis上面去。

为了解决这个问题，引入下面的哨兵机制

redis哨兵架构的相关基础知识的讲解

什么是哨兵？

哨兵(Sentinal)是redis集群架构当中非常重要的一个组件，它主要有以下功能：

集群监控：负责监控主节点和从节点是否正常工作

消息通知：如果某个redis故障了，那么哨兵负责发送消息作为报警通知给管理员

故障转移：如果主节点挂了，会自动转移到从节点

配置中心：如果故障发生了，会通知客户端连接到新的主节点上

哨兵的核心知识

哨兵本身是分布式的，需要作为一个集群去运行，每个哨兵协同工作

故障转移时，判断一个主节点宕机了，需要大部分哨兵同意才行

即使部分哨兵挂掉了，哨兵集群还是能正常工作的

哨兵至少需要3个实例，来保证自己的健壮性

哨兵+redis主从架构，是无法保证数据零丢失的，只会保证redis集群的高可用

对应哨兵+redis主从这种架构，在使用之前，要做重复的测试和演练。

为什么哨兵集群部署2个节点无法正常工作？

哨兵集群必须部署两个以上的节点，如果集群仅仅部署了两个哨兵实例，那么quorum=1(执行故障转移需要统一的哨兵个数)

如图，如果这时候master1宕机了，哨兵1和哨兵2中只要有一个认为master1宕机了就可以进行故障转移，同时哨兵1和哨兵2会选举出一个哨兵来进行故障转移。
同时这个时候需要majority(也就是所有集群中超过一半哨兵的数量),2个哨兵那么majority就是2，也就是说至少两个哨兵还运行着，才可以进行故障转移。
但是如果整个master1和哨兵1同时宕机了，那么就只剩下一个哨兵了，这个时候就没有majority来运行故障转移了，虽然另外一台机器还有一个哨兵，但是1无法大于1，也就是无法保证半数以上，因此故障转移不会执行。

经典的3节点哨兵集群

Configuration:quorum = 2,majority=2

如果M1所在机器宕机了，那么三个哨兵还剩下两个，s2和s3可以一致认为master宕机，然后选举出一个来执行故障转移

同时3个哨兵的majority是2，所以还剩下两个哨兵运行着，就可以运行执行故障转移

Redis哨兵主备切换的数据丢失问题：异步复制，集群脑裂

两种数据丢失的场景

异步复制导致的数据丢失

因为主节点和从节点之间数据复制是异步的，这时候如果主节点宕机，数据还没有复制完成，就会导致数据丢失

集群脑裂导致的数据丢失

什么是脑裂：也就是说，某个主节点所在机器突然脱离了正常的网络，跟其他从节点不能连接，但是实际上主节点还运行着。

此时哨兵可能就会认为主节点宕机了，然后开启选举，将其他从节点换成主节点
这个时候，集群中就会有两个master，也就是所谓的脑裂。
此时虽然某个从节点被切换成了主节点，但是客户端还没来得及切换到新的master，这时候会继续向旧的master节点写入数据，这些数据就丢失了
因此旧master再次恢复的时候，会被作为一个从节点挂载到新的主节点上，自己的数据就会清空，重新从新的主节点复制数据。

解决异步复制的脑裂导致的数据丢失

要解决这个问题，就需要配置两个参数：

Min-slaves-to-write 1和min-slaves-max-lag:

表示要求至少有一个从节点在进行数据的复制和同步的延迟不能超过10秒

如果一旦从节点数据同步和复制的延迟都超过了10秒，那么这个时候，主节点就不会再接收任何请求了。

减少异步复制数据丢失

有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能主节点宕机后损失的数据太多了，那么就拒绝写请求，这样可以把主节点宕机时由于部分数据未同步到从节点导致的数据丢失降低到可控范围内

减少脑裂的数据丢失

如果一个主节点出现了脑裂，跟其他从节点丢失了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的从节点发送数据，而且从节点超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求。这样脑裂后的旧主节点就不会接收客户端的新数据，也就避免了数据丢失。

上面的配置就确保了，如果跟任何一个从节点丢了连接，在10秒后发现从节点没有给自己ack，那么就拒绝新的请求。

因此在脑裂场景下，最多丢失10秒的数据。

redis哨兵的多个核心底层原理的深入解析(包含从节点选举算法)

sdown和odown两种状态

sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机
odown是客观宕机，如果quorum(执行故障转移需要的哨兵个数)数量的哨兵都觉得一个主节点宕机了，那么就是客观宕机
sdown达成的条件很简单，如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为主节点宕机了。
sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个主节点是sdown了，那么就认为是odown了，客观认为主节点宕机