如何保证Redis缓存和数据库的一致性问题
熟练掌握Redis缓存技术？
那么请问Redis缓存中有几种读写策略，又是如何保证与数据库的一致性问题
今天来聊一聊常用的三种缓存读写策略
Cache Aside Pattern
Cache Aside Pattern 是我们平时使用比较多的一个缓存读写模式，比较适合读请求比较多的场景，服务端需要同时维系 db 和 cache，并且是以 db 的结果为准
那么服务端到底是先更新db还是先更新cache？
1.先更新数据库
读
- 查询缓存，缓存中查询到了直接返回
- 查询不到时查询数据库，
- 查询完数据库后将数据更新至缓存
写
- 修改数据库
- 删除缓存
那么能不能先删除缓存再更新数据库呢？
答案是 不能，这样会导致数据的不一致性
当请求A 发起写请求，此时删除缓存，同时请求B发起读请求，由于没有缓存查询数据库，随后请求A更新数据库
通常情况下，查询数据库的速度比修改数据库更快。这是因为查询操作通常只涉及对数据库中的数据进行读取和匹配，并且可以使用合适的索引来加速查询过程。相比之下，修改操作需要对数据库中的数据进行写入和更新，可能还需要触发额外的数据库约束、触发器或日志记录等操作，这些都会增加一定的开销和时间。
那么是不是先更新数据库再删除缓存是不是就没有数据不一致的情况呢？
答案是 并不是
当请求A发起读请求，恰巧此时缓存过期，需要查询数据库，此时请求B发起写请求，由于没有缓存，故不会执行删除缓存操作，请求A查询完数据库将数据写入缓存，请求B随后更新数据库
但因为要同时达成读缓存时缓存失效并且有并发写的操作，而操作缓存比操作数据库要快得多，所以概率要小很多
那么如何解决这种情况呢？
更新完数据后的时候同时更新缓存，并且我们需要加一个锁/分布式锁来保证更新 cache 的时候不存在线程安全问题，确保数据库和缓存的强一致问题
2.先更新缓存
读
- 查询缓存，缓存中查询到了直接返回
- 查询不到时查询数据库，
- 查询完数据库后将数据更新至缓存
写
- 先更新缓存
- 再更新数据库
首先如果缓存更新成功但数据库更新失败，会导致数据不一致的问题
其次当请求A发起写请求，先更新缓存，于此同时请求B发起读请求，返回数据后，数据库被更新，照成了数据不一致的情况
这种概率大吗？
大，因为redis操作比数据库操作快的多，很容易发生
redis为什么那么快？
第一，Redis 的大部分操作在内存上完成，内存操作本身就特别快；
第二，Redis追求极致，选择了很多高效的数据结构，并做了非常多的优化，比如 hash，跳表，有时候一种对象底层有几种实现以应对不同场景。
第三，Redis 采用了多路复用机制，使其在网络 IO 操作中能并发处理大量的客户端请求，IO 多路复用机制是指一个线程处理多个 IO 流，就是我们经常听到的 select/epoll 机制。简单来说，在 Redis 只运行单线程的情况下，该机制允许内核中，同时存在多个监听 Socket 和已连接 Socket。内核会一直监听这些 Socket 上的连接请求或数据请求。一旦有请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果。
而我们的Cache Aside Pattern采用的就是第一种情况先更新数据库，比较适合读请求比较多的场景
那么对于首次请求一定不存在cache的情况如何解决呢？
可以设置定时任务将热点数据提前放入 cache 中
Read/Write Through
原理：Read/Write Through原理是把更新数据库的操作由缓存代理，cache 服务负责将此数据读取和写入 db，从而减轻了应用程序的职责。
Read Through：如果命中缓存则直接返回数据，如果没有命中则查询数据库，随后写入到缓存中并返回
Write Through：当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后再由缓存自己更新数据库（这是一个同步操作）。
Write Behind
原理：在更新数据的时候，只更新缓存，不更新数据库，而缓存会异步地批量更新数据库。这个设计的好处就是让数据的I/O操作非常快，带来的问题是，数据不是强一致性的，而且可能会丢。
对比Read/Write Through 是同步更新 cache 和 db，而 Write Behind 则是只更新缓存，不直接更新 db，而是改为异步批量的方式来更新 db
非常适合一些数据经常变化又对数据一致性要求没那么高的场景，比如浏览量、点赞量