作者 陈彩华
文章转载交流请联系 caison@aliyun.com本文主要介绍大型分布式系统中缓存的相关理论，常见的缓存组件以及应用场景。
1 缓存概述
2 缓存的分类
缓存主要分为以下四类
2.1 CDN缓存
基本介绍
CDN(Content Delivery Network 内容分发网络)的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求
应用场景
主要缓存静态资源，例如图片，视频
应用图
优点
2.2 反向代理缓存
基本介绍
反向代理位于应用服务器机房，处理所有对WEB服务器的请求。
如果用户请求的页面在代理服务器上有缓冲的话，代理服务器直接将缓冲内容发送给用户。如果没有缓冲则先向WEB服务器发出请求，取回数据，本地缓存后再发送给用户。通过降低向WEB服务器的请求数，从而降低了WEB服务器的负载。
应用场景
一般只缓存体积较小静态文件资源，如css、js、图片
应用图
开源实现
2.3 本地应用缓存
基本介绍
指的是在应用中的缓存组件，其最大的优点是应用和cache是在同一个进程内部，请求缓存非常快速，没有过多的网络开销等，在单应用不需要集群支持或者集群情况下各节点无需互相通知的场景下使用本地缓存较合适；
同时，它的缺点也是应为缓存跟应用程序耦合，多个应用程序无法直接的共享缓存，各应用或集群的各节点都需要维护自己的单独缓存，对内存是一种浪费。
应用场景
缓存字典等常用数据
缓存介质
实现
编程直接实现
Ehcache
基本介绍
Ehcache是一种基于标准的开源缓存，可提高性能，卸载数据库并简化可伸缩性。
它是使用最广泛的基于Java的缓存，因为它功能强大，经过验证，功能齐全，并与其他流行的库和框架集成。Ehcache可以从进程内缓存扩展到使用TB级缓存的混合进程内/进程外部署
应用场景
Ehcache架构图
Ehcache主要特征
Ehcache缓存数据过期策略
Ehcache过期数据淘汰机制
懒淘汰机制：每次往缓存放入数据的时候，都会存一个时间，在读取的时候要和设置的时间做TTL比较来判断是否过期
Guava Cache
2.4 分布式缓存
基本介绍
Guava Cache是Google开源的Java重用工具集库Guava里的一款缓存工具
特点与功能
应用场景
数据结构图
缓存更新策略
缓存回收策略
2.4 分布式缓存
指的是与应用分离的缓存组件或服务，其最大的优点是自身就是一个独立的应用，与本地应用隔离，多个应用可直接的共享缓存。
主要应用场景
主要接入方式
下面介绍分布式缓存常见的2大开源实现Memcached和Redis
Memcached
基本介绍
Memcached是一个高性能，分布式内存对象缓存系统，通过在内存里维护一个统一的巨大的hash表，它能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等。简单的说就是将数据调用到内存中，然后从内存中读取，从而大大提高读取速度。
特点
基本架构
缓存数据过期策略
LRU（最近最少使用）到期失效策略，在Memcached内存储数据项时，可以指定它在缓存的失效时间，默认为永久。当Memcached服务器用完分配的内时，失效的数据被首先替换，然后也是最近未使用的数据。
数据淘汰内部实现
懒淘汰机制：每次往缓存放入数据的时候，都会存一个时间，在读取
的时候要和设置的时间做TTL比较来判断是否过期
分布式集群实现
服务端并没有 “ 分布式 ” 功能。每个服务器都是完全独立和隔离的服务。 Memcached的分布式，是由客户端程序实现的
Redis
基本介绍
Redis是一个远程内存数据库（非关系型数据库），性能强劲，具有复制特性以及解决问题而生的独一无二的数据模型。它可以存储键值对与5种不同类型的值之间的映射，可以将存储在内存的键值对数据持久化到硬盘，可以使用复制特性来扩展读性能，
Redis还可以使用客户端分片来扩展写性能。内置了 复制（replication），LUA脚本（Lua scripting），LRU驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘持久化（persistence）， 并通过 Redis哨兵（Sentinel）和自动分区（Cluster）提供高可用性（high availability）。
数据模型
数据淘汰策略
数据淘汰内部实现
持久化方式
底层实现部分解析
启动的部分过程图解
server端持久化的部分操作图解
底层哈希表实现(渐进式Rehash)
初始化字典
新增字典元素图解
Rehash执行流程
缓存设计原则
Redis与Memcached比较
| Redis | Memcached | |
|---|---|---|
| 支持的数据结构 | 哈希、列表、集合、有序集合 | 纯kev-value |
| 持久化支持 | 有 | 无 |
| 高可用支持 | redis天然支持集群功能，可以实现主动复制，读写分离。官方也提供了sentinel集群管理工具，能够实现主从服务监控，故障自动转移，这一切，对于客户端都是透明的，无需程序改动，也无需人工介入 | 需要二次开发 |
| 存储value容量 | 最大512M | 最大1M |
| 内存分配 | 临时申请空间，可能导致碎片 | 预分配内存池的方式管理内存，能够省去内存分配时间 |
| 虚拟内存使用 | 有自己的VM机制，理论上能够存储比物理内存更多的数据，当数据超量时，会引发swap，把冷数据刷到磁盘上 | 所有的数据存储在物理内存里 |
| 网络模型 | 非阻塞IO复用模型,提供一些非KV存储之外的排序，聚合功能，在执行这些功能时，复杂的CPU计算，会阻塞整个IO调度 | 非阻塞IO复用模型 |
| 水平扩展的支持 | 暂无 | 暂无 |
| 多线程 | Redis支持单线程 | Memcached支持多线程,CPU利用方面Memcache优于Redis |
| 过期策略 | 有专门线程，清除缓存数据 | 懒淘汰机制：每次往缓存放入数据的时候，都会存一个时间，在读取的时候要和设置的时间做TTL比较来判断是否过期 |
| 单机QPS | 约10W | 约60W |
| 源代码可读性 | 代码清爽简洁 | 能是考虑了太多的扩展性，多系统的兼容性，代码不清爽 |
| 适用场景 | 复杂数据结构、有持久化、高可用需求、value存储内容较大 | 纯KV，数据量非常大，并发量非常大的业务 |
3 分层缓存架构设计
4 缓存带来的复杂度问题
常见的问题主要包括
- 数据一致性
- 缓存穿透
- 缓存雪崩
- 缓存高可用
- 缓存热点
下面逐一介绍分析这些问题以及相应的解决方案。
数据一致性
因为缓存属于持久化数据的一个副本，因此不可避免的会出现数据不一致问题。导致脏读或读不到数据的情况。数据不一致，一般是因为网络不稳定或节点故障导致
问题出现的常见3个场景以及解决方案：
缓存穿透
缓存一般是Key，value方式存在，当某一个Key不存在时会查询数据库，假如这个Key，一直不存在，则会频繁的请求数据库，对数据库造成访问压力。
主要解决方案：
- 对结果为空的数据也进行缓存，当此key有数据后，清理缓存
- 一定不存在的key，采用布隆过滤器，建立一个大的Bitmap中，查询时通过该bitmap过滤
缓存雪崩
缓存高可用
缓存是否高可用，需要根据实际的场景而定，并不是所有业务都要求缓存高可用，需要结合具体业务，具体情况进行方案设计，例如临界点是是否对后端的数据库造成影响。
主要解决方案：
- 分布式：实现数据的海量缓存
- 复制：实现缓存数据节点的高可用
缓存热点
一些特别热点的数据，高并发访问同一份缓存数据，导致缓存服务器压力过大。
解决：复制多份缓存副本，把请求分散到多个缓存服务器上，减轻缓存热点导致的单台缓存服务器压力
5 业界案例
案例主要参考新浪微博陈波的技术分享
技术挑战
Feed缓存架构图
架构特点
新浪微博把SSD应用在分布式缓存场景中，将传统的Redis/MC + Mysql方式，扩展为 Redis/MC + SSD Cache + Mysql方式，SSD Cache作为L2缓存使用，第一降低了MC/Redis成本过高，容量小的问题，也解决了穿透DB带来的数据库访问压力
主要在数据架构、性能、储存成本、服务化等不同方面进行了优化增强
