Redis原理和高可用场景实践总结(三)

简介: Redis原理和高可用场景实践总结

Redis分布式锁实现原理

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.dao.DataAccessException;
import org.springframework.data.redis.connection.RedisConnection;
import org.springframework.data.redis.core.RedisCallback;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.serializer.StringRedisSerializer;
/**
 * 分布式锁
 * 性能待测试
 * @author lzhcode
 *
 */
public class RedisLock {
    private static Logger logger = LoggerFactory.getLogger(RedisLock.class);
      private RedisTemplate redisTemplate;
      private static final int DEFAULT_ACQUIRY_RESOLUTION_MILLIS = 100;
      /**
       * Lock key path.
       */
      private String lockKey;
      /**
       * 锁超时时间,防止线程在入锁以后,无限的执行等待
       */
      private int expireMsecs = 60 * 1000;
      /**
       * 锁等待时间,防止线程饥饿
       */
      private int timeoutMsecs = 10 * 1000;
      private volatile boolean locked = false;
      /**
       * Detailed constructor with default acquire timeout 10000 msecs and lock expiration of 60000 msecs.
       *
       * @param lockKey lock key (ex. account:1, ...)
       */
      public RedisLock(RedisTemplate redisTemplate, String lockKey) {
          this.redisTemplate = redisTemplate;
          this.lockKey = lockKey + "_lock";
      }
      /**
       * Detailed constructor with default lock expiration of 60000 msecs.
       *
       */
      public RedisLock(RedisTemplate redisTemplate, String lockKey, int timeoutMsecs) {
          this(redisTemplate, lockKey);
          this.timeoutMsecs = timeoutMsecs;
      }
      /**
       * Detailed constructor.
       *
       */
      public RedisLock(RedisTemplate redisTemplate, String lockKey, int timeoutMsecs, int expireMsecs) {
          this(redisTemplate, lockKey, timeoutMsecs);
          this.expireMsecs = expireMsecs;
      }
      /**
       * @return lock key
       */
      public String getLockKey() {
          return lockKey;
      }
      private String get(final String key) {
          Object obj = null;
          try {
              obj = redisTemplate.execute(new RedisCallback<Object>() {
                  @Override
                  public Object doInRedis(RedisConnection connection) throws DataAccessException {
                      StringRedisSerializer serializer = new StringRedisSerializer();
                      byte[] data = connection.get(serializer.serialize(key));
                      connection.close();
                      if (data == null) {
                          return null;
                      }
                      return serializer.deserialize(data);
                  }
              });
          } catch (Exception e) {
              logger.error("get redis error, key : {}", key);
          }
          return obj != null ? obj.toString() : null;
      }
      private boolean setNX(final String key, final String value) {
          Object obj = null;
          try {
              obj = redisTemplate.execute(new RedisCallback<Object>() {
                  @Override
                  public Object doInRedis(RedisConnection connection) throws DataAccessException {
                      StringRedisSerializer serializer = new StringRedisSerializer();
                      Boolean success = connection.setNX(serializer.serialize(key), serializer.serialize(value));
                      connection.close();
                      return success;
                  }
              });
          } catch (Exception e) {
              logger.error("setNX redis error, key : {}", key);
          }
          return obj != null ? (Boolean) obj : false;
      }
      private String getSet(final String key, final String value) {
          Object obj = null;
          try {
              obj = redisTemplate.execute(new RedisCallback<Object>() {
                  @Override
                  public Object doInRedis(RedisConnection connection) throws DataAccessException {
                      StringRedisSerializer serializer = new StringRedisSerializer();
                      byte[] ret = connection.getSet(serializer.serialize(key), serializer.serialize(value));
                      connection.close();
                      return serializer.deserialize(ret);
                  }
              });
          } catch (Exception e) {
              logger.error("setNX redis error, key : {}", key);
          }
          return obj != null ? (String) obj : null;
      }
      /**
       * 获得 lock.
       * 实现思路: 主要是使用了redis 的setnx命令,缓存了锁.
       * reids缓存的key是锁的key,所有的共享, value是锁的到期时间(注意:这里把过期时间放在value了,没有时间上设置其超时时间)
       * 执行过程:
       * 1.通过setnx尝试设置某个key的值,成功(当前没有这个锁)则返回,成功获得锁
       * 2.锁已经存在则获取锁的到期时间,和当前时间比较,超时的话,则设置新的值
       *
       * @return true if lock is acquired, false acquire timeouted
       * @throws InterruptedException in case of thread interruption
       */
      public   boolean lock() throws InterruptedException {
          int timeout = timeoutMsecs;
          while (timeout >= 0) {
              long expires = System.currentTimeMillis() + expireMsecs + 1;
              String expiresStr = String.valueOf(expires); //锁到期时间
              if (this.setNX(lockKey, expiresStr)) {
                  // lock acquired
                  locked = true;
                  return true;
              }
              String currentValueStr = this.get(lockKey); //redis里的时间
              if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
                  //判断是否为空,不为空的情况下,如果被其他线程设置了值,则第二个条件判断是过不去的
                  // lock is expired
                  String oldValueStr = this.getSet(lockKey, expiresStr);
                  //获取上一个锁到期时间,并设置现在的锁到期时间,
                  //只有一个线程才能获取上一个线上的设置时间,因为jedis.getSet是同步的
                  if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
                      //防止误删(覆盖,因为key是相同的)了他人的锁——这里达不到效果,这里值会被覆盖,但是因为什么相差了很少的时间,所以可以接受
                      //[分布式的情况下]:如过这个时候,多个线程恰好都到了这里,但是只有一个线程的设置值和当前值相同,他才有权利获取锁
                      // lock acquired
                      locked = true;
                      return true;
                  }
              }
              timeout -= DEFAULT_ACQUIRY_RESOLUTION_MILLIS;
              /*
                  延迟100 毫秒,  这里使用随机时间可能会好一点,可以防止饥饿进程的出现,即,当同时到达多个进程,
                  只会有一个进程获得锁,其他的都用同样的频率进行尝试,后面有来了一些进行,也以同样的频率申请锁,这将可能导致前面来的锁得不到满足.
                  使用随机的等待时间可以一定程度上保证公平性
               */
              Thread.sleep(DEFAULT_ACQUIRY_RESOLUTION_MILLIS);
          }
          return false;
      }
      /**
       * Acqurired lock release.
       */
      public   void unlock() {
          if (locked) {
              redisTemplate.delete(lockKey);
              locked = false;
          }
      }
}

和RedisLock和Redisson表面来看,这个方案似乎很管用,但是这里存在一个问题:在我们的系统架构里存在一个单点故障,如果Redis的master节点宕机了怎么办呢?有人可能会说:加一个slave节点!在master宕机时用slave就行了!但是其实这个方案明显是不可行的,因为这种方案无法保证第1个安全互斥属性,因为Redis的复制是异步的。 总的来说,这个方案里有一个明显的竞争条件(race condition),举例来说:

  • 客户端A在master节点拿到了锁。
  • master节点在把A创建的key写入slave之前宕机了。
  • slave变成了master节点
  • B也得到了和A还持有的相同的锁(因为原来的slave里还没有A持有锁的信息)

下面的表格总结了Zookeeper和Redis分布式锁的优缺点:

15、你们生产环境中的redis是怎么部署的

redis cluster,10台机器,5台机器部署了redis主实例,另外5台机器部署了redis的从实例,每个主实例挂了一个从实例,5个节点对外提供读写服务,每个节点的读写高峰qps可能可以达到每秒5万,5台机器最多是25万读写请求/s。

机器是什么配置?32G内存+8核CPU+1T磁盘,但是分配给redis进程的是10g内存,一般线上生产环境,redis的内存尽量不要超过10g,超过10g可能会有问题。

5台机器对外提供读写,一共有50g内存。

因为每个主实例都挂了一个从实例,所以是高可用的,任何一个主实例宕机,都会自动故障迁移,redis从实例会自动变成主实例继续提供读写服务

你往内存里写的是什么数据?每条数据的大小是多少?商品数据,每条数据是10kb。100条数据是1mb,10万条数据是1g。常驻内存的是200万条商品数据,占用内存是20g,仅仅不到总内存的50%。

目前高峰期每秒就是3500左右的请求量

16、Redis Java客户端的选择

Redis的Java客户端很多,官方推荐的有三种:Jedis、Redisson和lettuce。

在这里对Jedis和Redisson进行对比介绍

Jedis:

轻量,简洁,便于集成和改造

支持连接池

支持pipelining、事务、LUA Scripting、Redis Sentinel、Redis Cluster

不支持读写分离,需要自己实现

文档差(真的很差,几乎没有……)

Redisson:

基于Netty实现,采用非阻塞IO,性能高

支持异步请求

支持连接池

支持pipelining、LUA Scripting、Redis Sentinel、Redis Cluster

不支持事务,官方建议以LUA Scripting代替事务

支持在Redis Cluster架构下使用pipelining

支持读写分离,支持读负载均衡,在主从复制和Redis Cluster架构下都可以使用

内建Tomcat Session Manager,为Tomcat 6/7/8提供了会话共享功能

可以与Spring Session集成,实现基于Redis的会话共享

文档较丰富,有中文文档

17、保护模式

Redis从3.2开始加强安全管理,如果redis没有设置密码,那么redis客户端只能从本地进行访问,如果是从其他机器连接过来访问的,就会报错误。

解决方案是设置参数protected-mode no,这个参数可以动态设置,或者为redis设置密码。

redis-cli -p 6500 config set protected-mode no

18、防重复提交

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface DuplicateSubmit {
}
import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
import org.aspectj.lang.reflect.MethodSignature;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.core.annotation.Order;
import org.springframework.stereotype.Component;
import org.springframework.web.context.request.RequestContextHolder;
import org.springframework.web.context.request.ServletRequestAttributes;
import javax.servlet.http.HttpServletRequest;
import java.lang.reflect.Method;
import java.util.concurrent.TimeUnit;
@Aspect
@Component
@Order(-2)
@Slf4j
public class DuplicateSubmitInteceptor {
    @Autowired
    private RedisUtils redisDomainService;
    @Pointcut("within(com.controller..*)")
    public void doubleCheckCut() {
    }
    @Around("doubleCheckCut()")
    public Object around(ProceedingJoinPoint pjp) throws Throwable {
        Method method = ((MethodSignature) pjp.getSignature()).getMethod();
        DuplicateSubmit duplicateSubmit = method.getAnnotation(DuplicateSubmit.class);
        if (null != duplicateSubmit) {
            HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();
            String uri = request.getRequestURI();
            Long orgId = UserContextHolder.getUser().getUserId();
            if (null == orgId) {
                throw new ServerException(ErrorCode.USER_INFO_ERROR);
            }
            String value = Long.toString(System.currentTimeMillis());
            try {
                boolean dobuleCheck =
                        redisDomainService.setIfAbsent(String.format(RedisKeyEnum.DOUBLE_REQUEST.getCode(), uri, orgId),
                                value,
                                RedisKeyEnum.DOUBLE_REQUEST.getTime().intValue(), TimeUnit.SECONDS);
                if (!dobuleCheck) {
                    log.error("======>表单重复提交限制出错...{}");
                    throw new ServerException(ErrorCode.DOUBLE_REQUEST_ERROR);
                }
                Object proceed = pjp.proceed();
                return proceed;
            } catch (Exception e) {
                log.error("======>表单重复提交限制出错...{}", e);
                throw e;
            } finally {
                String o = redisDomainService.getString(String.format(RedisKeyEnum.DOUBLE_REQUEST.getCode(), uri,
                        orgId));
                if (null != o) {
                    redisDomainService.unlock(String.format(RedisKeyEnum.DOUBLE_REQUEST.getCode(), uri, orgId), value);
                }
            }
        }
        return pjp.proceed();
    }
}

19、Redis有哪些淘汰策略

LFU (Least Frequently Used) :最近最少使用,跟使用的次数有关,淘汰使用次数最少的。

LRU (Least Recently Used): 最近最不经常使用,跟使用的最后一次时间有关,淘汰最近使用时间离现在最久的。

  • noevction:一旦缓存被写满了,再有写请求来时,Redis 不再提供服务,而是直接返回错误。Redis 用作缓存时,实际的数据集通常都是大于缓存容量的,总会有新的数据要写入缓存,这个策略本身不淘汰数据,也就不会腾出新的缓存空间,我们不把它用在 Redis 缓存中。
  • volatile-ttl 在筛选时,会针对设置了过期时间的键值对,根据过期时间的先后进行删除,越早过期的越先被删除。
  • volatile-random 就像它的名称一样,在设置了过期时间的键值对中,进行随机删除。
  • volatile-lru 会使用 LRU 算法筛选设置了过期时间的键值对。
  • volatile-lfu 会使用 LFU 算法选择设置了过期时间的键值对。
  • allkeys-random 策略,从所有键值对中随机选择并删除数据。
  • allkeys-lru 策略,使用 LRU 算法在所有数据中进行筛选。
  • allkeys-lfu 策略,使用 LFU 算法在所有数据中进行筛选。
目录
相关文章
|
存储 缓存 NoSQL
Redis 服务器全方位介绍:从入门到核心原理
Redis是一款高性能内存键值数据库,支持字符串、哈希、列表等多种数据结构,广泛用于缓存、会话存储、排行榜及消息队列。其单线程事件循环架构保障高并发与低延迟,结合RDB和AOF持久化机制兼顾性能与数据安全。通过主从复制、哨兵及集群模式实现高可用与横向扩展,适用于现代应用的多样化场景。合理配置与优化可显著提升系统性能与稳定性。
538 0
|
4月前
|
消息中间件 缓存 NoSQL
Redis各类数据结构详细介绍及其在Go语言Gin框架下实践应用
这只是利用Go语言和Gin框架与Redis交互最基础部分展示;根据具体业务需求可能需要更复杂查询、事务处理或订阅发布功能实现更多高级特性应用场景。
321 86
|
4月前
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。
|
4月前
|
存储 缓存 监控
Redis分区的核心原理与应用实践
Redis分区通过将数据分散存储于多个节点,提升系统处理高并发与大规模数据的能力。本文详解分区原理、策略及应用实践,涵盖哈希、范围、一致性哈希等分片方式,分析其适用场景与性能优势,并探讨电商秒杀、物联网等典型用例,为构建高性能、可扩展的Redis集群提供参考。
241 0
|
6月前
|
存储 缓存 NoSQL
Redis 核心知识与项目实践解析
本文围绕 Redis 展开,涵盖其在项目中的应用(热点数据缓存、存储业务数据、实现分布式锁)、基础数据类型(string 等 5 种)、持久化策略(RDB、AOF 及混合持久化)、过期策略(惰性 + 定期删除)、淘汰策略(8 种分类)。 还介绍了集群方案(主从复制、哨兵、Cluster 分片)及主从同步机制,分片集群数据存储的哈希槽算法。对比了 Redis 与 Memcached 的区别,说明了内存用完的情况及与 MySQL 数据一致性的保证方案。 此外,详解了缓存穿透、击穿、雪崩的概念及解决办法,如何保证 Redis 中是热点数据,Redis 分布式锁的实现及问题解决,以及项目中分布式锁
177 1
|
8月前
|
缓存 NoSQL Java
Redis:现代服务端开发的缓存基石与电商实践-优雅草卓伊凡
Redis:现代服务端开发的缓存基石与电商实践-优雅草卓伊凡
222 5
Redis:现代服务端开发的缓存基石与电商实践-优雅草卓伊凡
|
8月前
|
NoSQL 算法 安全
redis分布式锁在高并发场景下的方案设计与性能提升
本文探讨了Redis分布式锁在主从架构下失效的问题及其解决方案。首先通过CAP理论分析,Redis遵循AP原则,导致锁可能失效。针对此问题,提出两种解决方案:Zookeeper分布式锁(追求CP一致性)和Redlock算法(基于多个Redis实例提升可靠性)。文章还讨论了可能遇到的“坑”,如加从节点引发超卖问题、建议Redis节点数为奇数以及持久化策略对锁的影响。最后,从性能优化角度出发,介绍了减少锁粒度和分段锁的策略,并结合实际场景(如下单重复提交、支付与取消订单冲突)展示了分布式锁的应用方法。
618 3
|
8月前
|
存储 NoSQL Java
从扣减库存场景来讲讲redis分布式锁中的那些“坑”
本文从一个简单的库存扣减场景出发,深入分析了高并发下的超卖问题,并逐步优化解决方案。首先通过本地锁解决单机并发问题,但集群环境下失效;接着引入Redis分布式锁,利用SETNX命令实现加锁,但仍存在死锁、锁过期等隐患。文章详细探讨了通过设置唯一标识、续命机制等方法完善锁的可靠性,并最终引出Redisson工具,其内置的锁续命和原子性操作极大简化了分布式锁的实现。最后,作者剖析了Redisson源码,揭示其实现原理,并预告后续关于主从架构下分布式锁的应用与性能优化内容。
403 0
|
8月前
|
缓存 NoSQL 关系型数据库
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?
美团面试:MySQL有1000w数据,redis只存20w的数据,如何做 缓存 设计?