Facebook关于缓存一致性的论文解读：Scaling Memcache at Facebook读书思考

最新推荐文章于 2024-08-07 09:15:23 发布

b609355187

最新推荐文章于 2024-08-07 09:15:23 发布

阅读量699

点赞数

分类专栏： redis 文章标签： redis 缓存分布式数据库 java

本文链接：https://blog.csdn.net/b609355187/article/details/115817103

版权

本文介绍了Facebook在缓存一致性方面采用的Cache Aside Pattern及租约（Lease）机制。Cache Aside Pattern在数据变更时先更新数据库再过期缓存，牺牲强一致以保证性能。租约机制用于处理热点key的并发访问，通过租约token避免频繁过期导致的性能影响。当key被删除时，过期缓存会被放入队列，客户端可以选择是否使用。该机制提供了一种并发控制策略，但未详细说明并发修改key的处理方式。

摘要由CSDN通过智能技术生成

最近在读Facebook关于缓存的一个论文，发现有好多很好的创意，记录下来。

1，缓存一致性问题：

Facebook采用Cache Aside Pattern ,如果数据有变更，先更新数据库，在过期缓存，这种是比较常用的方案，并没有保证数据库和缓存的强一致，个人认为是合理的。只要保证强一致，必然会牺牲掉性能，这是无法避免的，网上的各种匪夷所思方案说实在的有点舍本逐末了。耗子叔也在一篇文章中论述了关于缓存一致性的几种方案：

1，Cache Aside Pattern：先写数据库，在过期缓存

2，Read Through：如果发送读 miss ,由缓存数据库去读持久化存储并缓存在自己本地

Write Througn：如果发生write 操作，直接写缓存数据库，由缓存数据库同步更新持久化存储，注意是同步，和下面 write behind 不一样的地方是这里是同步

3，Write Behind ：直接写缓存，由缓存数据库异步更新持久化存储，和Linux的pagecache策略很像