面试题：Redis与MySQL缓存一致性在高并发读写下的保障策略

Question

在高并发读写场景中，如何保证Redis缓存数据与MySQL数据库数据的一致性？说明常见的缓存更新策略及其优缺点，并且针对读写比不同的场景，怎样选择更合适的策略？

Answer 1

保证Redis缓存数据与MySQL数据库数据一致性的方法

1. 缓存更新策略：
   • 先更新数据库，再更新缓存：
     • 优点：实现相对简单，在单线程操作场景下能保证数据一致性。
     • 缺点：在高并发场景下，如果有两个写操作同时进行，先执行更新数据库操作的线程，后执行更新缓存操作，会导致数据不一致。例如线程A更新数据库，此时线程B也更新数据库，接着线程B更新缓存，最后线程A更新缓存，那么缓存中的数据就是线程A的旧数据。
   • 先删除缓存，再更新数据库：
     • 优点：操作相对简单，能解决大部分并发场景下的一致性问题。当数据更新时，先删除缓存，后续读操作会从数据库加载最新数据并写入缓存。
     • 缺点：存在缓存击穿问题。在高并发情况下，如果在删除缓存和更新数据库之间，有大量读请求到来，这些请求会直接穿透到数据库，可能压垮数据库。
   • 先更新数据库，再删除缓存：
     • 优点：这是目前应用较为广泛的策略，在高并发场景下相对可靠。先更新数据库保证了数据的持久化，再删除缓存确保下次读操作能从数据库加载最新数据。
     • 缺点：同样可能存在短暂的数据不一致。例如在更新数据库后，还未来得及删除缓存时，有读请求，会读到旧的缓存数据。不过这种不一致时间通常较短。另外，如果删除缓存失败，也可能导致数据不一致。
2. 读写比不同场景下策略的选择：
   • 读多写少场景：
     • 策略选择：优先选择先更新数据库，再删除缓存策略。
     • 原因：读多写少场景下，缓存击穿的风险相对较低，而且这种策略在大部分情况下能保证数据一致性，并且实现成本相对不高。
   • 读写均衡场景：
     • 策略选择：可以考虑先更新数据库，再删除缓存策略，但要结合缓存击穿的防范措施，如设置互斥锁等。也可以评估业务对数据一致性的容忍度，如果能接受短暂不一致，该策略是可行的；如果对一致性要求极高，可以采用一些复杂的分布式事务方案来保证数据一致性，但会增加系统复杂度。
   • 写多读少场景：
     • 策略选择：先删除缓存，再更新数据库策略相对合适，但要重点解决缓存击穿问题，比如使用布隆过滤器等技术减少无效的数据库查询。同时可以考虑适当缩短缓存的过期时间，加快数据的更新频率。