总结在常见的在Redis实践中遇到的问题和优化方法
缓存穿透
问题
缓存中存储的是数据库中命中的数据,如果没有命中,则会去数据库中去取然后回溯到缓存中。这个时候如果一直访问一个数据库中也没有的数据,就可能造成大量请求直接访问数据库。
优化方案
- 如果从数据库中查询的结果也为空,那么将这个空结果也放到缓存中。这样可能会造成数据不一致的情况(具体取决数据库和缓存的一致性策略),所以要设置一个比较短的过期时间。
- 查询数据库的时候使用互斥锁,查询前首先要得到锁再去查询,没有得到锁的要先等待直到锁可用。但是这种方案可能减低其查询的性能,因为只能够有一个查询存在,所以对于不属于缓存穿透的场景的查询性能会收到影响。
- 知道key的规则或者合法性,可以在业务层就进行一个过滤(通过规则或者布隆过滤器)
缓存雪崩
问题
缓存中设置了失效时间,如果大量缓存在短时间内一起失效,这样访问的压力就都移到数据库中去了。就像发生雪崩一样。
优化方案
- 采用加锁或消息队列,采用单线程的方式,防止失效时大量线程请求数据库。
- 在设置缓存时间的时候,在原来缓存时间的技术上加一个比较小的随机值,避免大量缓存在同一时间失效
热key问题
问题
业务层可能因为一些新闻或者热点事件对一个相同的key在短时间内发出大量请求。如果此时没有命中缓存,就需要构建缓存,但是构建缓存需要时间,在这个时间里面所有对key的请求还是会打到下面的数据库上,造成后端和数据库的压力过大。同时热key本身对缓存系统也会带来非常大的压力。
解决方案
- 还是可以用互斥锁进行解决,确保同一时间只有一个线程查询数据库
- 对于大量请求打到Redis上的解决可以采用在本地构建local cache的方法
大key问题
问题
Redis作为缓存通常是以接口为单位进行存储,也就是说Redis中存储的数据就是接口中返回的东西。
这样能够使得每次请求只有一个原子操作,但是带来的问题就是key会非常大,造成了大key存储的问题。这会导致用这个Redis作为缓存的服务非常不稳定,因为单次请求这个key的读写时间过长数据过多导致后面redis的原子操作可能发生I/O超时,从而导致redis实例命中率波动较大。当缓存命中率比较低的时候,瞬间大量数据请求就会打到数据库,导致带宽不足、数据库压力过大、数据库慢查询过多和平均查询时间变长。
因为我们服务的时间=redis超时时间+数据库慢查询时间+接口逻辑时间,所以大key可能大致整个服务的恶性循环。
优化方案
可以采用将存储单位从接口数据变为原子数据。每个接口数据都是由原子数据拼接而成,这个拼接可以在业务层完成。从而减小Redis请求超时的情况。
批量请求问题
问题
接着上面的问题,当把存储单位从接口数据变成了原子数据以后,势必会造成每个接口的请求数据变多。如果这些请求都通过单个连接去处理,就会造成总体的处理事件过长的问题
优化方案
这个时候可以使用到批量请求的相关接口:批量存取字符串类型的方式分别为mget、mset、pipeline。三者都会将多次操作合并到一次,也就是进行以此连接返回所有数据。但是之间的差异还是比较明显的,比如:
- pipeline:可以支持多个不同类型的操作在一次请求中,但是使用pipeline需要客户端和服务端都支持。当某个命令的执行需要依赖前一个命令的返回结果时,无法使用pipeline。
- mget:只支持get请求,megt过大的时候会导致内存暴涨,然后一直持有不释放
- mset:只支持set请求,且不支持设置过期时间
参考: