Redis 作为缓存是如何工作的

Redis 作为缓存是如何工作的，《Redis 核心技术与实战》学习笔记 12，部分已经作为留言发布，但是留言太多，排在后面的一般很难被大家看到，所以集中发布在这里，欢迎讨论。

题图来自《Redis 核心技术与实战》专栏

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

缓存一般是又快又小。

Redis 不适合无法获得源码的应用。

如果可以选的话，我可能会更多的考虑只读缓存模式，毕竟 Redis 主要是为了提高读的性能。

如果是需要高速读写的场景，比如商品大促、抢红包之类需要修改数据的，那么可以考虑采用读写缓存模式；如果读多写少，比如短视频、图片应用，那么就可以使用只读缓存。

对于课后题，只读缓存同步写数据库的时候，先写数据库，然后将缓存中的数据失效，如需读取，发生缓存失效，然后再从数据库中读取。

读写缓存的直写策略是同步把数据写入 Redis 和后台的数据库，都写完之后才返回。

相对来说两者的写入速度差不多（都是直接写数据库），但是读写缓存的直写策略对于频繁读的应用更友好一点（没有缓存失效的问题）。

看了课代表 @Kaito 的答案，发现自己忽略了读写缓存直写策略有可能造成的缓存和数据库不一致问题，包括高并发和数据库写错误。

如果考虑更为通用的缓存 write through 和 write back，那么 Redis 似乎就只是一个工程实现的问题，需要根据业务 trade off

24 | 替换策略：缓存满了怎么办？

大概 20 年前，有老师说以后的计算机内存会超过 1 GB，游戏可以完全在内存中运行，美好的未来。现在手机的内存已经超过 8 GB 了，但是游戏和应用也膨胀了。

如果不差钱，当然是大量采用 SSD 加内存。

考虑性价比，根据业务需要，结合“二八原则”和“重尾原则”，缓存设置为总数据量的 15% 到 30%。

替换策略讲的比较简单，只概述了 LRU 算法，LFU 应该是 Latest Frequent Used ？期待课代表给科普一下。

另外，Redis 其实不管脏数据写回数据库的事情。

替换策略的选择一般来说是 volatile-lru、allkeys-lru、allkeys-random，前两个没什么问题，但第三个为什么不是 volatile-random？

对于课后题，Redis 缓存对应 只读缓存 模式。看了课代表的答案有点不明觉厉，期待老师后续的答疑。

看了课后老师的回复，才注意到置顶数据的 volatile-lru 策略 + 不设置过期时间的巧妙用法。

之前好像提到，最好是给所有的缓存数据都设置过期时间。