缓存雪崩导致的危害息争决办法

计算机软件开发 2024-9-9 15:58:07 83 0 来自 中国
1. Redis 数据失效导致的雪崩

1.png 由于缓存失效,从而导致大量哀求导向数据库。

  • 大量哀求,导致数据库处理处罚不外来,整个体系依靠数据库的功能全部瓦解
  • 单体系挂掉,其他依靠于该体系的应用也会出现不稳定乃至瓦解
2. Redis数据失效的场景



  • 最大内存控制
    maxmemory 最大内存阈值
    maxmemory-policy 到达阈值的实行计谋
3. 缓存雪崩办理方案

3.1 Semaphore信号量限流


  • J.U.C包告急的并发编程工具类
    又称“信号量”,控制多个线程争抢允许。
核心方法

  • acquire:获取一个允许,如果没有就期待,
  • release:开释一个允许。


  • 典范场景∶
    1、代码并发处理处罚限流;
  • 例子
package cn.lazyfennec.cache.redis.service;import cn.lazyfennec.cache.redis.annotations.NeteaseCache;import cn.lazyfennec.cache.redis.dao.UserDao;import cn.lazyfennec.cache.redis.pojo.User;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.cache.annotation.CacheEvict;import org.springframework.data.redis.core.RedisTemplate;import org.springframework.jdbc.core.JdbcTemplate;import org.springframework.stereotype.Service;import java.util.Map;import java.util.concurrent.ConcurrentHashMap;import java.util.concurrent.Semaphore;import java.util.concurrent.TimeUnit;import java.util.concurrent.locks.ReentrantLock;@Service // 默认 单实例public class UserService2 {    @Autowired    UserDao userDao;    @Autowired    RedisTemplate redisTemplate; // spring提供的一个redis客户端,底层封装了jedis等客户端    // userId ---> lock 记载每一个userId当前的查询情况    static Map<String, ReentrantLock> mapLock = new ConcurrentHashMap<>();    static Semaphore semaphore = new Semaphore(50); // 信号量 50 -- 类似车票    /**     * 根据ID查询用户信息 (redis缓存,用户信息以json字符串格式存在(序列化))     */    public User findUserById(String userId) throws Exception {        // 1. 先读取缓存        Object cacheValue = redisTemplate.opsForValue().get(userId); // redisTemplate是spring提供的redis客户端        if (cacheValue != null) {            System.out.println("###缓存掷中:" + ((User) cacheValue).getUname());            return (User) cacheValue;        }        // ---------------缓存miss之后流程--------------        ReentrantLock reentrantLock = new ReentrantLock();        try {            if (mapLock.putIfAbsent(userId, reentrantLock) != null) { // 有返回值代表存在锁                reentrantLock = mapLock.get(userId);            }            Thread.sleep(3000);// TODO 停顿3秒,等下一个线程过来,模仿多个用户同时并发哀求的场景            reentrantLock.lock(); // 争抢锁,抢不到的列队---1个哀求查询数据库 --- 599个期待            Thread.sleep(3000);// TODO 停顿3秒,模仿lock获取之后业务处理处罚时间            // 再次查询缓存 -- 克制大量重复数据库查询            cacheValue = redisTemplate.opsForValue().get(userId); // redisTemplate是spring提供的redis客户端            if (cacheValue != null) {                System.out.println("###缓存掷中:" + ((User) cacheValue).getUname());                return (User) cacheValue;            }            semaphore.acquire(); // 获取信号量 ,没有获取到            // 2. 如果缓存miss,则查询数据库            User user = userDao.findUserById(userId);            System.out.println("***缓存miss:" + user.getUname());            // 3. 设置缓存(重修缓存) // 主播信息查询缓存            redisTemplate.opsForValue().set(userId, user);// set key value            redisTemplate.expire(userId, 100, TimeUnit.SECONDS); // 须要手动设            semaphore.release(); // 开释信号量            return user;        } finally {            if (!reentrantLock.hasQueuedThreads()) { // 当锁末了一个开释的时间,删撤消                mapLock.remove(userId);            }            reentrantLock.unlock();        }    }    @CacheEvict(value = "user", key = "#user.uid") // 方法实行结束,扫除缓存    public void updateUser(User user) {        String sql = "update tb_user_base set uname = ? where uid=?";        jdbcTemplate.update(sql, new String[]{user.getUname(), user.getUid()});    }    /**     * 根据ID查询用户名称     */    // 我自己实现一个类似的注解    @NeteaseCache(value = "uname", key = "#userId") // 缓存    public String findUserNameById(String userId) {        // 查询数据库        String sql = "select uname from tb_user_base where uid=?";        String uname = jdbcTemplate.queryForObject(sql, new String[]{userId}, String.class);        return uname;    }    @Autowired    JdbcTemplate jdbcTemplate; // spring提供jdbc一个工具(mybastis类似)}3.2 容错降级

4.png 如果以为有劳绩就点个赞吧,更多知识,请点击关注检察我的主页信息哦~
您需要登录后才可以回帖 登录 | 立即注册

Powered by CangBaoKu v1.0 小黑屋藏宝库It社区( 冀ICP备14008649号 )

GMT+8, 2024-10-19 04:26, Processed in 0.182213 second(s), 35 queries.© 2003-2025 cbk Team.

快速回复 返回顶部 返回列表