阿呆的专栏

常见缓存置换算法 LRU 最近最久未使用 FIFO 先进先出置换算法 类似队列 OPT 最佳置换算法 （理想中存在的） NRU Clock置换算法 LFU 最少使用置换算法 PBA 页面缓冲算法 LRU 实现原理：链表+hash表 查询插入时间复杂度：O(1) 代码实现：LinkedHashMap dubbo的工具LRU工具类便是继承自LinkedHashMap：com.alibaba.dubbo.common.utils.LRUCache 数据结构 HashMap结构基础上，为所有Node节点维护一个

上篇文章聊了聊redis框架底层HA与数据库一致性的方案，本篇文章主要介绍redis缓存与数据库之间的一致性问题，以及常用的设计模式 缓存模式 Cache-as-SoR Read/Write Through Write behind caching Cache Aside Cache-as-SoR(system-of-record) Read Through 流程 读（Read Through） 查询缓存模块 缓存模块命中直接返回 缓存模块未命中，缓存模块查询数据库 更新缓存模块并返回 Wr

文章基于redis缓存 缓存设计问题不讨论，感兴趣的同学可以入这个传送门：https://blog.youkuaiyun.com/u010597819/article/details/104220707 缓存一致性问题讨论主要讨论以下两个层次 主从一致性 缓存与数据库一致性 redis主从一致性问题 最终一致性 以哨兵模式为例说明，主从存在延迟，但保证最终一致性。简而言之主从同步的方案为 全量复制，redis fork一个子进程导出rdb文件，并同时记录之后的写命令至缓存（backlog）。rdb同步完成后再将缓

缓存穿透 什么是缓存穿透？ 缓存穿透是指查询大量的key实际不存在 例如：数据库中存储的国内34个省级行政区域信息，id是1-34，缓存的key为id。客户查询35、36、0等等实际不存在的key。因为这些数据实际不存在，所以缓存中也无法命中，便需要服务查询数据库，如果大量此类查询会直接导致数据库扛不住甚至宕机等可能性 解决方案 方案1：将不存在的key缓存起来，超时时间设置得短一些 优点：处理...