【Redis】Redis 缓存更新方案分析

前言

在业务环境中，频繁访问数据库获取数据的做法是不可取的，为了提升数据请求的效率，目前比较流行的做法就是使用 Redis 缓存服务，将频繁被请求的数据缓存起来，在下一次数据被请求时，根据设定的 key 返回相应的数据。但是，缓存系统的存在，就导致数据库和 Redis 之间需要我们考虑其数据同步的问题。由于两者的数据更新必然不是同时进行的，因此当其中一方出现数据更新时，正在进行的访问就有可能从另一方获取到“肮脏”的数据。接下来，我们就分析一下可能存在的几种方案以及他们各自的优缺点。

方案一：懒加载

服务运行时，Redis 缓存中没有数据，直至接收到数据请求之后，才会去访问数据库获取数据进行返回，并将数据同步到缓存。

这里的缓存更新是由用户请求进行触发的，每一次出现对新数据的请求时，就要对数据库进行一次访问。因此，在并发请求的场景下，缓存数据不存在时，所有的并发请求就会直接打了数据库上，给数据库带来极大的负载，容易造成数据库宕机，影响其他依赖的服务。这种方案一般会伴随着分布式锁，保证一次只能有一个请求访问数据库，并更新缓存，其他请求只能等待该请求完成响应后，直接访问缓存数据。

方案二：手动触发更新，覆盖旧缓存，删除无效缓存

这里的手动触发，是指后台工作人员通过操作启动，亦或是设置定时任务运行更新任务。更新任务触发后，系统会从数据库查询最新的数据集合，覆盖原有的缓存数据，其余的缓存视为无效数据，直接删除。

这个方案保证了任意时刻缓存与数据库都能存在可用的数据，而且能够及时清除无效的缓存数据。但是，该方案的逻辑相对比较复杂，每次更新都需要筛选出不进行缓存覆盖的数据所对应的 key，才能删除无效缓存。这种更新机制与业务内容存在着强关联，无法通用。

方案三：手动触发更新，删除原缓存数据

后台工作人员主动启动缓存更新任务，从数据库批量获取最新的数据集合，然后删除当前缓存的数据，将新数据插入到缓存中。

该方案在更新过程中，缓存在某一段时间内存在没有特定缓存数据的情况，如果此时刚好