Redis使用规范
一：预防缓存雪崩
方案1：差异化缓存过期时间，不要让大量的 Key 在同一时间过期。
比如，在初始化缓存的时候，设置缓存的过期时间是 30 秒 +10 秒以内的随机延迟（扰动值）。这样，这些Key 不会集中在 30 秒这个时刻过期，而是会分散在 30~40 秒之间过期：
@PostConstruct
public void rightInit1() {IntStream.rangeClosed(1, 1000).forEach(i -> stringRedisTemplate.opsForValue().set("city" + i, getCityFromDb(i), 30 + ThreadLocalRandom.current().nextInt(10), TimeUnit.SECONDS));log.info("Cache init finished");
} |
|---|
方案2：让缓存不主动过期。
初始化缓存数据的时候设置缓存永不过期，然后启动一个后台线程 30 秒一次定时把所有数据更新到缓存，而且通过适当的休眠，控制从数据库更新数据的频率，降低数据库压力。
@PostConstruct
public void rightInit2() throws InterruptedException {CountDownLatch countDownLatch = new CountDownLatch(1);// 每隔30秒全量更新一次缓存Executors.newSingleThreadScheduledExecutor().scheduleAtFixedRate(() -> {IntStream.rangeClosed(1, 1000).forEach(i -> {String data = getCityFromDb(i);// 模拟更新缓存需要一定的时间try {TimeUnit.MILLISECONDS.sleep(20);} catch (InterruptedException e) {}if (!StringUtils.isEmpty(data)) {// 缓存永不过期，被动更新stringRedisTemplate.opsForValue().set("city" + i, data);}});log.info("Cache update finished");countDownLatch.countDown();}, 0, 30, TimeUnit.SECONDS);countDownLatch.await();
} |
|---|
方案一和方案二是截然不同的两种缓存方式，如果无法全量缓存所有数据，那么只能使用方案一；
即使使用了方案二，缓存永不过期，同样需要在查询的时候，确保有回源的逻辑。正如之前所说，我们无法确保缓存系统中的数据永不丢失。
不管是方案一还是方案二，在把数据从数据库加入缓存的时候，都需要判断来自数据库的数据是否合法，比如进行最基本的判空检查。
二：注意缓存击穿问题
@GetMapping("right")
public String right() {String data = stringRedisTemplate.opsForValue().get("hotsopt");if (StringUtils.isEmpty(data)) {// 获取分布式锁RLock locker = redissonClient.getLock("locker");if (locker.tryLock()) {try {data = stringRedisTemplate.opsForValue().get("hotsopt");// 双重检查if (StringUtils.isEmpty(data)) {// 回源到数据库查询data = getExpensiveData();stringRedisTemplate.opsForValue().set("hotsopt", data, 5, TimeUnit.SECONDS);}} finally {locker.unlock();}}}return data;
} |
|---|
在真实的业务场景下，不一定要这么严格地使用双重检查分布式锁进行全局的并发限制，因
为这样虽然可以把数据库回源并发降到最低，但也限制了缓存失效时的并发。可以考虑的方
式是：
方案一，使用进程内的锁进行限制，这样每一个节点都可以以一个并发回源数据库；
方案二，不使用锁进行限制，而是使用类似 Semaphore 的工具限制并发数，比如限制为 10，这样既限制了回源并发数不至于太大，又能使得一定量的线程可以同时回源。
三：注意缓存穿透问题
方案一：缓存空数据
@GetMapping("right")
public String right(@RequestParam("id") int id) {String key = "user" + id;String data = stringRedisTemplate.opsForValue().get(key);if (StringUtils.isEmpty(data)) {data = getCityFromDb(id);//校验从数据库返回的数据是否有效if (!StringUtils.isEmpty(data)) {stringRedisTemplate.opsForValue().set(key, data, 30, TimeUnit.SECONDS);} else {//如果无效，直接在缓存中设置一个NODATA，这样下次查询时即使是无效用户还是可以命中stringRedisTemplate.opsForValue().set(key, "NODATA", 30, TimeUnit.SECONDS);}}return data;
} |
|---|
方案二：使用布隆过滤器
@GetMapping("right2")
public String right2(@RequestParam("id") int id) {String data = "";// 通过布隆过滤器先判断if (bloomFilter.mightContain(id)) {String key = "user" + id;// 走缓存查询data = stringRedisTemplate.opsForValue().get(key);if (StringUtils.isEmpty(data)) {data = getCityFromDb(id);stringRedisTemplate.opsForValue().set(key, data, 30, TimeUnit.SECONDS);}}return data;
} |
|---|
方案一，对于不存在的数据，同样设置一个特殊的 Value 到缓存中，比如当数据库中查出
的用户信息为空的时候，设置 NODATA 这样具有特殊含义的字符串到缓存中。这样下次请
求缓存的时候还是可以命中缓存，即直接从缓存返回结果，不查询数据库。但，这种方式可能会把大量无效的数据加入缓存中，如果担心大量无效数据占满缓存的话还
可以考虑方案二，即使用布隆过滤器做前置过滤。
对于方案二，我们需要同步所有可能存在的值并加入布隆过滤器，这是比较麻烦的地方。如
果业务规则明确的话，你也可以考虑直接根据业务规则判断值是否存在。
其实，方案二可以和方案一同时使用，即将布隆过滤器前置，对于误判的情况再保存特殊值
到缓存，双重保险避免无效数据查询请求打到数据库。
redis缓存更新策略
| 1、先更新缓存，再更新数据库； 导致缓存和数据库的数据不一致。
3、先删除缓存，再更新数据库，访问的时候按需加载数据到缓存；
|
|---|