文章目录
1.缓存架构设计
2.缓存常见的文图
- 数据一致性
- 缓存穿透
- 缓存雪崩
- 缓存高可用
- 缓存热点
下面逐一介绍分析这些问题以及相应的解决方案。
2.1 数据一致性
因为缓存属于持久化数据的一个副本，因此不可避免的会出现数据不一致问题。导致脏读或读不到数据的情况。数据不一致，一般是因为网络不稳定或节点故障导致
场景以及解决方案
- 场景1.先写缓存，在写数据库
- 描述：缓存写成功，但写数据库失败或相应延迟，则下次读取（并发读）缓存时，就会出现脏读
- 解决：这种写缓存的方式本身就是错误的，需要改为先写持久化介质，在写缓存
- 场景2.先写数据库，在写缓存
- 描述：写数据库成功，但写缓存失败，则下次读取缓存时，读不到数据
- 解决方案1（不推荐）：根据写入缓存的响应来进行判断，如果缓存写入失败，则回滚数据库操作；该方法增加了程序的复杂度，不推荐
- 解决方案2（推荐）：缓存使用时，若读缓存失败，先读数据库，在回写缓存
- 场景3.缓存异步刷新
- 描述：数据库操作和写缓存操作不在一个操作步骤中，如在分布式场景下，无法做到同时写缓存或者需要异步刷新的时候
- 解决：确定哪些数据适合此类场景；同时根据经验值确定合理数据的不一致时间，用户数据刷新时间间隔
2.2 缓存穿透、缓存击穿、缓存雪崩
对于缓存穿透、缓存雪崩以及缓存击穿的场景以及解决方案可以参考我的另一篇文章《秒杀系统》2.2解节-使用缓存下的介绍，此处我就不过多的去赘述了。
2.3 缓存高可用
缓存是否高可用，需要根据实际的场景而定，并不是所有业务都要求缓存高可用，需要结合具体业务，具体情况进行方案设计，例如临界点是是否对后端的数据库造成影响。
主要解决方案：
- 分布式：实现数据的海量缓存
- 复制：实现缓存数据节点的高可用
2.4 缓存热点
一些特别热点的数据，高并发访问同一份缓存数据，导致缓存服务器压力过大。
解决：复制多份缓存副本，把请求分散到多个缓存服务器上，减轻缓存热点导致的单台缓存服务器压力
3.相关案例
此处以新浪微博作为案例进行分析
3.1 技术挑战
3.2 缓存架构
Feed缓存架构图：
3.3 架构特点
新浪微博把SSD应用在分布式缓存场景中，将传统的Redis/MC + Mysql方式，扩展为 Redis/MC + SSD Cache + Mysql方式
SSD Cache作为L2缓存使用，第一降低了MC/Redis成本过高，容量小的问题，也解决了穿透DB带来的数据库访问压力
主要在数据架构、性能、储存成本、服务化等不同方面进行了优化增强
通过以上概念以及相关案例分析，我们可以做以下总结：
在做设计缓存架构时，我们需要关注以下内容：
- 集群内高可用
- 集群内扩展性
- 组件高性能
- 存储成本
- 服务化
- 服务配置化
- 服务治理
- 服务监控