成为架构师 - 架构师训练营第 05 周

什么是缓存 Cache 缓存:存储在计算机上的一个原始数据复制集，以便于访问 – 维基百科

缓存是介于数据访问者和数据源之间的一种高速存储，当数据需要多次读取的时候，用

于加快读取的速度。

缓存( Cache )和缓冲 (Buffer )的分别?

无处不在的缓存

CPU 缓存

操作系统缓存

数据库缓存

JVM 编译缓存

CDN 缓存

代理与反向代理缓存

前端缓存

应用程序缓存

分布式对象缓存

缓存数据存储(Hash 表)

key value, key hash 求余找到地址

缓存的关键指标

缓存命中率

• 缓存是否有效依赖于能多少次重用同一个缓存响应业务请求，这个度量指标被称作缓存命中率。

• 如果查询一个缓存，十次查询九次能够得到正确结果，那么它的命中率是 90%。

影响缓存命中率的主要指标

• 缓存键集合大小

• 缓存可使用内存空间

• 缓存对象生存时间

缓存键集合大小

缓存中的每个对象使用缓存键进行 识别，定位一个对象的唯一方式就是对缓存键执行精确匹配。例如，如果想为每个商品缓存在线商品信息，你需要使用商品 ID 作为缓存键。换句话说，缓存键空间是你的应用能够生成的所有键的数量。从统计数字上看，应用生成的唯一键越多，重用的机会越小。例 如，如果想基于客户 IP 地址缓存天气数据，则可能有多达 40 亿个键(这是所有可能的 IP 地址的数量)。如果要基于客户来源国家缓存天气数据，则可能仅需几百个缓存键(世界上所有国家的数量)。一定要想办法减少可能的缓存键数量。键数量越少，缓存的效率越高。

缓存可使用内存空间

缓存可使用内存空间直接决定了缓存对象的平均大小和缓存对象数量。因为缓存通常存储在内存中，缓存对象可用空间受到严格限制且 相对昂贵。如果想缓存更多的对象，就需要先删除老的对象，再添加新的对象。替换(清除)对象会降低缓存命中率，因为缓存对象被删除后，将来的请求就无法命中了。物理上能缓存的对象越多，缓存命中率就越高。

缓存对象生存时间

缓存对象生存时间称为 TTL( Time To Live )。在某些场景中，例如，缓存天气预报数据 15 分钟没问题。在这个场景下， 你可以设置缓存对象预定义 TTL 为 15 分钟。在其他场景中，你可能不能冒险使用过于陈旧的数据。例如，在一个电子商务系统中，店铺管理员可能在任何时刻修改商品价格，如果这些价格需要准确地展示在整个网站中。在这个场景下，你需要在每次商品价格修改时让缓存失效。简单讲，对象缓存的时间越长，缓存对象被重用的可能性就越高。

代理缓存

反向代理缓存

多层反向代理缓存

内容分发网络(CDN)

CDN 同时配置静态文件和动态内容

通读缓存(read-through)

• 代理缓存，反向代理缓存，CDN

• 通读缓存给客户端返回缓存资源，并在请求未命中缓存时获取实际数据。

• 客户端连接的是通读缓存而不是生成响应的原始服务器。

旁路缓存(cache-aside）

• 对象缓存是一种旁路缓存，旁路缓存通常是一个独立的键值对(key-value)存储。

• 应用代码通常会询问对象缓存需要的对象是否存在，如果存在，它会获取并使用缓存的对象，如果不存在或已过期， 应用会连接主数据源来组装对象，并将其保存回对象缓存中以便将来使用。

浏览器对象缓存

// 在 WebStorage 中缓存对象的 JavaScript

var preferences = {/* data object to be stored */};localStorage.setItem('preferences', JSON.stringify(preferences));// 访问缓存对象的 JavaScript

var cachedData = localStorage.getItem('preferences');

var preferences = JSON.parse(cachedData);

本地对象缓存

• 对象直接缓存在应用程序内存中

• 对象存储在共享内存，同一台机器的多个进程可以访问它们。

• 缓存服务器作为独立应用和应用程序部署在同一个服务器上。

本地对象缓存构建分布式集群

远程分布式对象缓存

Memcached 分布式对象缓存

Memcached 分布式缓存访问模型

分布式对象缓存的一致性 hash 算法

一致性 Hash 节点扩容

基于虚拟节点的一致性 Hash 算法

各种介质数据访问延迟

技术栈各个层次的缓存

缓存为什么能显著提升性能

• 缓存数据通常来自内存，比磁盘上的数据有更快的访问速度

• 缓存存储数据的最终结果形态，不需要中间计算，减少 CPU

• 缓存降低数据库、磁盘、网络的负载压力，使这些 I/O 设备获得更好的响应特性。

缓存是系统性能优化的大杀器

• 技术简单

• 性能提升显著

• 应用场景多

合理使用缓存

使用缓存对提高系统性能有很多好处，但是不合理的使用缓存可能非但不能提高系统的性能，还会成为系统的累赘，甚至风险。实践中，缓存滥用的情景屡见不鲜——过分依赖缓存、不合适的数据访问特性等

频繁修改的数据:这种数据如果缓存起来，由于频繁修改，应用还来不及读取就已失效或更新，徒增系统负担。一般说来，数据的读写比在 2:1 以上，缓存才有意义。

没有热点的访问:缓存使用内存作为存储，内存资源宝贵而有限，不能将所有数据都缓存起来，如果应用系统访问数据没有热点，不遵循二八定律，即大部分数据访问不是集中在小部分数据上，那么缓存就没有意义，因为大部分数据还没有被再次访问就已经被挤出缓存了。

数据不一致与脏读:一般会对缓存的数据设置失效时间，一旦超过失效时间，就要从数据库中重新加载。因此应用要容忍一定时间的数据不一致，如卖家已经编辑了商品属性，但是需要过一段时间才能被买家看到。在互联网应用中，这种延迟通常是可以接受的，但是具体应用仍需慎重对待。还有一种策略是数据更新时立即更新缓存，不过也会带来更多系统开销和事务一致性的问题。因此数据更新时通知缓存失效，删除该缓存数据，是一种更加稳妥的做法。

缓存雪崩:缓存是为了提高数据读取性能的，缓存数据丢失或者缓存不可用不会影响到应用程序的处——它可以从数据库直接获取数据。但是随着业务的发展，缓存会承担大部分的数据访问压力，数据库已经习惯了有缓存的日子，所以当缓存服务崩溃的时候，数据库会因为完全不能承受如此大的压力而宕机，进而导致整个网站不可用。这种情况，被称作缓存雪崩，发生这种故障，甚至不能简单的重启缓存服务器和数据库服务器来恢复网站访问。

缓存预热:缓存中存放的是热点数据，热点数据又是缓存系统利用 LRU(最近最久未用)算法对不断访问的数据筛选淘汰出来的，这个过程需要花费较长的时间，在这段时间，系统的性能和数据库负载都不太好，那么最好在缓存系统启动的时候就把热点数据加载好，这个缓存预加载手段叫做缓存预热(warm up)。对于一些元数据如城市地名列表、类目信息，可以启动时加载数据库中全部数据到缓存进行预热。

缓存穿透:如果不恰当的业务、或者恶意攻击持续高并发的请求某个不存在的数据，因为缓存没有保存该数据，所有的请求都会落到数据库上，会对数据库造成很大的压力，甚至崩溃。一个简单的对策是将不存在的数据也缓存起来(其 value 值为 null)，并设定一个较短的失效时间。

Redis VS Memcached

Redis 支持复杂的数据结构

Redis 支持多路复用异步 I/O 高性能

Redis 支持主从复制高可用

Redis 原生集群与 share nothing 集群模式

Redis 集群

• Redis 集群预分好 16384 个桶，当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod 16384 的值，决定将一个 key 放到哪个桶中。

• redis-cluster 把所有的物理节点映射到[0-16383]slot 上(不一定是平均分配)，cluster 负责维护 slot 与服务器的映射关系。

• 客户端与 Redis 节点直连，客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。

• 所有的 Redis 节点彼此互联。

消息队列与异步架构

同步调用 VS 异步调用

消息队列构建异步调用架构

• 消息生产者

• 消息队列

• 消息消费者

点对点模型

发布订阅模型

消息队列的好处

实现异步处理，提升处理性能

更好的伸缩性

削峰填谷

失败隔离和自我修复

因为发布者不直接依赖消费者，所以消息系统可以将消费者系统错误与生产者系统组件

隔离。

生产者和消费者互相不受对方失败影响。

这意味着任意时刻，我们都可以对后端服务器执行维护和发布操作。我们可以重启、添加或删除服务 器而不影响生产者可用性，这样简化了部署和服务器管理的难度。

解耦

事件驱动架构 EDA

主要 MQ

• RabbitMQ 的主要特点是性能好，社区活跃，但是 RabbitMQ 用 Erlang 开发，对不熟

悉 Erlang 的同学而言不便于二次开发和维护。(49M)

• ActiveMQ 影响比较广泛，可以跨平台，使用 Java 开发，对 Java 比较友好。(27M)

• RocketMQ 是阿里推出的一个开源产品，也是使用 Java 开发，性能比较好，可靠性也比较高。(35M)

• Kafka ，LinkedIn 出品的，Scala 开发，专门针对分布式场景进行了优化，因此分布式的伸缩性会比较好。(63M)

负载均衡架构

HTTP 重定向负载均衡

DNS 负载均衡

反向代理负载均衡

IP 负载均衡

数据链路层负载均衡

负载均衡算法

• 轮询:所有请求被依次分发到每个应用服务器上，适合于所有服务器硬件都相同的场景。

• 加权轮询:根据应用服务器硬件性能的情况，在轮询的基础上，按照配置的权重将请求分发到每个服务器，高性能的服务器分配更多请求。

• 随机:请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用，因为好的随机数本身就很均衡。如果应用服务器硬件配置不同，也可以很容易的使用加权随机算法。

• 最少连接:记录每个应用服务器正在处理的连接数(请求数)，将新到的请求分发到最少连接的服务器上，应该说，这是最符合负载均衡定义的算法。

• 源地址散列:根据请求来源的 IP 地址进行 Hash 计算，得到应用服务器，该算法可以保证同一个来源的请求总在同一个服务器上处理，实现会话粘滞。

应用服务器集群的 Session 管理

应用服务器的高可用架构设计主要基于服务无状态这一特性，但是事实上，业务总是有状态的，在交易类的电子商务网站，需要有购物车记录用户的购买信息，用户每次购买请求都是向购物车中增加商品;在社交类的网站中，需要记录用户的当前登录状态、最新发布的消息等以便及时将这些信息通知给他的好友。Web 应用中将这些状态信息称作会话(Session)，单机情况下，Session 可交给 Web 容器管理，在使用负载均衡的集群环境中，Session 管理主要有以下几种手段。

Session 复制

Session 绑定

利用 Cookie 记录 Session

Session 服务器

分布式数据库

MySQL 复制

MySQL 主从复制

MySQL 一主多从复制

一主多从复制的优点

• 分摊负载• 专机专用• 便于冷备• 高可用