23 | 旁路缓存：Redis是如何工作的？

Redis只读缓存和使用直写策略的读写缓存，这两种缓存都会把数据同步写到后端数据库中，它们的区别在于： 1、使用只读缓存时，是先把修改写到后端数据库中，再把缓存中的数据删除。当下次访问这个数据时，会以后端数据库中的值为准，重新加载到缓存中。这样做的优点是，数据库和缓存可以保证完全一致，并且缓存中永远保留的是经常访问的热点数据。缺点是每次修改操作都会把缓存中的数据删除，之后访问时都会先触发一次缓存缺失，然后从后端数据库加载数据到缓存中，这个过程访问延迟会变大。 2、使用读写缓存时，是同时修改数据库和缓存中的值。这样做的优点是，被修改后的数据永远在缓存中存在，下次访问时，能够直接命中缓存，不用再从后端数据库中查询，这个过程拥有比较好的性能，比较适合先修改又立即访问的业务场景。但缺点是在高并发场景下，如果存在多个操作同时修改同一个值的情况，可能会导致缓存和数据库的不一致。 3、当使用只读缓存时，如果修改数据库失败了，那么缓存中的数据也不会被删除，此时数据库和缓存中的数据依旧保持一致。而使用读写缓存时，如果是先修改缓存，后修改数据库，如果缓存修改成功，而数据库修改失败了，那么此时数据库和缓存数据就不一致了。如果先修改数据库，再修改缓存，也会产生上面所说的并发场景下的不一致。 我个人总结，只读缓存是牺牲了一定的性能，优先保证数据库和缓存的一致性，它更适合对于一致性要求比较要高的业务场景。而如果对于数据库和缓存一致性要求不高，或者不存在并发修改同一个值的情况，那么使用读写缓存就比较合适，它可以保证更好的访问性能。

对只读缓存方式的操作，先删redis，再修改db，最后删redis。用双删保证数据一致性。

这里有两点问题 老师没有说清楚： 1. 缓存更新模式 常见的就是cache aside 就是老师介绍的只读缓存 2. 读写缓存 有点类似write through 但从老师的叙述中只是特征部分吻合 所以这里要明确指出 因为这并不是主流的四种更新缓存套路，分别是：cahce aside , write through, read through, write behind. 读写一般是和只读缓存共用的 用于分担热点压力 比如说eureka

区别在于：只读缓存，是以数据库的数据为基准同步缓存的方案，读写缓存是同时修改数据库和缓存中的数据，这两种方案都存在数据一致性的问题。比如只读缓存在写回数据库删除缓存时这个时间段的读请求交易，读写缓存缓存的并发访问问题。 数据一致性问题：1.最终一致性方案，优先修改缓存数据，通过队列解耦修改请求到数据库，后台单独处理队列数据保证数据库数据最终一致性。 2.通过分布式事务，把缓存操作和数据库操作通过一个事务完成。这种情况数据能够强一致性 这两种情况都没办法保证，数据脏读的情况，只能保缓存和数据库的数据一致性，如何在保证缓存和数据的数据一致性的情况下，避免脏读的问题，还请大家讨论！

我觉得解决所有问题的办法就是给机房配双电源

分享一个自己在使用缓存的时候遇到的坑： 1、Redis 的缓存数据来自数据库 2、在业务系统上快速对数据进行处理，Redis 是一个热点更新对象 生产环境会遇到这样一个问题：缓存数据从数据库拉取上来的时候，会和任务数据更新Redis冲突，这时候需要分布式锁救场。

只读缓存： ①写时写db，删redis key，写性能好； ②读时读到redis无此key需从db load，只影响修改后首次读性能； ③redis+db数据一致 ④适合读多写少场景 直写策略的读写缓存： ①写时同时写redis+db，首先保证同时成功，db写慢会阻塞redis，整体写性能有影响； ②读数据直接读redis，读性能好； ③如果写db成功，写缓存失败，造成数据不一致，但数据可靠性好 ④适合读多写少场景，感觉还不如用只读缓存，不知道对不对？

针对 Redis 和异步写回策略，等待 Redis 淘汰数据再写回数据库，那 Redis 处理缓存，一定程度上还承担着队列的任务，即向上接受业务的数据，向下把数据写到数据库。 这个情况下，考虑到 Redis 的掉电带来数据丢失的风险，我觉得可以把 Redis 任务方面的需求转移到专业的消息队列中去使用。 这样就需要这样处理： 1、Obj 写 Redis； 2、Obj 入队 Kafka； 由于 Kafka 可以做到数据不丢失，所以这样数据可以更加安全一点，还可以扩展吞吐量。缺点是：引入一个新的中间件，意味着更多更复杂的业务代码结构。

一般业务场景下，先写 DB ，后删缓存 + 删除重试已经可以满足大部分一致性要求了。 如果还要说的话，那就是延迟双删，但是具有一定复杂度，至少我们是没有在产线应用的。 或者是，对于某些场景，也可以在单用户维度做一个简单的分布式锁来限制一下并发，这样也可以降低出现不一致的概率。 另外，就是和数据库事务一起的一些思考🤔：由于快照读的存在，事务内不对缓存做写操作，也可以根据业务场景来看事务结束后是否需要额外做一次删除缓存。