微服务实践目录，可以参见连接。
缓存系列包括：
1.微服务管理-11.缓存概述
1.微服务管理-11.缓存-0.技术
1.微服务管理-11.缓存-1.多级缓存设计
1.微服务管理-11.缓存-2.典型缓存架构设计
1.微服务管理-11.缓存-3.实践
1.微服务管理-11.缓存-4.总结
背景
从冯诺依曼体系结构开始计算机就开始考虑处理速度与存储之间的关系。对于缓存来说在CPU中加入缓存的时候是为了解决速度与存储的不协调问题。通过将常用的数据、下一条CPU指令加载到CPU的Cache中而加快因为数据总线读取数据造成的时延。以这种方式减少因为数据读取对处理时间的延时的情况，提高CPU计算时间片使用率。从而提高CPU的处理速度。从这里可以看到缓存的出现就是为了充分体现CPU的处理速度而设计的。
而我们现在经常提到对的缓存是在业务系统层面。基本上已经不考虑CPU的寻址、读取数据的时间了。业务系统中的缓存是随着计算机系统在人们生活中不断的发挥作用。业务系统不断的需要快速的反馈，而业务的处理消耗的时间慢慢的不能被使用者所接受。所以人们开始考虑怎样加快系统的返回时间，人们开始将CPU上的Cache的概念引入到业务系统中。
前人分析计算机系统其实可以分为计算密集型系统和IO密集型系统。对于这两种系统的缓存要求也是不一样的。对于计算密集型系统就像上面所说的缓存需要解决的问题是加快数据读取的速度。对于IO密集型来说系统系统是需要快速检索，并快速聚合。
那么对于现在的大型互联网系统来说应该是计算密集型系统还是IO密集型系统呢？针对这个问题，我的定义是IO密集型系统。具体原因是：对于互联网系统来说最多要操作的是CURD。所以说互联网系统是IO密集型系统。而IO密集型系统又可以分为读密集型和写密集型。而我再把互联网系统定义为IO读密集型系统。
-
IO读密集型系统
对于作者认为互联网系统是IO读密集型系统来说，可能大家不认同。作者在这里举两个例子。
报表系统对于业务系统来说是一个比较常见的部分。报表系统最直观的看法是他是一套计算密集型系统。简单的报表系统对于程序员来说就是查询并且根据计算条件计算出结果并输出。而对于架构师来说这个不可能让程序每次都读取并且占用数据库连接的情况下进行报表操作。对于报表系统来说比较简单的处理方式是报表数据库和业务数据库分离。如果是比较完善体系可以引入OLAP的概念做WD完成报表的内容。如果使用简单的方式的话，分析报表建立维度表，然后以预处理的方式将数据存储在预处理表中。在需要展示时可以直接从维度表或维度表的聚合中获取数据。
工作流管理系统对于业务系统来说系统中查看工作流中数据的地方比产生、修改这部分数据的地方多的多。而且一个工作流管理系统的计算量明显会更小。
个性化推荐系统对于业务系统来说，简单来说就是一个数据源。对于业务系统来说不关心个性推荐系统中的算法，模型等内容。而个性化推荐系统只需要将计算后的数据交付给业务系统即可。
针对这几个例子我们可以简单的认为大部分互联网系统都是IO读密集型系统。
-
概述
对于IO读密集型的互联网系统来说，缓存需要处理那些问题？这里列出要处理的问题，并会在说明这些问题处理方式时说明为什么这些问题需要处理。
- 缓存位置
- 缓存数据规则
- 缓存失效策略
- 缓存序列化与容量
- 缓存类型
下面会以重要性的顺序进行说明。
缓存数据规则
对于系统中会怎样认为那些数据？应该像CPU那样缓存程序代码段的指令还是缓存代码指令所要使用的数据？这个部分可以分为：过程数据规则、数据特征规则。过程数据规则说明应该缓存那些数据。
-
缓存过程数据规则
过程数据是在处理过程中的数据。对于过程中的数据是从原始的数据源中读取开始到真正的从接口返回的数据。这里可以分为：
- 缓存原始数据
从数据源（一般是数据库）中读取过来的数据。 - 缓存半成品数据
从数据源读取之后，进行了部分聚合的情况下的半成品数据。（对于微服务架构模式来说前台服务就是作为数据、服务能力聚合而做的。所以经常性的数据聚合会在前台中完成。） - 缓存成品数据
半成品再次聚合成为成品数据。使数据可以直接返回。
这些数据经常会在我们服务中发现。这里先说规则缓存的数据应该是最接近成品数据的数据。根据我们在背景中说明的互联网系统中最主要的是IO读密集型系统。所以，需要进行数据已最快的速度进行返回。让系统可以以最快的速度进行返回。
不过在缓存数据过程中可能会放因为缓存的问题造成接口响应时间抖动的情况。在这个过程中应尽量的减小影响响应时间方差的处理。
-
缓存粒度规则
缓存一般情况下是Key-Value型数据库，Key的个数其实也影响缓存性能。也影响需要聚合的数据服务过程。通常情况下，缓存的粒度越小，命中率会越高；但是也需要考虑我们在用户QPS放大到缓存QPS的问题。一般情况下缓存放大倍数不应该超过2倍，这个会影响系统的稳定性。
-
缓存数据特性规则
现在大家对于缓存数据的主要考虑点就是根据数据特性进行缓存。主要考虑的内容是使用频繁度+数据大小。
| / | 频繁 | 不频繁 |
|---|---|---|
| 大量 | 缓 | 不 |
| 少量 | 缓 | 不 |
缓存最大的特点是需要加快访问速度。也就是需要对于热点数据进行加速，所以，不管是大量的还是少量的都需要进行缓存。
缓存技术
缓存技术在下一篇缓存技术中进行详细介绍。这里主要说明一些在记性技术选择时，需要考虑到的内容。
- 分布式
- 堆内、堆外
- 持久化
- 换出策略
- 分级支持
- 缓存大小
- 命中率
- 缓存过期策略
- 并发支持
- 性能
缓存失效
先说结论：最终目标设计缓存永不失效的缓存系统。可以通过CQRS模式，事件驱动模式，命令控制环路模式等架构模式设计成一个永不失效的系统。这样可以设计出的系统绝对不会遇到缓存雪崩，缓存批量加载问题。
缓存换出策略：
FIFO、LFU、LRU、ARC、MRU等策略。换出策略时常跟分布式缓存数据再均衡策略有关。在设计与使用缓存技术时需要考虑。
缓存序列化与容量
序列化技术与容量是有关的。Serializable、Json、Hessian、Protobuf、Thrift等。缓存的序列化技术考虑版本化反序列化能力，序列化后大小，序列化性能等。之后的技术选型文章中说明。
缓存相关内容
| 编号 | 工作 | 说明 |
|---|---|---|
| 1 | 缓存初始化 | 缓存初始化触发时间是需要考虑的。通过事件制，还是启动加载？ |
| 2 | 缓存过期 | 过期策略。我坚实的相信不能绝对不要。 |
| 3 | 缓存更新 | 通过事件更新，以补偿机制保证一致性。 |
| 4 | 缓存过期时间更新 | 这里主要是负责在不更新缓存内容的情况下更新缓存过期时间。在IoT设备上经常会用到看门狗，其实更新缓存过期时间也有类似的作用 |
缓存位置：
缓存的位置包括很多。从整个互联网系统通用架构的最前端到最后端的方式进行技术缓存位置说明：
- 搜索服务
- 浏览器
- CDN
- WEB服务器
- 中间件（消息中间件，数据库中间件等）
- 服务的高速缓存
- 数据库查询缓存
- CPU的cache
总结
前几天总结了一句话：同样的Dubbo、同样的Spring Cloud有些公司能实现到几万QPS，几十万QPS，而有些公司只能实现几十的QPS。映射到缓存上有些系统即使用了缓存也就是那么几十的QPS怎么解决？
本文中更多的是解决高性能的问题。而不是简单的解决该怎么用缓存。下一篇文章会专门的介绍缓存技术。
