Redis缓存的一些案例

缓存的key有过期策略，如果恰好在这个时间点对这个Key有大量的并发请求，这些请求发现缓存过期一般都会从后端DB回源数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压挂。

业界常用优化方案有两种：

**第一种：**使用分布式锁，保证高并发下，仅有一个线程能回源后端DB。

**第二种：**保证高并发的请求到的Redis key始终是有效的，使用非用户请求回源后端，改成主动回源。一般可以使用异步任务进行缓存的主动刷新。

Redis是单线程的，所以线程安全的。

Redis使用非阻塞IO，并且大部分命令的时间复杂度O(1)。

使用高耗时的命令是非常危险的，会占用唯一的一个线程的大量处理时间，导致所有的请求都被拖慢。

例如：获取所有set集合中的元素 smembers myset，返回指定Hash中所有的member，时间复杂度O(N)。

缓存的Value集合变大，当高并接口请求时，会从Redis读取相关数据，每个请求读取的时间变长，不断的叠加，导致出现热点KEY情况，Redis某个分片处于阻塞，CPU使用率达到100%。

在Redis中，访问频率高的key称为热点key，当某一热点key的请求到Server主机时，由于请求量特别大，导致主机资源不足，甚至宕机，影响正常的服务。

热key问题的产生，有如下两种原因：

用户消费的数据远大于生产的数据，比如热卖商品或秒杀商品、热点新闻、热点评论等，这些典型的读多写少的场景会产生热点问题。
请求分片集中，超过单Server的性能极限，比如固定名称key，哈希落入一台Server，访问量极大的情况，超过Server极限时，就会导致热点Key问题的产生。

那么在实际业务中，如何识别到热点key呢？

当我们识别到热key，如何解决热key问题？

Redis集群扩容：增加分片副本，均衡读流量；
进一步对热key进行散列，比如将一个key备份为key1,key2......keyN，同样的数据N个备份，N个备份分布到不同分片，访问时可随机访问N个备份中的一个，进一步分担读流量。
使用二级缓存，即本地缓存。

当发现热key后，将热key对应数据首先加载到应用服务器本地缓存中，减少对Redis的读请求。