【Redis】Redis五大经典业务问题剖析及解决方法

一、缓存穿透

缓存穿透是指当请求的数据既不在缓存中也不存在于数据库中时，请求会直接穿透缓存层，到达数据库层。这通常是由于恶意攻击或者程序错误造成的，比如攻击者故意请求不存在的大量数据，导致缓存不命中，所有的请求都会落到数据库上，从而可能对数据库造成巨大的压力，影响其性能甚至导致崩溃通常是 thread_running 飙高。

解决方案

• 布隆过滤器（Bloom Filter）：布隆过滤器是一种数据结构，可以用来检测一个元素是否在一个集合中。在请求到达缓存之前，先通过布隆过滤器进行检查，如果布隆过滤器判断数据不存在，则直接返回错误响应，避免对数据库的访问。

• 缓存空结果：当查询数据库后发现数据不存在时，可以将这个"空结果"也缓存起来，并设置一个较短的过期时间。这样当再次请求相同的数据时，可以直接从缓存中获取到"空结果"，避免对数据库的访问。需要注意的是，这种方法可能会导致缓存被大量无用的空结果填满，所以需要合理设置过期时间。

• 限制请求：对于异常频繁的访问行为，可以采取限流、封禁IP等手段进行限制。例如，可以对每个用户的访问频率、请求的速度等进行限制，超过限制则暂时封禁其请求。

• 接口鉴权：在接口层做好身份验证和参数校验，不允许非法请求或者格式不正确的请求访问数据库。

• 数据库建立合理索引：对于一些必须要访问数据库的场景，确保数据库有好的查询性能，可以通过建立合理的索引来提高查询效率。

• 二级缓存：使用本地缓存作为一级缓存，Redis作为二级缓存。当本地缓存不命中时再查询Redis，如果Redis也不命中，最后才去查询数据库。这样可以减少直接对Redis的查询请求，降低Redis的压力。

• 前端控制：在前端应用中加强校验，比如表单校验、输入内容的合法性检查等，避免发送无效请求到后端。

二、缓存雪崩

缓存雪崩是指在缓存系统中，由于大量缓存数据在同一时间过期，或者缓存服务宕机，导致所有的请求都直接落到数据库上，造成数据库瞬间承受巨大的访问压力，从而变得不稳定甚至崩溃的现象。这类似于雪崩一样，一旦发生就会导致连锁反应，导致整个系统的性能急剧下降。

解决方案

• 缓存数据的过期时间随机化：设置缓存数据的过期时间时，不要让大量的缓存数据在同一时间点过期。可以对过期时间加上一个随机值，使得缓存数据的过期时间分散开来，防止在同一时刻大面积缓存失效。

• 使用持久化：如果缓存服务支持持久化，比如Redis的RDB和AOF，要确保开启并合理配置这些功能。这样，即使缓存服务重启，也能从持久化的数据中恢复，减少缓存雪崩的风险。

• 设置热点数据永不过期：对于一些热点数据，可以设置为永不过期，或者采用手动更新缓存的策略，避免这些热点数据集体过期。

• 使用多级缓存策略：可以使用本地缓存（如Ehcache）和分布式缓存（如Redis）结合的多级缓存策略，即使分布式缓存不可用，本地缓存仍然可以提供服务，减少对数据库的直接压力。

• 提升缓存服务的高可用性：使用主从复制、哨兵机制、集群等高可用方案来确保缓存服务的稳定性。即便单个节点出现故障，也能快速切换到正常的节点，保障缓存服务不中断。

• 限流和熔断机制：在系统中实施限流和熔断机制，当流量或错误超过一定阈值时，暂时阻止部分请求，保护数据库和系统不被过载。

• 异步队列：当缓存失效后，可以将数据库的读取操作放入异步队列中，用异步处理的方式来缓解瞬时流量对数据库的冲击。

三、缓存击穿

缓存击穿指的是缓存中没有但数据库中有的数据（一般是热点数据）在缓存失效的瞬间，同时有大量并发请求这个数据点，这些请求会直接穿透缓存，全部落到数据库上，造成数据库短时间内的高压力。这与缓存穿透不同，缓存穿透是查询不存在的数据，而缓存击穿则是查询存在但是缓存刚好失效的数据。

解决方案

• 使用互斥锁：对于同一个数据点，在缓存失效时，通过加锁或同步机制，保证不管有多少并发请求，只允许一个请求去数据库查询数据，并更新缓存，其他请求等待缓存被更新后直接从缓存中获取数据。常见的做法是使用分布式锁。

• 设置热点数据永不过期：对于一些访问频率非常高的热点数据，可以设置缓存永不过期，或者缓存失效后由后台维护线程负责更新，而不是由用户请求触发更新。

• 使用双缓存机制（Cache Aside pattern）：当缓存失效时，并不立即删除缓存，而是使用另一个缓存进行更新操作。在新缓存更新完成之前，所有的读请求仍然访问的是旧的缓存。更新完成后再进行切换。

• 提前更新缓存：对于即将到期的数据，可以通过定时任务来检测并更新它。当检测到缓存数据即将到期时，可以提前异步地更新缓存。

• 给缓存设置合理的过期时间：对于一些热点数据，根据业务场景设置合理的过期时间，避免大量并发请求在同一时刻击穿缓存。

• 分布式缓存+本地缓存：可以在本地实现一层缓存，以减少对分布式缓存服务的访问频率，即使分布式缓存服务的数据过期，本地缓存仍然可以提供服务。

• 读写分离和负载均衡：数据库使用读写分离架构和负载均衡策略，将读操作分散到多个从库，减少对主库的直接压力。

四、数据不一致

   

缓存和数据库数据不一致的问题通常是由于缓存层与数据库层之间的数据同步策略不当导致的。这可能发生在以下几种情况：

1. 写操作没有同时更新缓存与数据库。

2. 缓存过期或被删除，而数据库中的数据在此期间被修改。

3. 分布式系统中由于网络延迟或其他问题导致的数据同步延迟。

4. 数据库事务回滚，但缓存更新已经发生。

这些问题可能导致用户获取到过时的数据，影响用户体验，并可能引发更严重的数据一致性问题。

解决方案

1. 缓存更新策略

• 缓存延迟双删：更新数据库数据后，先删除缓存，然后延迟一小段时间再次删除缓存，以确保请求在这段时间内若读取了旧数据，也会再次删除缓存，从而读到最新数据。

• Write/Read Through Cache：利用缓存提供的写通(Writethrough)或读取通(Read through)策略，让缓存管理器负责数据的读写，确保数据的一致性。

• Write Behind Caching：更新操作首先在缓存中执行，然后异步批量更新到数据库，这种策略要考虑数据丢失的风险和数据一致性的问题。

2. 数据库触发器：使用数据库触发器在数据发生变化时自动更新缓存，确保数据一致性。

3. 事务消息：通过使用支持事务的消息队列，将缓存操作和数据库操作放到同一个事务中，确保两者要么都成功，要么都失败。

4. 最终一致性：接受在某个时间窗口内缓存与数据库中的数据不一致，但是通过后台异步进程定期校对并同步数据，保证最终一致性。

5. 使用分布式缓存解决方案：选择支持一致性哈希、数据同步等特性的分布式缓存解决方案，如Redis Cluster，保证数据在多个节点之间的一致性。

6. 版本号/时间戳校验：给数据库记录添加版本号或时间戳，缓存数据时一同缓存这个版本信息，每次读取缓存数据时都检查版本或时间戳是否相符，若不符则重新从数据库加载。

7. 强制缓存过期：设置较短的缓存过期时间，确保数据定期从数据库中刷新。

五、数据并发竞争

数据并发竞争访问问题，通常指的是多个客户端或线程同时对同一数据进行读写操作时，由于没有妥善的并发控制措施导致数据出现不一致或者丢失的情况。这个问题在分布式系统和多用户系统中尤为常见，尤其是在使用像Redis这样的缓存系统时也会遇到。

出现问题的场景

• 计数器更新：比如用Redis计数器统计网站点击量，如果多个请求同时更新计数器，可能会因为读写操作不是原子性导致计数器丢失更新。

• 库存扣减：在电商场景中，多个用户同时下单扣减库存，可能会导致超卖。

• 分布式锁：多个进程需要对同一资源进行操作时，需要使用锁来保证同时只有一个操作可以执行。

• Session共享：在分布式部署的Web应用中，多个服务器上的并发请求需要共享Session信息，可能导致Session数据不一致。

解决方案

• 使用事务：Redis事务可以通过MULTI和EXEC命令来确保一系列命令的原子性执行。

• 使用Lua脚本：Redis可以执行Lua脚本，Lua脚本在执行过程中会被当作一个整体执行，这保证了操作的原子性。

• 使用分布式锁：可以实现一个基于Redis的分布式锁来控制资源的并发访问。比如使用SETNX命令实现锁的获取和释放。

• 乐观锁/Optimistic Locking：使用WATCH命令监视一个或多个键，如果在执行事务前这些键没有被其他命令改变，事务才会被执行。

• 悲观锁/Pessimistic Locking：对于关键业务，可以选择先对数据加锁，在业务处理完成后再解锁，避免其他客户端的访问。

• 限流措施：通过限流算法如令牌桶、漏桶等，控制对某一资源的并发访问数，减少并发冲突。

• 消息队列：使用消息队列将并发请求串行化处理，确保对共享资源的访问是有序的。