Redis集群实际问题

  • 一、脑裂
  • 二 、Redis事务
  • 三、秒杀系统设计
  • 3.1 场景与特点：
  • 3.2 秒杀架构设计理念


一、脑裂

  1. 产生原因：
    master与从节点与哨兵没有在同一网段，导致哨兵无法找到master，就会以为master已经宕掉了，此时就会开始选举一个新的master，从而会出现两个master。集群脑裂问题中，如果客户端还在基于原来的master节点继续写入数据，那么新的master节点将无法同步这些数据，当网络问题解决之后，sentinel集群将原先的master节点降为slave节点，此时再从新的master中同步数据，将会造成大量的数据丢失。
  2. 解决方案：

redis的配置文件中，存在两个参数
min-slaves-to-write 3
min-slaves-max-lag 10
第一个参数表示连接到master的最少slave数量
第二个参数表示slave连接到master的最大延迟时间

  1. 按照上面的配置，要求至少3个slave节点，且数据复制和同步的延迟不能超过10秒，否则的话master就会拒绝写请求，配置了这两个参数之后，如果发生集群脑裂，原先的master节点接收到客户端的写入请求会拒绝，就可以减少数据同步之后的数据丢失。
    较新版本的redis.conf文件中的参数变成了

min-replicas-to-write 3
min-replicas-max-lag 10

二 、Redis事务

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行，事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。
事务相关的命令：

MULTI、EXEC、DISCARD、WATCH

三、秒杀系统设计

3.1 场景与特点：

  1. 秒杀时大量用户会在同一时间同时进行抢购，网站瞬时访问流量激增。
  2. 秒杀一般是访问请求数量远远大于库存数量，只有少部分用户能够秒杀成功。
  3. 秒杀业务流程比较简单，一般就是下订单减库存。

3.2 秒杀架构设计理念

  1. 限流：鉴于只有少部分用户能够秒杀成功，所以要限制大部分流量，只允许少部分流量进入服务后端。
  2. 削峰：对于秒杀系统瞬时会有大量用户涌入，所以在抢购一开始会有很高的瞬间峰值。高峰值流量是压垮系统很重要的原因，所以如何把瞬间的高流量变成一段时间平稳的流量也是设计秒杀系统很重要的思路。实现削峰的常用的方法有利用缓存和消息中间件等技术。
  3. 异步处理：秒杀系统是一个高并发系统，采用异步处理模式可以极大地提高系统并发量，其实异步处理就是削峰的一种实现方式。
  4. 内存缓存：秒杀系统最大的瓶颈一般都是数据库读写，由于数据库读写属于磁盘IO，性能很低，如果能够把部分数据或业务逻辑转移到内存缓存，效率会有极大地提升。
  5. 可拓展：当然如果我们想支持更多用户，更大的并发，最好就将系统设计成弹性可拓展的，如果流量来了，拓展机器就好了。像淘宝、京东等双十一活动时会增加大量机器应对交易高峰。