Redis集群详解

Redis作为缓存使用，单进程单实例存在的问题：

• 单点故障
• 容量有限
• 压力过大

1|1Redis主从复制解决单点故障：

AKF拆分原则：

x轴：全量、镜像。复制多个镜像，解决单点故障

y轴：按业务功能拆分为多个实例，同时在x轴方向同时创建多份镜像。

z轴：优先级、逻辑再拆分。比如说某个模块数据过多，可以拆分为多个Redis客户端，全量数据分为多份，每个Redis中存一部分数据。

此时虽然解决了单实例存在的三个问题，那么又会带来数据一致性问题。

解决数据一致性问题：

• 同步阻塞方式：

假如说一个客户端做了一个写操作，到达主Redis，那么client将阻塞，直到主Redis通知两个备Redis都成功写入才返回结果。这时候为强一致性，带来的问题是，假如说备用Redis这时候挂掉，没有写入成功，那么主Redis等待超时之后，就返回给客户端失败，相当于服务不可用，破坏了可用性。

• 异步方式：
  • 弱一致性：

  

  容忍数据丢失一部分，当client发送一个写请求，Redis立刻返回OK，这时候通知备Redis去写，如果两个都写失败了，那么就会丢失数据。

  • 最终一致性：

  

  这种方式虽然数据最终会一致，但是在这期间如果有客户端去读数据，可能会造成脏读。

小知识：主备与主从的区别 主备：备机一般不参与业务，当主挂了之后，备机可以代替主去提供服务。 主从：客户端可以访问主，也可以访问从。

Redis一般使用主从复制的模式，但是此时主自己又是一个单点。

对主做HA高可用：

对主做高可用并不是说不让主出现问题，而是对外表现为没有出现问题。人工可以去把其中一个从机设置为主，让另一个从去追随它。但是人往往是不可靠的，所以需要技术或程序来实现，主要是一个程序就会有单点故障的问题，所以程序也必须是一个集群。

假如说有三个监控程序监控一个主Redis的存活状态，那么也就是说Redis的存活状态由三个监控程序说了算。

• 强一致性，都给出OK：假如说都给出OK，才表示Redis存活，那么必然会破坏可用性，比如说其中一个监控阻塞了，而实际Redis还存活，这相当于监控不可用，所以不可取。
• 一部分给出OK，另一部分不算数：那么一部分是几个呢？假如拿三个监控举例，那么就只能是1或者2。 推导过程：
  • 1个：统计不准确，不够势力范围，因为每个都可以做主。可能会导致数据不一致，会有网络分区的问题，对外表现为同一服务拿到的数据不同，也就是脑裂。 并不是说发生脑裂不好，有个概念叫分区容忍性。比如说SpringCloud中的Eureka注册中心，假如说本来有十个服务注册到不同的Eureka中，负载的时候需要打到不同的机器上，每个负载发现的服务机器数不一致，但并不影响，对客户端来说，只要有服务可用即可。
  • 2个：这个时候会有两台结成势力范围，两台之间互相通信，这时候给出的结果就是Redis要么存活，要么挂了，不会有中间状态。

  2在3个节点成功解决脑裂问题，3在4/5个节点成功解决脑裂问题，可以得出结论，当有n个节点的时候需要n/2 1，也就是过半，一般使用奇数台。 为什么是奇数台？

  1. 3台、4台能承受的风险都是只允许1台出现问题，4台的成本更高。
  2. 4台的时候比3台更容易出现问题，即1台出现问题的概率更大。

主从复制配置：

• replica-serve-stale-data yes 表示一个Redis在启动之后，并且将追随一个主Redis，在主给生成RDB文件到从Redis去load RDB文件之前，是否提供查询服务。no的话，直到全部同步完之前不提供服务。
• replica-read-only yes 备机是否开启只读模式。
• repl-diskless-sync no 主Redis发送RDB有两种方式，第一种方式是通过落到磁盘，从Redis再去load，第二种方式是直接通过网络发送RDB传给从Redis。这就取决于磁盘IO和网络IO哪个更快一些。配置no的话默认是走磁盘方式。

• repl-backlog-size 1mb 主从复制，增量复制。在Redis中，除了写入RDB文件外，还维护一个小的队列。当从Redis load完RDB之后，突然挂掉了，然后服务又好了，这时候又需要去同步数据，但是此时的RDB文件已经过时，可以把RDB文件重新覆盖一遍，但是如果此时文件很大的话，又需要浪费时间。此时可以把一个偏移量给到主Redis，然后根据偏移量去获取增量数据，但是这时候取决于队列大小，默认为1MB，如果写的速度非常慢，在这期间没有超过设置的大小，那么是可以的，但是如果写的数据非常多，超过了设置的大小，那么又会走全量复制，所以要根据实际写入的数据设置合适的队列大小。

• min-replicas-to-write 3 min-replicas-max-lag 10 可以设置最少写几个写成功，当关心数据一致性的时候，可以设置。默认是注释掉的，如果设置的话其实是在向强一致性靠拢，所以需根据实际应用场景配置。

HA高可用（x轴）:

sentinel哨兵代替人工去自动修复故障，可以是单机也可以是集群，只监控master节点，因为master节点上有slave节点信息，通过发布订阅发现其他哨兵。

1|2Redis解决容量问题：

解决方案client端：

1. 当数据可以拆分的时候，可以按业务逻辑拆分，并分配到各个Redis实例。

1. 当数据不可拆分的时候，有三种解决方案（sharding分片）： 这三种模式都只能作为缓存用，不能做数据库用。
   • 利用算法：hash 取模（modula），模的大小为Redis实例数。当key经过hash之后，存放在某一台Redis实例中。 弊端：取模的数必须固定，当再增加Redis实例时，可能会取不到原来的值，需要重新取模，全局洗牌，影响分布式下的扩展性。

   

   • random随机：这种有一个应用场景，一般用于list类型，即消息队列。当并发流量大时，可以用Redis作为缓冲，但是一台实例有扛不住，可以多搞几台，每一台上有相同的key，当client去lpush一个key时，随机写到一台Redis实例中，另一个client去rpop，这个key其实相当于topic，而每个Redis相当于partition，就是kafka的模型，只不过kafka是基于磁盘的，数据可以重新消费，Redis是基于内存的，速度快。

   

   • 一致性哈希(ketama) 规划一个环形哈希环，环上有很多点，比如说0~2^32，然后有一个映射算法（如hash、md5等很多），有两个Redis节点，分别为node01，node02，把这两个节点信息通过一个hash算法映射到这个环上某一个点，这两个点是物理的，其他的点都是虚拟的。当一个数据(data)进来时，也经过这个hash算法映射在环上某个点，假如说这些点都在一个排好序的集合里（比如说TreeMap），然后遍历这个map去找大于这个点的最近的物理点在哪，找到这个点代表的物理机然后存放进去，即存到了node02中。假如说现在想加一个node03，经过hash后恰巧分配到了两个物理节点之间。 优点：增加节点可以分担其他节点的压力，不会造成像取模一样全局洗牌。 缺点:
     • 问题：新增节点导致一小部分数据不能命中，可能会造成缓存击穿。
     • 方案：每次取的时候，找离我最近的两个物理节点。

     那么在取不到的数据存在node02节点上会造成空间浪费，可以利用Redis自带的回收策略，例如LRU、LFU。 扩展：在哈希环上增加虚拟节点，一个物理设备可以通过hash算法映射为多个虚拟节点，使数据存储更均匀。

   

server端方案：

上述算法都是发生在客户端的，那么当客户端连接Redis的时候，socket连接过多，对server端的影响是连接成本很高。

此时可以用代理的方式解决，让所有的客户端去连接中间代理，此时server端的socket连接压力不大，只需要关心代理层性能即可。

所谓无状态，就是本身并不需要数据库，不需要存储数据，数据是存在后端的，只有达到无状态的代理，像Nginx这种，才更容易一变多。

如果客户端很多，前面压力过大，一台代理撑不住的话，代理可以做一个集群，在代理之前还可以加一层LVS，不需要对代理层做高可用，因为如果LVS挂掉的话，后面服务都不可用了，所以LVS会做一个主备，主备之间靠keepalived来管理，除了可以监控LVS之外，还可以监控代理层的健康状态，如果其中一台代理挂了，那么只会走另一台。

预分区：

不管是在client还是proxy的算法，新增一台Redis的时候总会有问题，要么重新取模全局洗牌，要么丢失一部分数据，所以干脆一开始取模值大一点，比如说取模为10，模数值的范围09。此时中间还需要一层`mapping`做映射，假如说一开始有两台Redis1和Redis12，Redis1上是04槽位，Redis2上是5~9槽位，这样新增一个节点的时候，只需要从之前的Redis上让出几个槽位即可。那么在数据迁移的过程中，允不允许修改？这时候可以先把时点数据RDB传过去，再把增量的日志传过去。

Redis集群实现：

cluster模式：只需要一个client，并且是无主模型，client连哪一个都行，在每一个Redis都有hash算法，还需要有其他Redis上的映射关系，假如说client要get一个k1，而k1根据hash取模算出来在4号槽位，而此时client连接Redis2，那么会返回给客户端并跳转到key对应所在的Redis节点，找到之后直接返回给client即可。（查询路由）

数据分治会导致聚合操作难以实现，比如说求两个集合的交集，两个集合在不同的Redis节点上。事务也难以支持，Redis并没有去实现，但可以人为定义进行hash的算法，比如说用相同的前缀（键哈希标签），这样数据就会存储到同一Redis节点上。

比如这两个键 {user1000}.following 和 {user1000}.followers 会被哈希到同一个哈希槽里，因为只有 user1000 这个子串会被用来计算哈希值。

2|0Redis常见问题

2|1缓存击穿

Redis的key会有过期时间，包括自带的LRU、LFU导致的淘汰key，当在过期的时候，正好有大量并发请求来查询这个key，这个时候请求会直接打到数据库上，称为缓存击穿。强调的是高并发对某个过期key查询。

解决方案：

Redis是单进程单实例的，用setnx()加锁，第一个去获取key发现没有，然后加一把锁，加锁成功的话，就去访问数据库，后面的加锁失败，就sleep等待，一般根据实际业务场景选择等待时间。

问题1：只要加锁就可能会有死锁的问题，假如说第一个人挂了怎么办？

• 可以设置锁的过期时间

问题2：如果没挂，但是访问数据库阻塞了，导致锁超时了怎么办？

• 使用多线程，一个线程取数据库，一个线程监控是否取回来，更新锁的时间。但是这样的话会增加业务代码的复杂度。

2|2缓存穿透

从业务系统接收到的查询请求的是系统中根本不存在的数据，称为缓存穿透。

解决方案：

布隆过滤器：三种使用方式

• client包含：压力到不了Redis，客户端代码复杂度高。
• client只写算法，bitmap在Redis。
• Redis集成布隆，客户端轻盈。

布隆过滤器的一个缺点是不能删除，如果有必要的话可以用布谷鸟过滤器，或者把key的值设为null。

2|3缓存雪崩

大量的key同时失效，间接造成大量的访问到达数据库，为缓存雪崩。

解决方案：

两方面，一是时点性无关的话，把过期时间随机，防止大量key同时过期。

如果是业务上0点，或者1点失效的话，可以强依赖击穿方案，也可以在业务层加判断，做零点延迟，这样压力不会到Redis。