Redis集群

脑裂：指由于网络分区或者硬件故障等原因，导致 Redis 集群中的节点互相失去连接，出现多个主节点为客户提供写服务，这种情况下可能会导致数据丢失；场景一
    在哨兵进行选举，故障转移的过程中，原主节点恢复和客户端的通信，这时客户端依旧可以向原主节点正常通信，这就是脑裂产生的第一个场景。

场景二

　　网络分区，主节点和客户端，哨兵和从库分割为了两个网络，主库和客户端处在一个网络中，从库和哨兵在另外一个网络中，此时哨兵也会发起主从切换，出现两个主节点的情况。

脑裂带来的影响

    脑裂出现后带来最严重的后果就是数据丢失，为什么会出现数据丢失的问题呢，主要原因是新主库确定后会向所有的实例发送slave of命令，让所有实例重新进行全量同步，而全量同步首先就会将实例上的数据先清空，所以在主从同步期间在原主库执行的命令将会被清空（在网络分区恢复后原主节点将被降级为从节点，并且执行全量同步导致数据丢失），所以这就是数据丢失的具体原因。

sentinel可以防止脑裂吗？

　　脑裂的主要原因其实就是哨兵集群认为主节点已经出现故障了，重新选举其它从节点作为主节点，而原主节点其实是假故障，从而导致短暂的出现两个主节点，那么在主从切换期间客户端一旦给原主节点发送命令，就会造成数据丢失。

所以应对脑裂的解决办法应该是去限制原主库接收请求，Redis提供了两个配置项。

可以通过配置下面两个字段来尽量规避脑裂：

　　①min-replicas-to-write：表示master必须至少写入slave的数量，否则就停止接收新的写请求；

　　②min-replicas-max-lag：表示当master经过多长时间得不到slave的响应时，就认为这个slave失联，停止接收新的写请求；

在假故障期间，通常都会出现master写入salve数量不达标或是有slave失联的情况，此时主节点拒绝写入，就可以避免脑裂造成的数据丢失问题；

　　不能完全避免脑裂，要想完全解决问题需要引入redis cluster集群；

Redis集群的主从复制模型是怎样的？

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

主从复制的作用主要包括：

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

主从库之间采用的是读写分离的方式。

  • 读操作：主库、从库都可以接收；
  • 写操作：首先到主库执行，然后，主库将写操作同步给从库。

注意：在2.8版本之前只有全量复制，而2.8版本后有全量和增量复制：

  • 全量（同步）复制：比如第一次同步时
  • 增量（同步）复制：只会把主从库网络断连期间主库收到的命令，同步给从库

Redis 全量复制的三个阶段？

第一阶段是主从库间建立连接、协商同步的过程，主要是为全量复制做准备。在这一步，从库和主库建立起连接，并告诉主库即将进行同步，主库确认回复后，主从库间就可以开始同步了。
　　具体来说，从库给主库发送 psync 命令，表示要进行数据同步，主库根据这个命令的参数来启动复制。psync 命令包含了主库的 runID 和复制进度 offset 两个参数。runID，是每个 Redis 实例启动时都会自动生成的一个随机 ID，用来唯一标记这个实例。当从库和主库第一次复制时，因为不知道主库的 runID，所以将 runID 设为“？”。offset，此时设为 -1，表示第一次复制。主库收到 psync 命令后，会用 FULLRESYNC 响应命令带上两个参数：主库 runID 和主库目前的复制进度 offset，返回给从库。从库收到响应后，会记录下这两个参数。这里有个地方需要注意，FULLRESYNC 响应表示第一次复制采用的全量复制，也就是说，主库会把当前所有的数据都复制给从库。
第二阶段，主库将所有数据同步给从库。从库收到数据后，在本地完成数据加载。这个过程依赖于内存快照生成的 RDB 文件。具体来说，主库执行 bgsave 命令，生成 RDB 文件，接着将文件发给从库。
　　从库接收到 RDB 文件后，会先清空当前数据库，然后加载 RDB 文件。这是因为从库在通过 replicaof 命令开始和主库同步前，可能保存了其他数据。为了避免之前数据的影响，从库需要先把当前数据库清空。在主库将数据同步给从库的过程中，主库不会被阻塞，仍然可以正常接收请求。否则，Redis 的服务就被中断了。但是，这些请求中的写操作并没有记录到刚刚生成的 RDB 文件中。为了保证主从库的数据一致性，主库会在内存中用专门的 replication buffer，记录 RDB 文件生成后收到的所有写操作。
第三个阶段，主库会把第二阶段执行过程中新收到的写命令，再发送给从库。具体的操作是，当主库完成 RDB 文件发送后，就会把此时 replication buffer 中的修改操作发给从库，从库再重新执行这些操作。这样一来，主从库就实现同步了。

Redis 增量复制的流程？

repl_backlog_buffer：它是为了从库断开之后，如何找到主从差异数据而设计的环形缓冲区，从而避免全量复制带来的性能开销。如果从库断开时间太久，repl_backlog_buffer环形缓冲区被主库的写命令覆盖了，那么从库连上主库后只能乖乖地进行一次全量复制，所以repl_backlog_buffer配置尽量大一些，可以降低主从断开后全量复制的概率。而在repl_backlog_buffer中找主从差异的数据后，如何发给从库呢？这就用到了replication buffer。
replication buffer：Redis和客户端通信也好，和从库通信也好，Redis都需要给分配一个 内存buffer进行数据交互，客户端是一个client，从库也是一个client，我们每个client连上Redis后，Redis都会分配一个client buffer，所有数据交互都是通过这个buffer进行的：Redis先把数据写到这个buffer中，然后再把buffer中的数据发到client socket中再通过网络发送出去，这样就完成了数据交互。
　　　　　　　　　　所以主从在增量同步时，从库作为一个client，也会分配一个buffer，只不过这个buffer专门用来传播用户的写命令到从库，保证主从数据一致，我们通常把它叫做replication buffer。

Redis 为什么会设计增量复制？

　　如果主从库在命令传播时出现了网络闪断，那么，从库就会和主库重新进行一次全量复制，开销非常大。从 Redis 2.8 开始，网络断了之后，主从库会采用增量复制的方式继续同步。

增量复制如果在网络断开期间，repl_backlog_size环形缓冲区写满之后，从库是会丢失掉那部分被覆盖掉的数据，还是直接进行全量复制呢？

  1. 一个从库如果和主库断连时间过长，造成它在主库repl_backlog_buffer的slave_repl_offset位置上的数据已经被覆盖掉了，此时从库和主库间将进行全量复制。

  2. 每个从库会记录自己的slave_repl_offset，每个从库的复制进度也不一定相同。在和主库重连进行恢复时，从库会通过psync命令把自己记录的slave_repl_offset发给主库，主库会根据从库各自的复制进度，来决定这个从库可以进行增量复制，还是全量复制。

Redis 为什么主从全量复制使用RDB而不使用AOF？

　　1、传输RDB文件可以尽量降低对主库机器网络带宽的消耗，一是文件小，读取文件的速度会很快，二是因为RDB文件存储的都是二进制数据，从库直接按照RDB协议解析还原数据即可，速度会非常快。而AOF文件记录的是每一次写操作的命令，写操作越多文件会变得很大。AOF需要依次重放每个写命令，这个过程会经历冗长的处理逻辑，恢复速度相比RDB会慢得多，所以使用RDB进行主从全量复制的成本最低。

　　2、假设要使用AOF做全量复制，意味着必须打开AOF功能，打开AOF就要选择文件刷盘的策略，选择不当会严重影响Redis性能。而RDB只有在需要定时备份和主从全量复制数据时才会触发生成一次快照。而在很多丢失数据不敏感的业务场景，其实是不需要开启AOF的。

Redis 为什么还有无磁盘复制模式？

　　Redis 默认是磁盘复制，但是如果使用比较低速的磁盘，这种操作会给主服务器带来较大的压力。Redis从2.8.18版本开始尝试支持无磁盘的复制。使用这种设置时，子进程直接将RDB通过网络发送给从服务器，不使用磁盘作为中间存储。

无磁盘复制模式：master创建一个新进程直接dump RDB到slave的socket，不经过主进程，不经过硬盘。适用于disk较慢，并且网络较快的时候。

　　使用repl-diskless-sync配置参数来启动无磁盘复制。

　　使用repl-diskless-sync-delay 参数来配置传输开始的延迟时间；master等待一个repl-diskless-sync-delay的秒数，如果没slave来的话，就直接传，后来的得排队等了; 否则就可以一起传。

Redis 为什么还会有从库的从库的设计？

　　一次全量复制中，对于主库来说，需要完成两个耗时的操作：生成 RDB 文件和传输 RDB 文件。

　　如果从库数量很多，而且都要和主库进行全量复制的话，就会导致主库忙于 fork 子进程生成 RDB 文件，进行数据全量复制。fork 这个操作会阻塞主线程处理正常请求，从而导致主库响应应用程序的请求速度变慢。此外，传输 RDB 文件也会占用主库的网络带宽，同样会给主库的资源使用带来压力。

　　可以通过“主 - 从 - 从”模式将主库生成 RDB 和传输 RDB 的压力，以级联的方式分散到从库上。

Redis哨兵机制？哨兵实现了什么功能呢?

哨兵的核心功能是主节点的自动故障转移。

哨兵实现了什么功能呢？

  • 监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
  • 自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
  • 配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
  • 通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。

Redis 哨兵集群是通过什么方式组建的？

　　哨兵实例之间可以相互发现，要归功于 Redis 提供的 pub/sub 机制，也就是发布 / 订阅机制。

　　在主从集群中，主库上有一个名为__sentinel__:hello的频道，不同哨兵就是通过它来相互发现，实现互相通信的。

　　在下图中，哨兵 1 把自己的 IP（172.16.19.3）和端口（26579）发布到__sentinel__:hello频道上，哨兵 2 和 3 订阅了该频道。那么此时，哨兵 2 和 3 就可以从这个频道直接获取哨兵 1 的 IP 地址和端口号。然后，哨兵 2、3 可以和哨兵 1 建立网络连接。

 

Redis 哨兵是如何监控Redis集群的？

　　这是由哨兵向主库发送 INFO 命令来完成的。就像下图所示，哨兵 2 给主库发送 INFO 命令，主库接受到这个命令后，就会把从库列表返回给哨兵。接着，哨兵就可以根据从库列表中的连接信息，和每个从库建立连接，并在这个连接上持续地对从库进行监控。哨兵 1 和 3 可以通过相同的方法和从库建立连接。

 

Redis 哨兵如何判断主库已经下线了呢？

首先要理解两个概念：主观下线和客观下线

  • 主观下线：任何一个哨兵都是可以监控探测，并作出Redis节点下线的判断；
  • 客观下线：有哨兵集群共同决定Redis节点是否下线；

　　当某个哨兵（如下图中的哨兵2）判断主库“主观下线”后，就会给其他哨兵发送 is-master-down-by-addr 命令。接着，其他哨兵会根据自己和主库的连接情况，做出 Y 或 N 的响应，Y 相当于赞成票，N 相当于反对票。

　　如果赞成票数（这里是2）是大于等于哨兵配置文件中的 quorum 配置项（比如这里如果是quorum=2）, 则可以判定主库客观下线了。

Redis 哨兵的选举机制是什么样的？

  • 为什么必然会出现选举/共识机制？

　　为了避免哨兵的单点情况发生，所以需要一个哨兵的分布式集群。作为分布式集群，必然涉及共识问题（即选举问题）；同时故障的转移和通知都只需要一个主的哨兵节点就可以了。

  • 哨兵的选举机制是什么样的？

哨兵的选举机制其实很简单，就是一个Raft选举算法： 选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举

Raft算法你可以参看这篇文章分布式算法 - Raft算法

  • 任何一个想成为 Leader 的哨兵，要满足两个条件：
    • 第一，拿到半数以上的赞成票；
    • 第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。

以 3 个哨兵为例，假设此时的 quorum 设置为 2，那么，任何一个想成为 Leader 的哨兵只要拿到 2 张赞成票，就可以了。

Redis 1主4从，5个哨兵，哨兵配置quorum为2，如果3个哨兵故障，当主库宕机时，哨兵能否判断主库“客观下线”？能否自动切换？

1、哨兵集群可以判定主库“主观下线”。由于quorum=2，所以当一个哨兵判断主库“主观下线”后，询问另外一个哨兵后也会得到同样的结果，2个哨兵都判定“主观下线”，达到了quorum的值，因此，哨兵集群可以判定主库为“客观下线”。

2、但哨兵不能完成主从切换。哨兵标记主库“客观下线后”，在选举“哨兵领导者”时，一个哨兵必须拿到超过多数的选票(5/2+1=3票)。但目前只有2个哨兵活着，无论怎么投票，一个哨兵最多只能拿到2票，永远无法达到N/2+1选票的结果。

主库判定客观下线了，那么如何从剩余的从库中选择一个新的主库呢？

  • 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点
  • 选择salve-priority从节点优先级最高（redis.conf）的
  • 选择复制偏移量最大，只复制最完整的从节

 

 新的主库选择出来后，如何进行故障的转移？

  • 将slave-1（选出来的新主库）脱离原从节点（PS: 5.0 中应该是replicaof no one)，升级主节点，
  • 将从其他slave节点指向新的主节点
  • 通知客户端主节点已更换
  • 将原主节点（oldMaster）变成从节点，指向新的主节点

什么是Redis发布订阅？

　　Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

　　Redis 的 SUBSCRIBE 命令可以让客户端订阅任意数量的频道， 每当有新信息发送到被订阅的频道时， 信息就会被发送给所有订阅指定频道的客户端。

Redis发布订阅有哪两种方式？

　　基于频道(Channel)的发布/订阅

　　基于模式(pattern)的发布/订阅

 

什么是Redis Cluster？

　　Redis-cluster是一种服务器Sharding技术，Redis3.0以后版本正式提供支持，是Redis的分布式解决方案。

　　一主多从，单实例是存在瓶颈的，比如面对写流量的时候，始终只有主库在抗，所以可以采用横向扩展的方式，整多主多从。

　　用多个Redis实例来组成一个集群，按照一定的规则把数据「分发」到不同的Redis实例上。当集群所有的Redis实例的数据加起来，那这份数据就是全的。

　　要「分布式存储」，就肯定避免不了对数据进行「分发」(也是路由的意思)：

　　Redis Cluster的「路由」是做在客户端的（SDK已经集成了路由转发的功能）

说说Redis哈希槽的概念？为什么是16384个？

　　Redis-cluster没有使用一致性hash，而是引入了哈希槽的概念。

　　Redis-cluster中有16384(即2的14次方）个哈希槽，每个key通过CRC16校验后，计算出16bit的值（可以理解为就是做hash），对16383取模来决定放置哪个槽。Cluster中的每个节点负责一部分hash槽（hash slot）。

比如集群中存在三个节点，则可能存在的一种分配如下：

  1. 节点A包含0到5500号哈希槽；
  2. 节点B包含5501到11000号哈希槽；
  3. 节点C包含11001 到 16384号哈希槽。
  • 为什么是16384个

　　在redis节点发送心跳包时需要把所有的槽放到这个心跳包里，以便让节点知道当前集群信息，16384=16k，在发送心跳包时使用char进行bitmap压缩后是2k（2 * 8 (8 bit) * 1024(1k) = 16K），也就是说使用2k的空间创建了16k的槽数。

　　虽然使用CRC16算法最多可以分配65535（2^16-1）个槽位，65535=65k，压缩后就是8k（8 * 8 (8 bit) * 1024(1k) =65K），也就是说需要需要8k的心跳包，作者认为这样做不太值得；并且一般情况下一个redis集群不会有超过1000个master节点，所以16k的槽位是个比较合适的选择。

　　Redis实例之间「通讯」会相互交换「槽信息」，那如果槽过多（意味着网络包会变大），网络包变大，意味着会「过度占用」网络的带宽，Redis作者认为集群在一般情况下是不会超过1000个实例，那就取了16384个，即可以将数据合理打散至Redis集群中的不同实例，又不会在交换数据时导致带宽占用过多。

 

 客户端怎么知道这个哈希槽在哪台Redis实例上呢？

　　在集群的中每个Redis实例都会向其他实例「传播」自己所负责的哈希槽有哪些。这样一来，每台Redis实例就可以记录着「所有哈希槽与实例」的关系了。有了这个映射关系以后，客户端也会「缓存」一份到自己的本地上，那自然客户端就知道去哪个Redis实例上操作了。

在集群里也可以新增或者删除Redis实例(节点)，这个怎么整？

　　如果集群Redis实例存在变动，由于Redis实例之间会「通讯」

　　所以等到客户端请求时，Redis实例总会知道客户端所要请求的数据在哪个Redis实例上

　　如果已经迁移完毕了，那就返回「move」命令告诉客户端应该去找哪个Redis实例要数据，并且客户端应该更新自己的缓存(映射关系)

　　如果正在迁移中，那就返回「ack」命令告诉客户端应该去找哪个Redis实例要数据


为什么对数据进行分区在Redis中用的是「哈希槽」这种方式吗？而不是一致性哈希算法

　　一致性哈希算法就是有个「哈希环」，当客户端请求时，会对Key进行hash，确定在哈希环上的位置，然后顺时针往后找，找到的第一个真实节点，一致性哈希算法比「传统固定取模」的好处就是：如果集群中需要新增或删除某实例，只会影响一小部分的数据

　　但如果在集群中新增或者删除实例，在一致性哈希算法下，就得知道是「哪一部分数据」受到影响了，需要进行对受影响的数据进行迁移

　　而哈希槽的方式，在集群中的每个实例都能拿到槽位相关的信息，当客户端对key进行hash运算之后，如果发现请求的实例没有相关的数据，实例会返回「重定向」命令告诉客户端应该去哪儿请求

　　哈希槽实现相对简单高效，每次扩缩容只需要动对应Solt（槽）的数据，一般不会动整个Redis实例

服务端 路由：
　　服务端路由一般指的就是，有个代理层专门对接客户端的请求，然后再转发到Redis集群进行处理。现在比较流行的是Codis

　　它与Redis Cluster最大的区别就是，Redis Cluster是直连Redis实例的，而Codis则客户端直连Proxy，再由Proxy进行分发到不同的Redis实例进行处理。

  • Codis数据路由：默认分配1024个哈希槽，映射相关信息会被保存至Zookeeper集群。Proxy会缓存一份至本地，Redis集群实例发生变化时，DashBoard更新Zookeeper和Proxy的映射信息

  • Redis Cluster和Codis数据迁移：Redis Cluster支持同步迁移，Codis支持同步迁移&&异步迁移

    • 把新的Redis实例加入到集群中，然后把部分数据迁移到新的实例上（在线）
 

Redis集群会有写操作丢失吗？为什么？

　　Redis并不能保证数据的强一致性，这意味这在实际中集群在特定的条件下可能会丢失写操作。

 

Redis Cluster：

  1. 为什么需要 Redis Cluster？解决了什么问题？有什么优势？

    　　哨兵模式基于主从模式，实现读写分离，它还可以自动切换，系统可用性更高。但是它每个节点存储的数据是一样的，浪费内存，因此在Redis3.0后Cluster集群应运而生。

    　　Redis Cluster是一种服务器Sharding技术(分片和路由都是在服务端实现)，采用多主多从，每一个分区都是由一个Redis主机和多个从机组成，片区和片区之间是相互平行的。

  2. Redis Cluster 是如何分片的？
  3. 为什么 Redis Cluster 的哈希槽是 16384 个?
  4. 如何确定给定 key 的应该分布到哪个哈希槽中？
  5. Redis Cluster 支持重新分配哈希槽吗？　yes　
    1.      在 Redis Cluster 运行过程中，可能会遇到新增节点、节点故障、节点扩容等情况，这些变化可能会导致哈希槽的分布不再均匀，进而影响集群的性能和可用性。
          为了解决这个问题，Redis Cluster 提供了一种叫做“resharding”的机制，可以重新分配哈希槽，使其均匀地分布在新的节点上。具体来说，resharding 的过程如下：
          　　添加新节点：当新节点加入集群时，它的哈希槽数量会被平均分配给所有节点。
                 节点故障：当某个节点故障时，它的哈希槽会被重新分配给其他节点。
                 节点扩容：当某个节点需要扩容时，它可以请求集群管理员为其分配一部分哈希槽，管理员将这些哈希槽分配给该节点。
            在这些操作中，Redis Cluster 会使用一些算法来保证哈希槽的均匀分布，例如，在添加新节点或故障转移时，集群会尝试将不同节点的哈希槽数量调整到差不多相同的水平。
           需要注意的是，resharding 操作可能会对集群的性能和可用性产生影响，因此应该在必要时进行，避免过于频繁地进行哈希槽的重新分配。
  6. Redis Cluster 扩容缩容期间可以提供服务吗？ yes
    1. 可以。因为Redis的节点会根据集群拓扑结构进行自动重定向，确保客户端可以找到正确的节点来处理请求。
  7. Redis Cluster 中的节点是怎么进行通信的？
    1. Gossip 算法
    2. Redis集群采用P2P的Gossip（流言） 协议，Gossip协议工作原理就是节点彼此不断通信交换信息， 一段时间后所有的节点都会知道集群完整的信息

    3. 通信过程说明：

      1. 集群中的每个节点都会单独开辟一个TCP通道， 用于节点之间彼此通信， 通信端口号在基础端口上加10000。
      2. 每个节点在固定周期内通过特定规则选择几个节点发送ping消息。接收到ping消息的节点用pong消息作为响应。
      3. 集群中每个节点通过一定规则挑选要通信的节点， 每个节点可能知道全部节点， 也可能仅知道部分节点， 只要这些节点彼此可以正常通信， 最终它们会达到一致的状态。 当节点出故障、 新节点加入、 主从角色变化、 槽信息变更等事件发生时， 通过不断的ping/pong消息通信， 经过一段时间后所有的节点都会知道整个集群全部节点的最新状态， 从而达到集群状态同步的目的。

 新加入节点： Gossip 协议向老节点，发出一个“Meet 消息”。老节点会回复“Pong 消息”。后续新节点会定期给老节点发送“ping”，老节点回复"pong",来确保联系保持

    Meet 消息，用于通知新节点加入。就好像上面例子中提到的新节点上线会给老节点发送 Meet 消息，表示有“新成员”加入。
    Ping 消息，这个消息使用得最为频繁，该消息中封装了自身节点和其他节点的状态数据，有规律地发给其他节点。
    Pong 消息，在接受到 Meet 和 Ping 消息以后，也将自己的数据状态发给对方。同时也可以对集群中所有的节点发起广播，告知大家的自身状态。
    Fail 消息，如果一个节点下线或者挂掉了，会向集群中广播这个消息。

 

 

 

 

 

 


 
posted @ 2023-12-06 13:43  壹索007  阅读(50)  评论(0)  编辑  收藏  举报