【随笔记】Redis（二）架构模式面试知识点

ゞ浴缸里的玫瑰 2023-01-18 13:24 132阅读 0赞

> 由简入繁，水滴石穿。

## Redis 的架构模式 ##

### 单机版 ###

> 直接说，就是只有一个redis，坏了就没得用那种。

*  特点：简单，很简单。
 *  缺点：
    
     *  存储容量有限制，取决于所在服务器的能力
     *  处理能力有限，也取决于所在服务器的能力
     *  高可用性无，没有高可用，坏了就没得用

### 主从复制 ###

> 高端点的单机版，Redis的复制（replication）功能允许用户根据一个Redis服务器来创建多个任意的复制品，其中被复制的服务器就是主服务器（master），而通过复制出来的服务器就是从服务器（slave）。只要主从服务器之间的网络连接正常，主从服务器之间就具有相同的数据，主服务器会一直将自身数据同步给从服务器，保证主从服务器上面的数据相同。

*  特点：
    
     *  master、slave两个角色
     *  master、slave数据是相同的
     *  可以降低master读数据压力，可以将读操作交给slave
 *  缺陷：
    
     *  没有高可用，master宕机后还是没得用
     *  slave为master减轻读压力，但是master还是存在写压力

### 哨兵模式 ###

> 高端模式，解决了高可用、自动进行故障转移。

*  监控（monitoring）：Sentinel会不断检查主服务器和从服务器是否正常工作；
 *  提醒（Notification）：当被监控的某个Redis服务器出现问题，Sentinel可以通过API向管理员或者其他程序发送通知；
 *  自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作，Sentinel会进行一次自动故障迁移。
 *  特点：
    
     *  高可用
     *  监控所有节点
     *  可以自动故障迁移
 *  缺点：
    
     *  主从模式切换时间中，数据会丢失
     *  master写压力没有解决

### 集群模式（Proxy） ###

> 高端玩法。使用Twitter开源的Twemproxy，一个Redis和Memcache快速/轻量级代理服务器，他是一个快速的单线程代理程序，支持Memcached ASCII协议和Redis协议。

*  特点鲜明：
    
     *  1.支持多种hash算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins；
     *  2.支持自动删除失败节点。
     *  3.后端Sharding分配逻辑对业务透明，业务的读写方式和操作单个Redis一致；
 *  缺点：
    
     *  维护高可用的成本增加，因为同样要维护proxy的高可用

### 集群模式（直连） ###

> Redis 3.0后版本支持Redis-cluster集群，采用的是无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。

*  特点：
    
     *  无中心架构，少了proxy代理层
     *  数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布
     *  可扩展性，节点可以动态增加或者减少
     *  高可用性，当有节点不可用时，集群仍然可用，可以增加slave做备份数据副本
     *  实现故障自动failover，节点之间通过gossip协议交换状态信息，通投票机制完成slave到master的角色提升
 *  缺点：
    
     *  资源隔离性差，很容易出现相互影响
     *  数据通过异步复制，强一致性不能保证

## 高可用 ##

> 从上面的几种Redis架构中可以看到，Redis的高可用主要由Cluster集群模式、sentinel哨兵模式，当主服务器挂掉后，会从节点中选择出一个新的主服务器，并调整其他从服务器Slave关联到新的master上。

选举策略一般分三种：

*  Slave的Priority设置的越低，优先级就越高；
 *  相同情况slave复制的数据越多，优先级越高；
 *  runid越小，越容易被选中升为master；

如果使用Sentinel模式，为了保证Sentinel的高可用，通常会部署3个Sentinel。那么多个Sentinel之间通过Raft协议来保证自身的高可用。

> 关于Raft协议，这个协议是大师提出的，非常的牛，解决了很多分布式一致性的问题，这个理解起来也不容易，我也没怎么看这个算法。

Sentinel用三个实例去保证健壮性，虽然不能保证数据不丢失，但是在高可用上是可以保证的。

*  监控：负责监控集群内的Redis Master和Slave进程是否正常工作；
 *  消息通知：如果发现某一个Redis实例出现问题，可以发送消息通知出去；
 *  故障转移：如果Master故障了，可以自动转移到slave上；
 *  配置中心：故障转移后，能通知client去新的Master；