文章目录加载中

缓存设计-崩溃和修复

# 缓存崩溃和恢复

流量打进来,会按照不同的策略分配到不同的缓存上。这里的策略常用的有取模、一致性哈希。

对于取模,节点出问题,如果节点下线,会造成大量缓存不命中,可以通过每个节点主从切换来解决;但是如果有新节点加入,也会造成取模结果不同,造成大量缓存不命中。

所以一般采取一致性哈希,节点上下线,只会影响部分缓存的分配。但如果缓存集群出问题,还是会有问题。

此时,要做到快速恢复,前期就要做到缓存节点一主一从,出问题立即切换流量。也可以对应用进行降级,然后通过任务逐渐预热缓存(模拟用户请求、直接更新缓存等等),最后慢慢减少降级量,逐步恢复应用。

# 痛点问题

# 默认值不合理

问题 1: 默认值不合理,导致回源请求后端,给 db 造成压力。

原因:某个后端接口 api1,本身用户数据就是空,所以返回给调用方的数据为 null。此时调用方将 null 结果返回给前端,缓存 null 作为结果。

当请求再次到来,读取的缓存为空,或者读取不到缓存(因为本身就没数据,上次请求缓存结果就是 null)。此时会再次调用后端接口 api1。当请求变多,相当于缓存没生效,都打到了后端。

解决:默认值可以设置为空字符串,或者空对象(而不是 null),或者其它特殊数据用来标识空数据。在每次读取缓存时,将结果和空数据比较,相同,那么说明用户就是没数据,无需调用后端接口,直接返回即可。

本文来自心谭博客:xin-tan.com,经常更新web和算法的文章笔记,前往github查看目录归纳:github.com/dongyuanxin/blog