集群

  • 高可用机制
    • 主从复制、
    • 哨兵模式、
    • 集群

1、什么是Redis主从复制？

是什么？

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。

主从复制的作用
  • 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
  • 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
  • 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

  • 高可用基石：主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

    过程

    主从复制过程主要可以分为3个阶段：连接建立阶段、数据同步阶段、命令传播阶段。
    连接建立阶段
    该阶段的主要作用是在主从节点之间建立连接，为数据同步做好准备。

  • 步骤1：保存主节点信息

slaveof命令是异步的，在从节点上执行slaveof命令，从节点立即向客户端返回ok，从节点服务器内部维护了两个字段，即masterhost和masterport字段，用于存储主节点的ip和port信息。

  • 步骤2：建立socket连接

从节点每秒1次调用复制定时函数replicationCron()，如果发现了有主节点可以连接，便会根据主节点的ip和port，创建socket连接。
从节点为该socket建立一个专门处理复制工作的文件事件处理器，负责后续的复制工作，如接收RDB文件、接收命令传播等。
主节点接收到从节点的socket连接后（即accept之后），为该socket创建相应的客户端状态，并将从节点看做是连接到主节点的一个客户端，后面的步骤会以从节点向主节点发送命令请求的形式来进行。

  • 步骤3：发送ping命令

从节点成为主节点的客户端之后，发送ping命令进行首次请求，目的是：检查socket连接是否可用，以及主节点当前是否能够处理请求。
从节点发送ping命令后，可能出现3种情况：
（1）返回pong：说明socket连接正常，且主节点当前可以处理请求，复制过程继续。
（2）超时：一定时间后从节点仍未收到主节点的回复，说明socket连接不可用，则从节点断开socket连接，并重连。
（3）返回pong以外的结果：如果主节点返回其他结果，如正在处理超时运行的脚本，说明主节点当前无法处理命令，则从节点断开socket连接，并重连。

  • 步骤4：身份验证

如果从节点中设置了masterauth选项，则从节点需要向主节点进行身份验证；没有设置该选项，则不需要验证。从节点进行身份验证是通过向主节点发送auth命令进行的，auth命令的参数即为配置文件中的masterauth的值。
如果主节点设置密码的状态，与从节点masterauth的状态一致（一致是指都存在，且密码相同，或者都不存在），则身份验证通过，复制过程继续；如果不一致，则从节点断开socket连接，并重连。

  • 步骤5：发送从节点端口信息

身份验证之后，从节点会向主节点发送其监听的端口号（前述例子中为6380），主节点将该信息保存到该从节点对应的客户端的slave_listening_port字段中；该端口信息除了在主节点中执行info Replication时显示以外，没有其他作用。
数据同步阶段
主从节点之间的连接建立以后，便可以开始进行数据同步，该阶段可以理解为从节点数据的初始化。具体执行的方式是：从节点向主节点发送psync命令（Redis2.8以前是sync命令），开始同步。
数据同步阶段是主从复制最核心的阶段，根据主从节点当前状态的不同，可以分为全量复制和部分复制。
命令传播阶段
数据同步阶段完成后，主从节点进入命令传播阶段；在这个阶段主节点将自己执行的写命令发送给从节点，从节点接收命令并执行，从而保证主从节点数据的一致性。
需要注意的是，命令传播是异步的过程，即主节点发送写命令后并不会等待从节点的回复；因此实际上主从节点之间很难保持实时的一致性，延迟在所难免。数据不一致的程度，与主从节点之间的网络状况、主节点写命令的执行频率、以及主节点中的repl-disable-tcp-nodelay配置等有关。

原理

当启动一个slave node的时候，它会发送一个PSYNC命令给master node
如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据; 否则如果是slave node第一次连接master node，那么会触发一次full resynchronization
开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。
slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

断点续传

从Redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份
master node会在内存中常见一个backlog，master和slave都会保存一个replica offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制
但是如果没有找到对应的offset，那么就会执行一次resynchronization。

无磁盘化复制

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了
repl-diskless-sync repl-diskless-sync-delay，等待一定时长再开始复制，因为要等更多slave重新连接过来

过期key处理

slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

由于主从延迟导致读取到过期数据怎么处理？

1、通过scan命令扫库：当Redis中的key被scan的时候，相当于访问了该key，同样也会做过期检测，充分发挥Redis惰性删除的策略。这个方法能大大降低了脏数据读取的概率，但缺点也比较明显，会造成一定的数据库压力，否则影响线上业务的效率。
2、Redis加入了一个新特性来解决主从不一致导致读取到过期数据问题，增加了key是否过期以及对主从库的判断，如果key已过期，当前访问的master则返回null；当前访问的是从库，且执行的是只读命令也返回null。

Redis主从架构数据会丢失吗，为什么？

有两种数据丢失的情况：
1、异步复制导致的数据丢失：因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了。
2、脑裂导致的数据丢失：某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着，此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master。这个时候，集群里就会有两个master，也就是所谓的脑裂。此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了。因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据。

2、哨兵模式

Redis 2.8 以后提供了 Redis Sentinel 哨兵机制来解决主节点故障问题。
其部署架构主要包括两部分：Redis Sentinel集群和Redis数据集群。
其中Redis Sentinel集群是由若干Sentinel节点组成的分布式集群，可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel的节点数量要满足2n+1（n>=1）的奇数个。

核心功能

在主从复制的基础上，哨兵引入了主节点的自动故障转移。
Sentinel 是一个管理多个 Redis 实例的工具，它可以实现对 Redis 的监控、通知、自动故障转移。
集群、事务 - 图1

原理

哨兵模式的主要作用在于它能够自动完成故障发现和故障转移，并通知客户端，从而实现高可用。哨兵模式通常由一组 Sentinel 节点和一组（或多组）主从复制节点组成。

心跳机制

（1）Sentinel与Redis Node
Redis Sentinel 是一个特殊的 Redis 节点。在哨兵模式创建时，需要通过配置指定 Sentinel 与 Redis Master Node 之间的关系，然后 Sentinel 会从主节点上获取所有从节点的信息，之后 Sentinel 会定时向主节点和从节点发送 info 命令获取其拓扑结构和状态信息。
（2）Sentinel与Sentinel
基于 Redis 的订阅发布功能， 每个 Sentinel 节点会向主节点的 sentinel：hello 频道上发送该 Sentinel 节点对于主节点的判断以及当前 Sentinel 节点的信息 ，同时每个 Sentinel 节点也会订阅该频道， 来获取其他 Sentinel 节点的信息以及它们对主节点的判断。
通过以上两步所有的 Sentinel 节点以及它们与所有的 Redis 节点之间都已经彼此感知到，之后每个 Sentinel 节点会向主节点、从节点、以及其余 Sentinel 节点定时发送 ping 命令作为心跳检测， 来确认这些节点是否可达。

故障转移

每个 Sentinel 都会定时进行心跳检查，当发现主节点出现心跳检测超时的情况时，此时认为该主节点已经不可用，这种判定称为主观下线。
之后该 Sentinel 节点会通过 sentinel ismaster-down-by-addr 命令向其他 Sentinel 节点询问对主节点的判断， 当 quorum（法定人数） 个 Sentinel 节点都认为该节点故障时，则执行客观下线，即认为该节点已经不可用。这也同时解释了为什么必须需要一组 Sentinel 节点，因为单个 Sentinel 节点很容易对故障状态做出误判。
这里 quorum 的值是我们在哨兵模式搭建时指定的，后文会有说明，通常为 Sentinel节点总数/2+1，即半数以上节点做出主观下线判断就可以执行客观下线。
因为故障转移的工作只需要一个 Sentinel 节点来完成，所以 Sentinel 节点之间会再做一次选举工作， 基于 Raft 算法选出一个 Sentinel 领导者来进行故障转移的工作。

选举方式

被选举出的 Sentinel 领导者进行故障转移的具体步骤如下：
（1）在从节点列表中选出一个节点作为新的主节点（选择标准如下）

  • 过滤不健康或者不满足要求的节点；
  • 选择 slave-priority（优先级）最高的从节点， 如果存在则返回， 不存在则继续；
  • 选择复制偏移量最大的从节点 ， 如果存在则返回， 不存在则继续；
  • 选择 runid 最小的从节点。

（2）Sentinel 领导者节点会对选出来的从节点执行 slaveof no one 命令让其成为主节点。
（3）Sentinel 领导者节点会向剩余的从节点发送命令，让他们从新的主节点上复制数据。
（4）Sentinel 领导者会将原来的主节点更新为从节点， 并对其进行监控， 当其恢复后命令它去复制新的主节点。

同步配置的时候其他哨兵根据什么更新自己的配置呢？

执行切换的那个哨兵，会从要切换到的新master（salve->master）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的。
如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch 作为新的version号。
这个version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的，其他的哨兵都是根据版本号的大小来更新自己的master配置的。

为什么Redis哨兵集群只有2个节点无法正常工作？

哨兵集群必须部署2个以上节点。
如果两个哨兵实例，即两个Redis实例，一主一从的模式。
则Redis的配置quorum=1，表示一个哨兵认为master宕机即可认为master已宕机。
但是如果是机器1宕机了，那哨兵1和master都宕机了，虽然哨兵2知道master宕机了，但是这个时候，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2个哨兵都运行着，就可以允许执行故障转移。
但此时哨兵1没了就只有1个哨兵了了，此时就没有majority来允许执行故障转移，所以故障转移不会执行。

高可用怎么实施？

使用官方推荐的哨兵(sentinel)机制就能实现，当主节点出现故障时，由Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。它有四个主要功能：

  • 集群监控，负责监控Redis master和slave进程是否正常工作。
  • 消息通知，如果某个Redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
  • 故障转移，如果master node挂掉了，会自动转移到slave node上。

  • 配置中心，如果故障转移发生了，通知client客户端新的master地址。

    优缺点：

    优点：

  • Redis Sentinel集群部署简单；

  • 能够解决Redis主从模式下的高可用切换问题；
  • 很方便实现Redis数据节点的线形扩展，轻松突破Redis自身单线程瓶颈，可极大满足Redis大容量或高性能的业务需求；
  • 可以实现一套Sentinel监控一组Redis数据节点或多组数据节点。

缺点：

  • 部署相对Redis主从模式要复杂一些，原理理解更繁琐；
  • 资源浪费，Redis数据节点中slave节点作为备份节点不提供服务；
  • Redis Sentinel主要是针对Redis数据节点中的主节点的高可用切换，对Redis的数据节点做失败判定分为主观下线和客观下线两种，对于Redis的从节点有对节点做主观下线操作，并不执行故障转移。
  • 不能解决读写分离问题，实现起来相对复杂。

    3、cluster集群的原理

    引入原因：
    不管是主从模式还是哨兵模式都只能由一个master在写数据，在海量数据高并发场景，一个节点写数据容易出现瓶颈，引入Cluster模式可以实现多个节点同时写数据。
    解决Redis分布式方面的需求,例如当遇到单机内存，并发和流量等瓶颈的时候，Redis Cluster能起到很好的负载均衡的目的。
    结构
    Redis-Cluster采用无中心结构，每个节点都保存数据，节点之间互相连接从而知道整个集群状态。
    集群、事务 - 图2

如图所示Cluster模式其实就是多个主从复制的结构组合起来的，每一个主从复制结构可以看成一个节点，那么上面的Cluster集群中就有三个节点。

特点
  • 多主多从，去中心化：从节点作为备用，复制主节点，不做读写操作，不提供服务
  • 不支持处理多个key：因为数据分散在多个节点，在数据量大高并发的情况下会影响性能；
  • 支持动态扩容节点：这是我认为算是Rerdis Cluster最大的优点之一；

  • 节点之间相互通信，相互选举，不再依赖sentinel：准确来说是主节点之间相互“监督”，保证及时故障转移

    区别

  • 相比较sentinel模式，多个master节点保证主要业务（比如master节点主要负责写）稳定性，不需要搭建多个sentinel实例监控一个master节点；

  • 相比较一主多从的模式，不需要手动切换，具有自我故障检测，故障转移的特点；
  • 相比较其他两个模式而言，对数据进行分片（sharding），不同节点存储的数据是不一样的；
  • 从某种程度上来说，Sentinel模式主要针对高可用（HA），而Cluster模式是不仅针对大数据量，高并发，同时也支持HA。
    数据分片
    Redis Cluster在设计中没有使用一致性哈希（Consistency Hashing），而是使用数据分片引入哈希槽（hash slot）来实现；
    Redis Cluster集群节点最小配置6个节点以上（3主3从），其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。
    Redis Cluster采用虚拟槽分区，所有的键根据哈希函数映射到0～16383个整数槽内，每个节点负责维护一部分槽以及槽所印映射的键值数据。
    过程
    Redis cluster有固定的16384个hash slot（哈希槽），对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot。
    Redis cluster中每个master都会持有部分slot（槽），比如有3个master，那么可能每个master持有5000多个hash slot。
    hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去。每次增加或减少master节点都是对16384取模，而不是根据master数量，这样原本在老的master上的数据不会因master的新增或减少而找不到。并且增加或减少master时Redis cluster移动hash slot的成本是非常低的。
    为什么是16384？
    在redis节点发送心跳包时需要把所有的槽信息放到这个心跳包里，以便让节点知道当前集群信息，在发送心跳包时使用char进行bitmap压缩后是2k（16384÷8÷1024=2kb），也就是说使用2k的空间创建了16k的槽数。
    虽然使用CRC16算法最多可以分配65535（2^16-1）个槽位，65535=65k，压缩后就是8k（8 8 (8 bit) 1024(1k) = 8K），也就是说需要需要8k的心跳包，作者认为这样做不太值得；并且一般情况下一个redis集群不会有超过1000个master节点，所以16k的槽位是个比较合适的选择。
    (1)如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
    如上所述，在消息头中，最占空间的是myslots[CLUSTER_SLOTS/8]。
    当槽位为65536时，这块的大小是:65536÷8÷1024=8kb
    因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，浪费带宽。
    (2)redis的集群主节点数量基本不可能超过1000个。
    如上所述，集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者，不建议redis cluster节点数量超过1000个。
    那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。
    (3)槽位越小，节点少的情况下，压缩率高
    Redis主节点的配置信息中，它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中，会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。
    如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。
    节点之间怎么通信？
    Redis cluster节点间采取gossip协议进行通信。
    所有节点都持有一份元数据，不同的节点如果出现了元数据的变更，则更改节点会把数据不断地发送给其他节点让其他节点进行数据变更。通过节点互相之间不断通信来保持整个集群所有节点的数据是完整的。
    主要交换故障信息、节点的增加和移除、hash slot信息等。
    好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力;
    缺点则是元数据更新有延时，可能导致集群的一些操作会有一些滞后。
    数据倾斜问题
    数据分布不均匀，虚拟节点机制。

事务

1、事务机制

Redis事务生命周期：

  • 开启事务：使用MULTI开启一个事务
  • 命令入队列：每次操作的命令都会加入到一个队列中，但命令此时不会真正被执行

  • 提交事务：使用EXEC命令提交事务，开始顺序执行队列中的命令。

    2、是原子性的吗？

    关系型数据库认为原子性：一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复(Rollback)到事务开始前的状态，就像这个事务从来没有执行过一样。
    而官方认为事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。EXEC 命令负责触发并执行事务中的所有命令：如果客户端在使用 MULTI 开启了一个事务之后，却因为断线而没有成功执行 EXEC ，那么事务中的所有命令都不会被执行。另一方面，如果客户端成功在开启事务之后执行 EXEC ，那么事务中的所有命令都会被执行。
    官方认为Redis事务是一个原子操作，这是站在执行与否的角度考虑的。但是从ACID原子性定义来看，严格意义上讲Redis事务是非原子型的，因为在命令顺序执行过程中，一旦发生命令执行错误Redis是不会停止执行然后回滚数据。

    3、为什么不支持回滚roll back？

    在事务运行期间虽然Redis命令可能会执行失败，但是Redis依然会执行事务内剩余的命令而不会执行回滚操作。
    redis只发现语法问题，在放入事务队列时就会被发现，并且执行失败，获知对某个键执行不符合其数据类型的操作。只有程序错误才会导致。
    Redis的设计目标是功能简化及确保更快的运行速度。支持事务回滚能力会导致设计复杂，这与Redis的初衷相违背。
    对于bug，其实回归并不能解决。官方在设计Redis时选用更加简单和快速的方法，没有实现回滚的机制。

    4、事务失败的场景

    有三种类型的失败场景：
    （1）在事务提交之前，客户端执行的命令缓存（队列）失败，比如命令的语法错误(命令参数个数错误，不支持的命令等等)。如果发生这种类型的错误，Redis将向客户端返回包含错误提示信息的响应，同时Redis会清空队列中的命令并取消事务。
    （2）事务提交后开始顺序执行命令，之前缓存在队列中的命令有可能执行失败。
    （3）由于乐观锁失败，事务提交时将丢弃之前缓存的所有命令序列。通过开启两个redis客户端并结合watch命令模拟这种失败场景。
    在事务过程中监控的key被其他客户端改变，则当前客户端的乐观锁失败，事务提交时将丢弃所有命令缓存队列。

    5、相关命令

    （1）WATCH
    可以为Redis事务提供 check-and-set （CAS）行为。被WATCH的键会被监视，并会发觉这些键是否被改动过了。如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回nil-reply来表示事务已经失败。
    （2）MULTI
    用于开启一个事务，它总是返回OK。MULTI执行之后,客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行，而是被放到一个队列中，当 EXEC命令被调用时， 所有队列中的命令才会被执行。
    （3）UNWATCH
    取消 WATCH 命令对所有 key 的监视，一般用于DISCARD和EXEC命令之前。如果在执行 WATCH 命令之后， EXEC 命令或 DISCARD 命令先被执行了的话，那么就不需要再执行 UNWATCH 了。因为 EXEC 命令会执行事务，因此 WATCH 命令的效果已经产生了；而 DISCARD 命令在取消事务的同时也会取消所有对 key 的监视，因此这两个命令执行之后，就没有必要执行 UNWATCH 了。
    （4）DISCARD
    当执行 DISCARD 命令时， 事务会被放弃， 事务队列会被清空，并且客户端会从事务状态中退出。
    （5）EXEC
    负责触发并执行事务中的所有命令：
    如果客户端成功开启事务后执行EXEC，那么事务中的所有命令都会被执行。
    如果客户端在使用MULTI开启了事务后，却因为断线而没有成功执行EXEC,那么事务中的所有命令都不会被执行。需要特别注意的是：即使事务中有某条/某些命令执行失败了，事务队列中的其他命令仍然会继续执行，Redis不会停止执行事务中的命令，而不会像我们通常使用的关系型数据库一样进行回滚。

    6、事务ACID

  • 原子性（Atomicity）

原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。

  • 一致性（Consistency）

事务前后数据的完整性必须保持一致。

  • 隔离性（Isolation）

多个事务并发执行时，一个事务的执行不应影响其他事务的执行

  • 持久性（Durability）

持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响
Redis的事务总是具有ACID中的一致性和隔离性，其他特性是不支持的。当服务器运行在AOF持久化模式下，并且appendfsync选项的值为always时，事务也具有耐久性。

7、事务的其他实现

  • 基于Lua脚本，Redis可以保证脚本内的命令一次性、按顺序地执行，
    其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是会继续运行完
  • 基于中间标记变量，通过另外的标记变量来标识事务是否执行完成，读取数据时先读取该标记变量判断是否事务执行完成。但这样会需要额外写代码实现，比较繁琐