redis 的惊群处理和分布式锁的应用例子_redisson 惊群效应

在并发量比较高的情况下redis有很多应用场景，提升查询效率，缓解底层DBio ，下面列举两个平时开发中应用过的两个例子，欢迎各位一起讨论改进。

 1 . redis 惊群处理

1.1 方案的由来

Redis的缓存数据库是为快速响应客户端减轻数据库压力的有效手段之一，其中有一种功能是失效缓存，其优点是可以不定期的释放使用频率低的业务空间而增加有限的内存，但对于同步数据库和缓存之间的数据来说需要面临一个问题就是：在并发量比较大的情况下当一个缓存数据失效之后会导致同时有多个并发线程去向后端数据库发起请求去获取同一业务数据，这样如果在一段时间内同时生成了大量的缓存，然后在另外一段时间内又有大量的缓存失效，这样就会导致后端数据库的压力陡增，这种现象就可以称为“缓存过期产生的惊群现象”！

1.2 处理逻辑

  缓存内真实失效时间time1

  缓存value中存放人为失效时间戳 ：time2 （ time2 永远小于time1）

  缓存value对应的lock锁（就是一个与value 对应的 另一个key），主要用于判断是第几个线程来读取redis的value

   当把数据库的数据写入缓存后，这时有客户端第一次来读取缓存，取当前系统时间:system_time 如果system_time >= time2  则认为默认缓存已过期（如果system_time< time1 则还没真实失效 ），这时再获取value的lock锁，调用redis的incr函数（单线程自增函数）判断是第几个获取锁的线程，当且仅当是第一个线程时返回1，以后都逐渐递增。第一个访问的线程到数据库中获取最新值重新放入缓存并删除lock锁的key，并重新设置时间戳；在删除lock之前所有访问value客户端线程获取lock的value都大于1，这些线程仍然读取redis中的旧值，而不会集中访问数据库。

1.3 伪代码

private long expirt_time = 1000 * 40 ;//人为过期时间

private long time = 1000 * 60;//一分钟

private long second = 60 * 6;//六分钟

KooJedisClient client =SpringContextUtils.getBean("redisClient", KooJedisClient.class);

private final String user_key ="USER_REDIS";

private final String user_key_lock ="USER_REDIS_lock";

 

public void setExpireTime( HttpServletRequestrequest  ){

        StringuserId = request.getParameter( "userId");

        //数组里存放：1：真实value ,2：过期时间

        Stringkey = org.apache.commons.lang3.StringUtils.join(new Object[]{user_key,userId});

        String[]info = client.get( key , String[].class);

        longnowTime = System.curre