预测两会后中国经济新“风口”

5.1 缓存更新带来的数据不一致与脏读

缓存更新的常见策略有：

1、先更新数据库再更新缓存;

2、先更新数据库再删除缓存;

3、先删除缓存再更新数据库;

4、定时清理缓存;

5、有请求访问数据时，判断缓存是否过期，过期从数据库中刷新缓存。

在这几种方案中，如果修改缓存与数据库不在同一个事物中，就带来了数据不一致和脏读的问题。

对应方案1：先删除缓存再更新数据库，并且在同一个事物中。

对应方案2：缓存自动失效后，另外的异步线程进行缓存更新。

对应方案3：缓存更新在并发、分布式要考虑锁，redis天生就是单线程，比较有优势。

5.2 怎么做缓存预热

缓存预热是指在用户可访问服务之前，将热点数据加载到缓存的操作，这样可以有效避免上线后瞬时大流量造成系统不可用。

缓存预热的一般性策略：

1、开发个缓存刷新功能，手工刷新;

2、项目启动的时候自动进行加载(一般为字典表等数据量不大的数据);

3、设置个定时器，自动刷新缓存;

4、提前统计热点数据，事先批量加载到如redis这样缓存工具中。

5.3 缓存重建

缓存失效后，重建热点缓存，如果耗时较长，在重建过程中，性能、负载不好。

对应方案：

1、正常情况下，交错缓存失效时间，减轻缓存压力;

2、崩溃失效的情况下，可以使用带持久化功能的缓存来恢复，比如Redis;

3、如果是MongoDB则不太一样，它是采用mmap来将数据文件映射到内存中，所以当MongoDB重启时，这些映射的内存并不会清掉，不需要进行缓存重建与预热。

5.4 缓存雪崩与可用性

缓存雪崩：缓存在同一时间失效时，访问直达数据库层，可能导致DB挂掉、系统崩溃。

对应方案1：交错缓存失效时间或随机缓存失效时间。

对应方案2：主从热备(Redis sentinel)。

对应方案3：集群/水平切分(Redis Cluster、一致性哈希)。

5.5 缓存穿透

缓存穿透：持续高并发访问某个不存在的Key。

对应方案1：空值缓存。

对应方案2：布隆过滤器(bloom filter) + bitmap。穷举可能访问的数据放入bitmap中，使用hash访问。

5.6 缓存击穿

缓存击穿：热点Key失效，高并发请求，直击数据库。

缓存击穿与缓存穿透很相似，不同点是是缓存击穿前访问的是真实的热点数据，只是在某一刹那失效了，造成了击穿的效果。

这样看，它其实也是缓存雪崩的一个特例。与雪崩的区别即在于击穿是对于特定的热点数据，而雪崩是全部数据。

对应方案：多级缓存及交错失效时间 + LRU 淘汰算法。

对于热点数据进行二级或多级缓存，并对于不同级别的缓存设定不同的失效时间，缓解雪崩。

此外可使用LRU的变种算法LRU-K缓存数据。

5.7 缓存降级

缓存降级是服务降级中的一环。

在访问量剧增，导致服务出现问题时，为了保证核心服务可用，防止发生缓存雪崩，可进行服务降级。

以redis为例，比较常见的做法就是，不去数据库查询，而是直接返回默认值给用户。

缓存降级也可根据日志级别进行预案设置。



 

（编辑：南通站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!