08 Redis主从复制、哨兵、集群

向右看齐 2023-07-25 09:59 19阅读 0赞

#### CAP理论 ####

C-Consistent，一致性

A-Availability，可用性

P-Partition tolerance，分区容忍性

简单来说就是当网络分区发生时，一致性和可用性不能同时保证。

#### 为什么要做主从同步 ####

因为当Redis的节点挂掉后，重启数据恢复需要较长时间，会影响服务，所以要做主从复制，一个master节点可以挂接多个slave节点，当master节点挂掉时，就可以让slave节点来提供服务。

#### Redis 主从节点是怎样通信的，传输数据是全量复制还是半增量复制 ####

#### Redis 怎么实现高并发 ####

Redis通过主从架构，实现读写分离，主节点负责写，并将数据同步给其他从节点，从节点负责读，从而实现高并发。

#### Redis如何做到高可用？ ####

一个slave挂掉了不会影响程序，还会有其他的slave给程序提供查询服务  
但是master死掉了就没发进行写程序了，所有redis有个主备切换，当master死掉了，会找一个slave来代替master作为新的master,这就叫做故障转移也叫做主备切换

#### 分布式Redis系统最终一致性 ####

在主从网络断开的情况下，主节点依旧可以提供服务，所以Redis满足**可用性**。但是Redis的主从数据是异步同步的，所以分布式Redis系统不满足**一致性**，Redis可以保证**最终一致性**，一旦网络恢复，从节点会努力追赶上落后的数据，最终从节点的状态和主节点的状态会保证一致。

同步方式：增量同步、快照同步

#### 为什么要有哨兵机制 ####

我们知道Redis可以主从复制，master节点挂掉后，可以切换到slave节点，但是手动更改地址很麻烦，所以Redis提供了Sentinel哨兵机制，在master故障时可以自动进行切换。

#### 选举算法是什么样的 ####

#### 哨兵原理 ####

*  Redis sentinel 哨兵集群通过心跳机制监控主从节点，每一个 sentinel 节点会定时对 Redis 集群中的所有节点发出心跳包，检测节点是否正常，如果某个节点在规定时间内没有回复，则认为节点发生了故障。
 *  哨兵由3~5个节点组成，他们会持续监控master和slave节点，当master节点挂掉时，会自动选举一个最优的节点切换为主节点。客户端连接redis时，会首先连接sentinel，通过哨兵查询主节点的地址，再去连接主节点进行数据交互。当主节点发生故障时，客户端会重新向sentinel要地址，sentinel会将最新的主节点地址告诉客户端。

问题1：异步复制导致的数据丢失  
因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了

问题2：脑裂导致的数据丢失  
脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着

此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master

这个时候，集群里就会有两个master，也就是所谓的脑裂。

此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了

因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据

可以通过调整参数减少消息丢失。

*  min-slave-to-write 1
 *  min-slave-max-lag 10

要求至少有1个slave可以正常复制，并且数据复制和同步的延迟不能超过10秒

如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了

上面两个配置可以减少异步复制和脑裂导致的数据丢失，最多丢失10秒的数据。

Redis默认端口是6379，sentinel默认端口是26379

#### 为什么要有Redis cluster ####

在高并发场景下，单个Redis有性能瓶颈，体现在内存可能不够用，另外大量的请求到一台Redis上压力会比较大。所以有了Redis cluster解决方案，它可以将多个Redis实例聚集在一起来完成数据存储和读写操作。每个节点负责一部分数据，多个节点组成一个集群，他们之间通过一种特殊的二进制协议相互交互集群信息。

#### Redis cluster怎么进行数据分片的 ####

Redis cluster将所有的数据划分到16384个slot，每个节点负责一部分槽位。当客户端来连接集群时，它会得到集群的槽位分配信息，当要往Redis集群中放置一个key-value时，先对key使用crc16算法算得一个结果，然后把结果对16384取模，会得到hash槽的编号，根据槽位分配信息可以找到对应的节点，然后存取数据。

优点：使用hash槽的好处是可以方便的添加或者删除redis节点，当需要添加节点时，只需要把其他节点的某些hash槽挪到新节点即可，当需要移除节点时，只需要把要移除的节点的hash槽挪到其他节点即可。

**普通的hash算法的缺点**：将key的hash值对redis实例的个数取模来定位到redis的话，会有一些问题，比如redis实例增加，这个计算公式也会变，这就会导致原本的记录查不到了,就要将之前存储的key重新hash一遍，但是这样代价比较高。所以有了一致性哈希。

**为什么redis不采用一致性hash算法**：  
这个算法是redis开发者自己实现的一个算法，已经可以实现方便的添加删除节点。

**一致性hash算法原理**：  
一致性hash也是使用取模的方法，不过不是对服务器数量取模，而是对2的32次方取模，hash函数的值空间为0~2的32次方-1，将整个hash值空间看成一个虚拟的圆环。将每台服务器都hash到hash环的一个位置上。要添加key时，将key对2的32次方取模，确定在环上的位置，沿着环顺时针查找，遇到的服务器就是要定位到的服务器。

假如有一台服务器宕机了，只会影响这台服务器和它前面一台服务器中之间的数据，将这些数据重新进行定位即可。  
如果新增一台服务器，也只需要重新定位一小部分数据，一致性hash算法具有很好的扩展性和容错性。

问题：数据倾斜问题  
假设服务器在hash环上分布不均匀，就会导致大部分的数据定位到一台服务器上。

解决：为了解决数据倾斜问题，引入了虚拟节点机制，对每一个服务器节点计算多个hash，每个计算结果的位置都放置一个此服务节点，称为虚拟节点。这样在服务器节点很少的情况下，也能做到数据的平均分布。  
使用这种方式来大大削弱甚至避免数据倾斜问题。