不知道提起redis，大家第一反应想到的是什么，可能大家跟我想的一样，缓存，
其实在日常的工作中，redis的缓存作用真的解决了不少的麻烦，比如对于web来说，是用户量和访问量支持项目技术的更迭和前进。随着服务用户提升。可能会出现以下的一些状况：
页面并发量和访问量并不多，mysql足以支撑自己逻辑业务的发展。那么其实可以不加缓存。最多对静态页面进行缓存即可。
页面的并发量显著增多，数据库有些压力，并且有些数据更新频率较低反复被查询或者查询速度较慢。那么就可以考虑使用缓存技术优化。对高命中的对象存到key-value形式的redis中，那么，如果数据被命中，那么可以省经效率很低的db。从高效的redis中查找到数据。
那redis和同样作为内存缓存的memcache有什么区别呢？
Memcache 的代码层类似 Hash，特点如下：
- 支持简单数据类型
- 不支持数据持久化存储
- 不支持主从
- 不支持分片
Redis 特点如下：
- 数据类型丰富
- 支持数据磁盘持久化存储
- 支持主从
- 支持分片
既然redis这么牛，难道她就是无敌的吗？人无完人，肯定不是啊，我相信也有很多人听到过这样的几个词语
- 缓存穿透
- 缓存并发
- 缓存失效
缓存穿透
注：
上面三个图会有什么问题呢？
我们在项目中使用缓存通常都是先检查缓存中是否存在，如果存在直接返回缓存内容，如果不存在就直接查询数据库然后再缓存查询结果返回。这个时候如果我们查询的某一个数据在缓存中一直不存在，就会造成每一次请求都查询DB，这样缓存就失去了意义，在流量大时，可能DB就挂掉了。那这种问题有什么好办法解决呢？
要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。
有一个比较巧妙的作法是，可以将这个不存在的key预先设定一个值。
比如，"key" , “&&”。
在返回这个&&值的时候，我们的应用就可以认为这是不存在的key，那我们的应用就可以决定是否继续等待继续访问，还是放弃掉这次操作。如果继续等待访问，过一个时间轮询点后，再次请求这个key，如果取到的值不再是&&，则可以认为这时候key有值了，从而避免了透传到数据库，从而把大量的类似请求挡在了缓存之中。
缓存并发
有时候如果网站并发访问高，一个缓存如果失效，可能出现多个进程同时查询DB，同时设置缓存的情况，如果并发确实很大，这也可能造成DB压力过大，还有缓存频繁更新的问题。
我现在的想法是对缓存查询加锁，如果KEY不存在，就加锁，然后查DB入缓存，然后解锁；其他进程如果发现有锁就等待，然后等解锁后返回数据或者进入DB查询。
这种情况和刚才说的预先设定值问题有些类似，只不过利用锁的方式，会造成部分请求等待。
缓存失效
引起这个问题的主要原因还是高并发的时候，平时我们设定一个缓存的过期时间时，可能有一些会设置1分钟啊，5分钟这些，并发很高时可能会出在某一个时间同时生成了很多的缓存，并且过期时间都一样，这个时候就可能引发一当过期时间到后，这些缓存同时失效，请求全部转发到DB，DB可能会压力过重。
那如何解决这些问题呢？
其中的一个简单方案就是将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
我们讨论的第二个问题是针对同一个缓存，第三个问题是针对很多缓存。
总结来看：
- 缓存穿透：查询一个必然不存在的数据。比如文章表，查询一个不存在的id，每次都会访问DB，如果有人恶意破坏，很可能直接对DB造成影响。
- 缓存失效：如果缓存集中在一段时间内失效，DB的压力凸显。这个没有完美解决办法，但可以分析用户行为，尽量让失效时间点均匀分布。
当发生大量的缓存穿透，例如对某个失效的缓存的大并发访问就造成了缓存雪崩。
问题汇总
问题1：
如何解决DB和缓存一致性问题？
答：当修改了数据库后，有没有及时修改缓存。这种问题，以前有过实践，修改数据库成功，而修改缓存失败的情况，最主要就是缓存服务器挂了。而因为网络问题引起的没有及时更新，可以通过重试机制来解决。而缓存服务器挂了，请求首先自然也就无法到达，从而直接访问到数据库。那么我们在修改数据库后，无法修改缓存，这时候可以将这条数据放到数据库中，同时启动一个异步任务定时去检测缓存服务器是否连接成功，一旦连接成功则从数据库中按顺序取出修改数据，依次进行缓存最新值的修改。
问题2：
问下缓存穿透那块！例如，一个用户查询文章，通过ID查询，按照之前说的，是将缓存的KEY预先设置一个值，，如果通过ID插过来，发现是预先设定的一个值，比如说是“&&”，那之后的继续等待访问是什么意思，这个ID什么时候会真正被附上用户所需要的值呢？
答：我刚说的主要是咱们常用的后面配置，前台获取的场景。前台无法获取相应的key，则等待，或者放弃。当在后台配置界面上配置了相关key和value之后，那么以前的key &&也自然会被替换掉。你说的那种情况，自然也应该会有一个进程会在某一个时刻，在缓存中设置这个ID，再有新的请求到达的时候，就会获取到最新的ID和value。
问题3：
其实用redis的话，那天看到一个不错的例子，双key，有一个当时生成的一个附属key来标识数据修改到期时间，然后快到的时候去重新加载数据，如果觉得key多可以把结束时间放到主key中，附属key起到锁的功能。
答：这种方案，之前我们实践过。这种方案会产生双份数据，而且需要同时控制附属key与key之间的关系，操作上有一定复杂度。
问题4：
多级缓存是什么概念呢？
答：多级缓存就像我今天之前给大家发的文章里面提到了，将ehcache与redis做二级缓存。但同样会存在一致性问题，如果我们需要强一致性的话，缓存与数据库同步是会存在时间差的，所以我们在具体开发的过程中，一定要根据场景来具体分析，二级缓存更多的解决是，缓存穿透与程序的健壮性，当集中式缓存出现问题的时候，我们的应用能够继续运行。
说明：本文中提到的缓存可以理解为Redis。
二、缓存穿透与并发方案
上文中介绍了关于缓存穿透、并发的一些常用思路，但是没有明确一些思路的使用场景，下面继续深入探讨。相信不少朋友之前看过很多类似的文章，但是归根结底就是二个问题：
- 如何解决穿透
- 如何解决并发
当并发较高的时候，其实我是不建议使用缓存过期这个策略的，我更希望缓存一直存在，通过后台系统来更新缓存系统中的数据达到数据的一致性目的，有的朋友可能会质疑，如果缓存系统挂了怎么办，这样数据库更新了但是缓存没有更新，没有达到一致性的状态。
解决问题的思路是：如果缓存是因为网络问题没有更新成功数据，那么建议重试几次，如果依然没有更新成功则认为缓存系统出错不可用，这时候客户端会将数据的KEY插入到消息系统中，消息系统可以过滤相同的KEY，只需保证消息系统不存在相同的KEY，当缓存系统恢复可用的时候，依次从mq中取出KEY值然后从数据库中读取最新的数据更新缓存。注意：更新缓存之前，缓存中依然有旧数据，所以不会造成缓存穿透。
下图展示了整个思路的过程：
看完上面的方案以后，又会有不少朋友提出疑问，如果我是第一次使用缓存或者缓存中暂时没有我需要的数据，那又该如何处理呢？
解决问题的思路：在这种场景下，客户端从缓存中根据KEY读取数据，如果读到了数据则流程结束，如果没有读到数据（可能会有多个并发都没有读到数据），这时候使用缓存系统中的setNX方法设置一个值（这种方法类似加个锁），没有设置成功的请求则sleep一段时间，设置成功的请求读取数据库获取值，如果获取到则更新缓存，流程结束，之前sleep的请求这时候唤醒后直接再从缓存中读取数据，此时流程结束。
在看完这个流程后，我想这里面会有一个漏洞，如果数据库中没有我们需要的数据该怎么处理，如果不处理则请求会造成死循环，不断的在缓存和数据库中查询，这时候我们会沿用我之前文章中的如果没有读到数据则往缓存中插入一个NULL字符串的思路，这样其他请求直接就可以根据“NULL”进行处理，直到后台系统在数据库成功插入数据后同步更新清理NULL数据和更新缓存。
流程图如下所示：
总结：在实际工作中，我们往往将上面二个方案组合使用才能达到最佳效果，虽然第二种方案也会造成请求阻塞，但是只是在第一次使用或者缓存暂时没有数据的情况下才会产生，在生产中经过检验在TPS没有上万的情况下是不会造成问题的。
三、热点缓存解决方案
1、缓存使用背景：
我们拿用户中心的一个案例来说明：每个用户都会首先获取自己的用户信息，然后再进行其他相关的操作，有可能会有如下一些场景情况：
- 会有大量相同用户重复访问该项目。
- 会有同一用户频繁访问同一模块。
2、思路解析
- 因为用户本身是不固定的而且用户数量也有几百万尤其上千万，我们不可能把所有的用户信息全部缓存起来，通过第一个场景情况可以看到一些规律，那就是有大量的相同用户重复访问，但是究竟是哪些用户重复访问我们也并不知道。
- 如果有一个用户频繁刷新读取项目，那么对数据库本身也会造成较大压力，当然我们也会有相关的保护机制来确实恶意攻击，可以从前端控制，也可以有采黑名单等机制，这里不在赘述。如果用缓存的话，我们又该如何控制同一用户繁重读取用户信息呢。
请看下图：
我们会通过缓存系统做一个排序队列，比如1000个用户，系统会根据用户的访问时间更新用户信息的时间，越是最近访问的用户排名越排前，系统会定期过滤掉排名最后的200个用户，然后再从数据库中随机取出200个用户加入队列，这样请求每次到达的时候，会先从队列中获取用户信息，如果命中则根据userId，再从另一个缓存数据结构中读取用户信息，如果没有命中则说明该用户请求频率不高。
JAVA伪代码如下所示：
for (int i = 0; i < times; i++) {
user = new ExternalUser();
user.setId(i+"");
user.setUpdateTime(new Date(System.currentTimeMillis()));
CacheUtil.zadd(sortKey, user.getUpdateTime().getTime(), user.getId());
CacheUtil.putAndThrowError(userKey+user.getId(), JSON.toJSONString(user));
}
Set<String> userSet = CacheUtil.zrange(sortKey, 0, -1);
System.out.println("[sortedSet] - " + JSON.toJSONString(userSet) );
if(userSet == null || userSet.size() == 0)
return;
Set<Tuple> userSetS = CacheUtil.zrangeWithScores(sortKey, 0, -1);
StringBuffer sb = new StringBuffer();
for(Tuple t:userSetS){
sb.append("{member: ").append(t.getElement()).append(", score: ").append(t.getScore()).append("}, ");
} System.out.println("[sortedcollect] - " + sb.toString().substring(0, sb.length() - 2));
Set<String> members = new HashSet<String>();
for(String uid:userSet){
String key = userKey + uid;
members.add(uid);
ExternalUser user2 = CacheUtil.getObject(key, ExternalUser.class);
System.out.println("[user] - " + JSON.toJSONString(user2) );
} System.out.println("[user] - " + System.currentTimeMillis());
String[] keys = new String[members.size()]; members.toArray(keys);
Long rem = CacheUtil.zrem(sortKey, keys);
System.out.println("[rem] - " + rem); userSet = CacheUtil.zrange(sortKey, 0, -1);
System.out.println("[remove - sortedSet] - " + JSON.toJSONString(userSet));
但是redis难道除了做缓存之外就没有其他的吗？那你要这么想就太对不起redis了，接着往下看
分布式锁：
在现代的编程语言中，接触过多线程编程的程序员多多少少对锁有一定的了解。简单的说，多线程中的锁就是在多线程环境下，多个线程对共享资源进行修改的时候，保证共享资源一致性的机制。这里不展开说。在分布式环境下，原来的多线程的锁就不管用了，也就出现了分布式锁的需求。所谓分布式锁服务也就是在分布式环境下，保证多个分布式的服务共享的资源一致性的服务。
在分布式环境下实现一个分布式锁服务并不太容易，需要考虑很多在单进程下的锁服务不需要考虑的问题。分布式锁锁的实现也有很多。这里我们讨论在 Java 中通过 redis 来实现。
在 GitHub 中的 redisson 项目中已经有开源的实现。但是那个太复杂了。现在我们来基于单机的 redis 实现一个简单的分布式锁服务。这个服务必须满足下面的要求
- 支持立即获取锁方式，如果获取到返回true，获取不到则返回false；
- 支持等待获取锁方式，如果获取到，直接返回true，获取不到在等待一小段时间，在这一小段时间内反复尝试，如果尝试成功，则返回true，等待时间过后还获取不到则返回false；
- 不能产生死锁的情况；
- 不能释放非自己加的锁；
下面我们用实例来演示在 Java 中利用 redis 实现分布式锁服务
加锁
通过 redis 来实现分布式锁的加锁逻辑如下所示：
根据这个逻辑，实现上锁的核心代码如下所示：
jedis.select(dbIndex);
String key = KEY_PRE + key;
String value = fetchLockValue();
if(jedis.exists(key)){
jedis.set(key,value);
jedis.expire(key,lockExpirseTime);
return value;
}
表面上看这段代码好像没有什么问题，实际上并不能在分布式环境中正确的实现加锁的操作。要能够正确的实现加锁操作，“判断 key 是否存在”、“保存 key-value”、“设置 key 的过期时间”这三步操作必须是原子操作。如果不是原子操作，那么可能会出现下面两种情况：
- 在“判断 key 是否存在”得出 key 不存在的结果步骤后，“保存 key-value”步骤前，另一个客户端执行同样的逻辑，并且执行到了“判断 key 是否存在”步骤，同样得出了 key 不存在的结果。这样会导致多个客户端获得了同一把锁；
- 在客户端执行完“保存 key-value” 步骤后，需要设置一个 key 的过期时间，防止客户端因为代码质量未解锁，在或者进程崩溃未解锁导致的死锁情况。在“保存 key-value”步骤之后，“设置 key 的过期时间”步骤之前，可能进程崩溃，导致“设置 key 的过期时间”步骤失败；
redis 在2.6.12版本之后，对 set 命令进行了扩充，能够规避上面的两个问题。新版的 redis set 命令的参数如下
SET key value [EX seconds] [PX milliseconds] [NX|XX]
新版的 set 命令增加了 EX 、 PX 、 NX|XX 参数选项。他们的含义如下
- EX seconds – 设置键 key 的过期时间，单位时秒
- PX milliseconds – 设置键 key 的过期时间，单位时毫秒
- NX – 只有键 key 不存在的时候才会设置 key 的值
- XX – 只有键 key 存在的时候才会设置 key 的值
这样，原来的三步操作就可以在一个 set 的原子操作里面来完成，规避了上面我们提到的两个问题。
新版的 redis 加锁核心代码修改如下所示：
jedis = redisConnection.getJedis();
jedis.select(dbIndex);
String key = KEY_PRE + key;
String value = fetchLockValue();
if ("OK".equals(jedis.set(key, value, "NX", "EX", lockExpirseTime))) {
return value;
}
解锁
解锁的基本流程如下：
根据这个逻辑，在 Java 中解锁的核心代码如下所示：
jedis.select(dbIndex);
String key = KEY_PRE + key;
if(jedis.exists(key) && value.equals(jedis.get(key))){
jedis.del(key);
return true;
}
return false;
和加锁的时候一样，key 是否存在、判断是否自己持有锁、**删除 key-value **这三步操作需要是原子操作，否则当一个客户端执行完“判断是否自己持有锁”步骤后，得出自己持有锁的结论，此时锁的过期时间到了，自动被 redis 释放了，同时另一个客户端又基于这个 key 加锁成功，如果第一个客户端还继续执行删除 key-value的操作，就将不属于自己的锁给释放了。
这显然是不运行的。在这里我们利用 redis 执行 Lua 脚本的能力来解决原子操作的问题。修改后的解锁核心代码如下所示：
jedis.select(dbIndex);
String key = KEY_PRE + key;
String command = "if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
if (1L.equals(jedis.eval(command, Collections.singletonList(key), Collections.singletonList(value)))) {
return true;
}
另外，判断是否自己持有锁的机制是用加锁的时候的 key-value 来判断当前的 key 的值是否等于自己持有锁时获得的值。所以加锁的时候的 value 必须是一个全局唯一的字符串。扩展：分布式全局唯一ID生成策略
完整的代码如下所示
package com.x9710.common.redis.impl;
import com.x9710.common.redis.LockService;
import com.x9710.common.redis.RedisConnection;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import redis.clients.jedis.Jedis;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Collections;
import java.util.Date;
import java.util.UUID;
/**
* 分布式锁 redis 实现
*
* @author 杨高超
* @since 2017-12-14
*/
public class LockServiceRedisImpl implements LockService {
private static Log log = LogFactory.getLog(LockServiceRedisImpl.class);
private static String SET_SUCCESS = "OK";
private static String KEY_PRE = "REDIS_LOCK_";
private DateFormat df = new SimpleDateFormat("yyyyMMddHHmmssSSS");
private RedisConnection redisConnection;
private Integer dbIndex;
private Integer lockExpirseTime;
private Integer tryExpirseTime;
public void setRedisConnection(RedisConnection redisConnection) {
this.redisConnection = redisConnection;
}
public void setDbIndex(Integer dbIndex) {
this.dbIndex = dbIndex;
}
public void setLockExpirseTime(Integer lockExpirseTime) {
this.lockExpirseTime = lockExpirseTime;
}
public void setTryExpirseTime(Integer tryExpirseTime) {
this.tryExpirseTime = tryExpirseTime;
}
public String lock(String key) {
Jedis jedis = null;
try {
jedis = redisConnection.getJedis();
jedis.select(dbIndex);
key = KEY_PRE + key;
String value = fetchLockValue();
if (SET_SUCCESS.equals(jedis.set(key, value, "NX", "EX", lockExpirseTime))) {
log.debug("Reids Lock key : " + key + ",value : " + value);
return value;
}
} catch (Exception e) {
e.printStackTrace();
} finally {
if (jedis != null) {
jedis.close();
}
}
return null;
}
public String tryLock(String key) {
Jedis jedis = null;
try {
jedis = redisConnection.getJedis();
jedis.select(dbIndex);
key = KEY_PRE + key;
String value = fetchLockValue();
Long firstTryTime = new Date().getTime();
do {
if (SET_SUCCESS.equals(jedis.set(key, value, "NX", "EX", lockExpirseTime))) {
log.debug("Reids Lock key : " + key + ",value : " + value);
return value;
}
log.info("Redis lock failure,waiting try next");
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
} while ((new Date().getTime() - tryExpirseTime * 1000) < firstTryTime);
} catch (Exception e) {
e.printStackTrace();
} finally {
if (jedis != null) {
jedis.close();
}
}
return null;
}
public boolean unLock(String key, String value) {
Long RELEASE_SUCCESS = 1L;
Jedis jedis = null;
try {
jedis = redisConnection.getJedis();
jedis.select(dbIndex);
key = KEY_PRE + key;
String command = "if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
if (RELEASE_SUCCESS.equals(jedis.eval(command, Collections.singletonList(key), Collections.singletonList(value)))) {
return true;
}
} catch (Exception e) {
e.printStackTrace();
} finally {
if (jedis != null) {
jedis.close();
}
}
return false;
}
/**
* 生成加锁的唯一字符串
*
* @return 唯一字符串
*/
private String fetchLockValue() {
return UUID.randomUUID().toString() + "_" + df.format(new Date());
}
}
测试代码
package com.x9710.common.redis.test;
import com.x9710.common.redis.RedisConnection;
import com.x9710.common.redis.impl.LockServiceRedisImpl;
public class RedisLockTest {
public static void main(String[] args) {
for (int i = 0; i < 9; i++) {
new Thread(new Runnable() {
public void run() {
RedisConnection redisConnection = RedisConnectionUtil.create();
LockServiceRedisImpl lockServiceRedis = new LockServiceRedisImpl();
lockServiceRedis.setRedisConnection(redisConnection);
lockServiceRedis.setDbIndex(15);
lockServiceRedis.setLockExpirseTime(20);
String key = "20171228";
String value = lockServiceRedis.lock(key);
try {
if (value != null) {
System.out.println(Thread.currentThread().getName() + " lock key = " + key + " success! ");
Thread.sleep(25 * 1000);
}else{
System.out.println(Thread.currentThread().getName() + " lock key = " + key + " failure! ");
}
} catch (Exception e) {
e.printStackTrace();
} finally {
if (value == null) {
value = "";
}
System.out.println(Thread.currentThread().getName() + " unlock key = " + key + " " + lockServiceRedis.unLock(key, value));
}
}
}).start();
}
}
}
测试结果
Thread-1 lock key = 20171228 failure! Thread-2 lock key = 20171228 failure! Thread-4 lock key = 20171228 failure! Thread-8 lock key = 20171228 failure! Thread-7 lock key = 20171228 failure! Thread-3 lock key = 20171228 failure! Thread-5 lock key = 20171228 failure! Thread-0 lock key = 20171228 failure! Thread-6 lock key = 20171228 success! Thread-1 unlock key = 20171228 false Thread-2 unlock key = 20171228 false Thread-4 unlock key = 20171228 false Thread-8 unlock key = 20171228 false Thread-3 unlock key = 20171228 false Thread-5 unlock key = 20171228 false Thread-0 unlock key = 20171228 false Thread-7 unlock key = 20171228 false Thread-6 unlock key = 20171228 true
从测试结果来看可以看到，9个线程同时给一个 key 加锁，只有一个能够成功获取到锁，其余的客户端都无法获取到锁。
后记
这个代码里面还实现了一个 tryLock 的接口。这个主要是客户端无法获取到锁的时候会在一小段时间内反复尝试是否能够获取到锁。
好了。关于redis的缓存和分布式锁就讲到这里了，不知道各位看的爽不爽
爽的话，给小弟点个赞，加个关注支持一下呀
如果这些满足不了的话，那咱就关注公众号：Java架构师联盟，每日更新技术好文
