一、缓存（优化读数据）：

1、定义：存储在计算机上的一个原始的数据复制集，以便于访问。介于数据访问者和数据源之间的一种高速存储，当数据需要多次读取的时候，用于加快读取的速度。

2、各种缓存介质的访问速度：

3、缓存数据的存储结构：

1. Hash 表

2. 树

4、缓存的关键指标：

1. 缓存命中率：

5、影响缓存命中率的因素：

1. 缓存键集合的大小：缓存键的在系统中的使用频率越高，缓存的命中率也就越高。因此，缓存键的取值就不能是一些很离散的值。

2. 缓存可使用的内存空间的大小。

3. 缓存对象的生存时间。

一、常见的缓存实现形式：

1、代理缓存：

用户访问互联网，先经过代理缓存，如果代理缓存缓存有用户要访问的网站，就直接返回，没有就再访问网络。部署在用户一端的，系统架构一般不会考虑。

2、反向代理缓存：

服务器中心会有一个反向代理服务器，这个反向代理服务器代理了服务器中的服务器。当有用户访问时，会先向反向代理服务器访问，反向代理服务器有缓存的话直接返回，没有的话才会向下访问应用服务器。

反向代理服务器可以多层部署，顶层有一个负载均衡服务器，将请求分发到反向代理服务器集群 1 中，然后反向代理服务器集群 1 将请求访问转发到前端 web 服务器集群中，前端服务器集群有访问后端 web 服务器，会将请求发到后端反向代理服务器集群 2，后端反向代理服务器集群 2 会将具体的请求分发到具体的后端服务器中。

3、内容分发网络 CDN：

一般是会将静态内容缓存在 CDN 中，CDN 是有网络运营商提供的一个服务器，它是离用户比较近的一个服务器。如果 CDN 没有缓存就会直接访问互联网。

4、远程分布式缓存：

1. Memcached 分布式对象缓存，每台缓存服务器都缓存不同的数据，每个应用服务通过计算 key 的 hashcode 得到每个缓存对象在哪台服务器上。缓存不武器之间不共享数据。

2. Redis 分布式缓存集群。

二、一致性 Hash 算法：

1、一致性哈希环：将一个还分割成 0 到 2 的 32 次方-1 个节点，将服务器经过 hash 计算分布到 hash 环上，然后将要存储的数据也经过 hash 计算分布到 hash 环上，顺时针找到离这个数据最近的一个服务器节点，进行存储。

缺点：增加一个节点并没有为整个集群分担压力，只是分担了离他最近的结点的压力。如果节点之间 hash 计算过后位置很近，那就会导致每台服务器的数据分布不均匀，有些服务器节点压力大，有些服务器节点压力小。

2、基于虚拟节点的一致性哈希环：

将一个服务器节点虚拟成多个节点（通常 150 个），后然每个虚拟节点经过 hash 计算分布到环上，这样服务器的节点分布就相对来说比较均匀。这样新增一个服务器节点就有可能会对所有的服务节点都会有影响。

3、各个层次的缓存：

4、缓存是系统优化的大杀器：

技术简单、性能提升显著、应用场景多。

应在系统的各个环节思考缓存的使用，但不要滥用缓存。

5、不应使用缓存的场景：

1. 频繁修改的数据：

至少一次写缓存数据，两次以上读取该数据，这个缓存才有意义。一次写入多次读取。

2. 没有热点访问：

内存资源有限，应将热点访问的数据缓存起来，做到缓存 20%的数据，满足 80%的访问，遵循二八定律。

6、缓存注意的问题：

1.数据不一致与脏读：

当有缓存数据修改了，但是缓存还没有修改，这时候就会导致缓存数据不一致。

解决办法：提示用户该修改数据还需多少时间才生效。或使缓存数据失效（系统开销比较大）。

2.缓存雪崩：

 缓存数据失效，导致访问全部到达数据库，数据库支持不了这么大的访问导致系统崩溃。

3. 缓存穿透：

当业务不恰当或者恶意攻击，持续高并发的访问一个不存在的数据，因为缓存中没有保存该数据，就会一直到数据库中访问数据，就会导致数据库的压力比较大。简单方法就是将不存在的数据也缓存起来，设置一个较短的失效时间。

4. 缓存预热：

在系统刚启动的时候，请求就进来了，这个时候缓存还没准备好，就会有大量的请求会到数据库中，数据库的压力就会变大。因此可以在系统启动之前专门跑一个任务将一些热点数据提前缓存在缓存系统中。热启动。

二、消息队列（优化写数据）：

1、同步/异步调用：

1.异步架构优化写性能。

2.同步调用，当有耗时较长的操作时，就会要阻塞等待，影响性能。

3.异步调用，无需等待具体的处理操作，只需关注消息发送到了消息队列，就可以继续向下执行了。如主线程需要知道执行的结果，可以由队列消息消费完了之后，回调主线程的代码，来处理。

2、构建异步调用架构：

1.角色：

消息生产者、消息队列、消息消费者

2.点对点模型：

生产的一个消息只会被消费一次。

3. 发布订阅模型：

生产者生产一个消息会关联一个 topic 主题，订阅了这个主题的消费者都可以消费到这条消息。

3、消息队列的好处：

1. 实现异步处理，提升处理性能。

2. 更好的伸缩。

3. 削峰填谷。

4. 失败隔离和自我修复。生产者和消费任何一方处理过程中发生了错误，都不会影响对方。

5. 解耦。

4、事件驱动架构 EDA：

1. 定义：生产者，生产或发布一个事件，消费者获取该事件处理。由事件的发布驱动后面一系列程序的执行。通过事件关联起来。

5、各种 MQ 比较：

6、产品选型建议：

社区活跃、资料多（错问题了，更容易查找到资料）、未来更有前景。

简单的一个技巧：在百度或者 google 搜索相应的产品名称，搜索到的词条数量表示该产品的活跃度。

三、负载均衡架构：

1、负载均衡服务器：

当用户请求到达时，由负载均衡服务器将用户请求分发给每一台应用服务器。使这些应用服务器分摊这些用户请求。

2、请求分发：

1. HTTP 重定向负载均衡：

有一台 HTTP 重定向负载均衡服务器，当有用户请求时，计算该请求哪台应用服务器，然后返回给用户一个包含了重定向到该应用服务器对应的 IP 地址的相应，让用户重定向到具体的某一台应用服务器。

缺点：一次请求变成了两次请求，效率比较低。安全性问题，应用服务器的 ip 地址暴露给了外网。

2. DNS 负载均衡：

在用户请求的时候，用户请求的域名会被 DNS 服务解析成具体的 IP 地址，在配置域名解析的时候，配置多个 IP 地址，每次 DNS 解析的时候就会实现负载均衡了。

缺点：应用 IP 地址暴露在外网。

3. 反向代理负载均衡（HTTP 数据包）：

反向代理负载均衡服务器是在数据中心内的，用户的请求达到反向代理负载均衡服务器后，转发到应用服务器。

小规模网站常用，但是像淘宝、百度等不用，原因性能不好，因为他是转发 HTTP 请求，要等待多个 TCP/IP 协议包，当构建成了一个完整的 HTTP 请求后才能进行转发。

4. IP 负载均衡（TCP/IP 数据包）：

当用户发送了一个请求，负载均衡服务器每收到一个 TCP/IP 协议包，直接修改 TCP/IP 协议数据包内的目标 IP 地址为应用服务器 IP 地址，源地址为负载均衡服务器的 IP 地址，然后重新发出去，不构建完整的 HTTP 请求。

当应用服务器返回相应到负载均衡服务器的时候，负载均衡服务器又再次修改 TCP/IP 数据包的源 IP 地址和目标 IP 地址，将响应发送给用户。

缺点：请求的 TCP/IP 数据包可能很小只有几个，但是相应的 TCP/IP 数据包可能会很大比如图片，会有几百几千的 TCP/IP 数据包。此时负载均衡服务器的压力就会比较大。

5. 数据链路层负载均衡：

与 TCP/IP 层负载均衡类似，数据链路层负载均衡主要是修改请求数据的 mac 地址。

负载均衡服务器和应用服务器使用了同一个 IP 地址，当用户的一个请求到达负载均衡服务器时，负载均衡服务器修改请求 TCP/IP 包的 mac 地址，然后再发出。当应用服务器处理完成后，直接发出响应，无需经过负载均衡服务器。

大型互联网架构中常用，性能比较好。

3、负载均衡算法：

轮询：

加权轮询：

随机：

最少连接：记录每台服务器的连接数，找到最小的连接数的服务器。

源地址散列：根据请求的来源的 IP 地址进行 hash 计算，分配到相应的服务器。实现会话粘滞。

4、Session 管理：

1. Session 复制：每台服务器上的 Session 相互复制，保持一致。消耗资源。

2. Session 绑定：使用源地址散列，一个 IP 固定访问一台服务器。

3. 利用 Cookie 记录 Session（使用）。

4. Session 服务器（常用）。

无状态服务器是最好的，最高效，便于扩展的集群架构。