架构师训练营：第五周总结

上周学习了大型互联网应用的演变历程中，遇到了哪些问题。都用了什么样的技术方案解决的。这周开始就再深入一层去了解具体的每种技术方案的知识。首先来看：

1. 缓存架构

首先来看看互联网应用各个技术栈中使用的缓存

上图：

从上往下，越靠近上层的缓存对应用资源的节省率越高。

缓存的两种类型

通路缓存：应用仅通过缓存获取数据，缓存中没有时，缓存服务去查询数据库缓存结果并返回给应用。

旁路缓存：应用同时连接缓存服务，与数据库服务。查询时先查询缓存服务，没有再查询数据库服务，并向缓存服务添加缓存。



缓存提升性能的原因

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

2. 缓存存储数据的最终结果形态，不需要中间计算，减少cpu的资源消耗。

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

来看看各种介质数据的访问时间的延迟，下图：



使用缓存时需要注意的问题

1. 不滥用缓存，频繁修改的数据，没有热点的数据不要用缓存

2. 使用缓存就一定会有数据不一致，脏读的现象，要结合业务场景具体调节，缓存的有时时间。

3. 缓存雪崩，缓存服务崩溃，查询压力直接到下游服务，下游各服务无法适应巨大的压力，纷纷崩溃倒置整个系统短时间内都无法使用。

4. 缓存预热，热点数据需要提前做缓存预热。

5. 缓存穿透，针对经常访问但是却不存在的key也缓存，避免请求直接穿透到数据库。

6. 单一职责运用缓存中间件，如果是缓存服务器，就值使用缓存特性。如果是NOSQL数据库，就只使用数据库特性。

2. 消息队列与异步架构

同步调用：上层服务调用下层服务时，等待直到下层服务返回。

异步调用：上层服务调用下层服务时，无须等待下层服务返回



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

点对点模型，如图：



发布订阅模型，如图：

使用消息队列的好处

1. 更好的伸缩性：使用发布订阅模式，在扩展时只需增加订阅者即可。

2. 削峰填谷：有缓冲请求流量的效果，消费者可根据自身处理能力，从消息队列获取请求。

3. 系统隔离，解耦：发布者订阅者无直接依赖关系，订阅者失败重启，不会影响到发布者。



消息队列中间件的选型

• 选择自己熟悉的

• 选择契合自身系统的（语言、平台等方面）

• 选择社区活跃的（问题可以快速在社区得到回应）

3. 负载均衡架构

为什么要使用负载均衡

负载均衡主要是搭配集群使用的，将同一个应用程序同时部署到多个服务器上时，这一组服务器叫集群。

集群带来的问题就是，这么多的服务器，在怎样分配处理请求。负载均衡就是解决请求的分发的问题的。

集群使用负载均衡的架构，如图：

负载均衡的几种结束类型

HTTP 重定向负载均衡：通过web服务器重定向用户请求到某一服务器，HTTP层负载，不安全，暴露集群内部的ip， 不推荐。

DNS 负载均衡：利用DNS负载均衡请求到，用户附近的服务器上。

反向代理负载均衡：利用代理的便捷，缓存与负载兼具。 只适合集群服务器不多的情况。 中间件nginx

IP 负载均衡：IP层的负载均衡，修改ip包中的请求与目标ip实现。 中间件LVS 中间件nginx

数据链路层负载均衡：数据链路层的负载均衡，修改数据链路层数据包的MAC地址，集群使用同一个ip，实现。 中间件LVS

负载均衡的几种算法

• 轮询

• 加权轮询： 按照服务器硬件性能，轮询基础上按照权重分配。

• 随机：简单实用

• 最少连接：请求分发到最少连接的服务器上，符合负载均衡定义

• 源地址散列：ip计算hash，映射到某一个服务器上。保证同一ip每次请求相同的服务器(用处不大）

负载均衡后带来的问题

集群应用的Session管理问题：用户登录后，请求是附带状态的，多个服务器之间如何共享Session.保持用户的请求状态。

解决办法：

• 服务器之间Session复制 （不可取，服务器本地内存受不住，同步操作消耗资源）

• Session绑定 （运用源地址散列负载算法，也不可取，负载均衡的效果体现不出来）

• 利用Cookie 记录 Session (用户可以设置浏览器禁用 Cookie，无法完全覆盖)

• 使用共享的Session服务器（或集群） (目前的通用做法）



4. 数据库方案

主从复制

主从复制数据库主要是把，读写请求分开，从库负责查询请求，主库负责更新请求。主库与从库之间使用BinLog(Mysql)实现同步（不同步dml,ddl语句）。原理和结构如下图：





主主复制

数据库主主复制主要是解决数据库的高可用问题，两个主数据库之间同步，每个主数据库和自己的从库也同步，但是只有一个主数据库接收更新请求，当其中一台不可用时，自动切换另一台主数据库达到高可用性，主主数据库在更新表结构时延迟巨大。主库与主库同步使用ReLog（Mysql）。原理和结构图如下：





数据分片

数据库数据分片，主要解决数据量大的问题。尤其是单表的数据量大的情况。

在做数据分片之前，建议先做业务数据分库。

数据分片的主要原理：

将原来的一个数据一张表的的数据。分成许多片，每一片放在一个数据库中。每个数据库在部署到不同的服务器上。把数据分开储存，增加了数据库的数据存储量，同时顺带提升了一些读写性能。

数据分片的实行方案：

硬编码方式：

1、按照数据有序的id取模求余，将数据存储到对应的分片数据库表中。

2、 额外使用一张分片表，记录数据的分片方式。查询时先插寻数据的分片位置，再去分片数据库表中查询数据。

硬编码方式分片的挑战

• 需要大量额外的代码，处理逻辑因此变得更加复杂

• 无法执行多分片的联合查询

• 无法使用数据库的事务

• 随着数据的增长，如何增加更多的分片服务器。

使用中间件：

1、mycat

2、Amoeba

3、Coba



综合运用数据库方案的部署图

如下：