1、分布式缓存架构

1.1、缓存的作用

• 缓存数据通常是存在内存中的，访问速度比磁盘上的快很多

• 缓存数据一般是结果的最终形态，不需要中间计算，减少CPU资源的消耗

• 缓存可降低数据库、磁盘、网络、服务器的压力

1.2、常用的缓存方案

• CDN缓存

由运营商提供

• 代理缓存

部署在用户端，不属于系统的部分

• 反向代理缓存

代理应用服务器，属于系统的一部分，一般使用在缓存静态资源的场景

• 前端缓存

浏览器对象缓存

• 应用程序缓存

本地缓存

• 分布式对象缓存

redis、memcached



2、消息队列与异步架构

2.1、消息队列的好处

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

将耗时的处理逻辑通过消息驱动的方式进行异步处理，降低用户请求的响应时间。

• 伸缩性

异步处理将用户的请求拆分成了多个步骤，针对不同的步骤需要的资源情况进行针对性的扩容，提升处理能力。

• 削峰填谷

由于请求都发送到了消息队列中，在高峰期，消息缓冲在消息队列中，应用服务器根据自己的能力处理消息，将消息均分到一段时间内处理。

• 失败隔离和自我修复

生产者不直接依赖消费者，任何一方异常都不会相互影响。

• 解耦

生产者和消费者没有直接调用，达到了解耦的目的。

2.2、两种模型

• 点对点模型

多个消费者消费同一个消息队列，一个消息只会被一个消费者处理一次。

• 发布评阅模型

每个消息都会被所有消费者处理。

2.2、常用的MQ产品

• RabbitMQ 的主要特点是性能好，社区活跃，但是 RabbitMQ 用 Erlang 开发，对不熟悉 Erlang 的同学而言不便于二次开发和维护。(49M)

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

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

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



3、负载均衡架构

3.1、常用的负载均衡方案

• HTTP重定向负载均衡

两次HTTP请求影响性能；暴露了应用服务器的IP，安全性差。实际项目中基本不会用到。



• DNS负载均衡

系统不需要实现负载均衡，由域名服务商提供，实现简单。

实际使用中一般使用两层负载均衡，DNS负载均衡转发到系统内的负载均衡服务器。一般互联网系统都会使用这种负载均衡架构。



• 反向代理负载均衡

反向代理服务器需要处理应用层HTTP协议，效率低、性能差，所以只在小规模的应用服务器集群中使用。



• IP负载均衡

通过修改数据包的IP地址实现，不需要解析HTTP协议，处理TCP/IP数据包，性能高。但响应数据包非常大时，网络可能成为性能的瓶颈。



• 数据链路层负载均衡

与IP层的数据不同的是负载均衡服务器只修改MAC地址，不用处理响应请求。负载均衡服务器和应用服务器需要使用同一个虚拟IP。是实际大型系统中使用最多的一种方案。

3.2、负载均衡算法

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

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

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

• 最少连接：记录每个应用服务器正在处理的连接数（请求数），将新到的请求分发到 最少连接的服务器上。应该说，这是最符合负载均衡定义的算法，但实现难度高，价值不高，实践中很少用。

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