1、本周主要内容

• 缓存

• 消息队列与异步架构

• 负载均衡

• 分布式数据库



2、缓存

关于缓存的总结，参考：https://xie.infoq.cn/article/22c1da5c16e2649d20a0361a9



3、消息队列与异步架构

3-1、同步调用与异步调用

3-1-1、同步调用

同步调用的问题：

• 应用程序一直在等待后续任务完成；

• 后续调用很慢，线程被阻塞，系统资源得不到释放，用户程序响应时间较高；

• 同步调用时间会变得很长；

解决方案：

异步调用，远程调用或后续任务耗时较高，将请求数据发送到消息队列，然后直接返回；消息队列的Consumer从消息队列中获取消息，执行操作；

好处：线程不会被阻塞时间较长，资源快速释放；用户响应快；提高系统吞吐能力和处理性能



3-1-2、多个耗时同步调用



3-1-3、异步调用



3-1-4、有回调的异步调用



3-1-5、多次异步调用



3-2、消息队列的异步架构

3-2-1、角色

1、生产者，创建消息，并发送到消费队列；

2、消息队列，消息存放位置；

3、消费者，从消费队列中订阅消息；

3-2-2、消息队列架构模型

1、点对点模型

从队列头部获取消息

消息只会被处理一次



2、发布订阅模型

生产者发送一个消息，这个消息可以被多个消费者消费



3-3、使用消息队列的好处

3-3-1、提升处理性能

实现异步处理，提升处理性能；数据存储是异步的，有可能业务失败，出现逻辑不一致的情况；不返回操作结果；保护数据库和系统



3-3-2、更好的伸缩性

比如文件渲染操作，渲染功能的服务器，从消息队列获取消息，再对文件进行渲染；



3-3-3、消峰填谷

保护系统不会过载，不会因为请求数量突然提升，导致系统负载升高；





3-3-4、失败隔离和自我修复

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

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

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



3-3-5、系统间的解耦



3-4、使用消息队列的问题

3-4-1、增加系统自身复杂性



3-4-2、如何保证消息不丢



3-4-3、如何保证消息不重复发送



3-4-4、如何保证消息不重复消息



3-4-5、异步的失败如何做业务的补偿？通常有哪些手段？

用户通知一致性



3-5、事件驱动架构（EDA）

通过“发布-订阅”模式，将事件发布出去

3-6、同步调用的耦合



3-7、事件驱动的耦合



4、负载均衡架构

所谓负载均衡，将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案

4-1、负载均衡架构

1、用户请求如何发送；

2、请求如何分发；

4-2、负载均衡类型

4-2-1、HTTP重定向负载均衡

1、过程

(1) 用户访问HTTP重定向负载均衡服务器；

(2) HTTP重定向负载均衡服务器返回重定向的服务器IP；



2、优点

简单



3、缺点：

(1) 性能差：用户请求每次都要重定向，需要两次HTTP请求；

(2) 不安全：重定向可以获取服务器的IP，容易被攻击；



4-2-2、DNS负载均衡

1、DNS根据域名解析IP地址；

2、客户端根据IP地址进行访问；

优点：

• 性能：DNS负载均衡【不需要】每次进行域名解析，域名解析结果会在本地进行缓存；

• 安全性：DNS解析返回的IP地址不是应用服务器的真实IP，域名解析的IP地址是负载均衡服务器的IP地址，由负载均衡服务器在分发到应用服务器，淘宝和百度经常使用；为什么不担心安全问题？像淘宝这样的公司，域名解析出来的不是应用服务器真实IP地址，而是负载均衡服务器的地址；

缺点：

因为DNS负载均衡的IP是缓存在客户端本地，如果系统发布或者服务器宕机，客户端还是会访问同一个域名解析的IP地址；



4-2-3、反向代理负载均衡

一般不适用。因为转发的是HTTP请求，HTTP请求性能较差，通信过程较慢；对服务器压力较大，HTTP请求数据包较大；要拿到完整的数据包；



4-2-4、IP负载均衡

源目标IP地址 -> 改为目标IP地址

响应IP地址 -> 源响应用户IP地址

缺点：

(1) 用户请求/响应都要通过负载均衡服务器；

(2) 网络出口带宽称为瓶颈；

4-2-5、数据链路层负载均衡

响应数据不经过负载均衡服务器，直接返回给客户端；

负载均衡服务器请求目标服务器的MAC地址，响应不在经过负载均衡服务器；



4-3、负载均衡算法

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

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

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

• 最少连接：记录每个应用服务器正在处理的连接数（请求数），将新到的请求分发到最少连接的服务器上，这是最符合负载均衡定义的算法；需要维护服务器状态，但是实践中很少使用；

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



4-4、负载均衡模型

OSI是一个开放性的通信系统互连参考模型，他是一个定义得非常好的协议规范。

OSI模型有7层结构，每层都可以有几个子层。 OSI的7层从上到下分别是

7、应用层；

6、表示层；

5、会话层；

4、传输层；

3、网络层；

2、数据链路层；

1、物理层；

其中高层（即7、6、5、4层）定义了应用程序的功能，下面3层（即3、2、1层）主要面向通过网络的端到端的数据流。

在这七层模型种，高层次都是依赖于低层次的。层次越高，使用起来越方便。





TELNET、HTTP、FTP、NFS、SMTP、DNS等属于第七层应用层的概念。

TCP、UDP、SPX等属于第四层传输层的概念。

IP、IPX等属于第三层网络层的概念。

ATM、FDDI等属于第二层数据链路层的概念。



了解了网络协议的七层模型以后，再来看看负载均衡。

可以很明确的一点是，负载均衡是要在网络传输中做文章的。

而要在网络传输过程搞事情，那么这七层模型就势必躲不开。

所以，根据负载均衡技术实现在OSI七层模型的不同层次，是可以给负载均衡分类的。

常见的实现方式中，主要可以在应用层、传输层、网络层和数据传输层做文章。所以，工作在应用层的负载均衡，通常称之为七层负载均衡、工作在传输层的称之为四层负载均衡。



大致可以分为以下几种，其中最常用的是四层和七层负载均衡：

二层负载均衡 

负载均衡服务器对外依然提供一个VIP（虚IP），集群中不同的机器采用相同IP地址，但是机器的MAC地址不一样。当负载均衡服务器接受到请求之后，通过改写报文的目标MAC地址的方式将请求转发到目标机器实现负载均衡。



三层负载均衡

和二层负载均衡类似，负载均衡服务器对外依然提供一个VIP（虚IP），但是集群中不同的机器采用不同的IP地址。当负载均衡服务器接受到请求之后，根据不同的负载均衡算法，通过IP将请求转发至不同的真实服务器。



四层负载均衡 

四层负载均衡工作在OSI模型的传输层，由于在传输层，只有TCP/UDP协议，这两种协议中除了包含源IP、目标IP以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。



七层负载均衡 

七层负载均衡工作在OSI模型的应用层，应用层协议较多，常用http、radius、dns等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个Web服务器的负载均衡，除了根据IP加端口进行负载外，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。 

负载均衡工具

市面上有很多开源的负载均衡的工具或软件，基本都是基于前面提到的方案实现的，大多数是工作在第七层和第四层的。Nginx/LVS/HAProxy是目前使用最广泛的三种负载均衡软件。

LVS ：LVS主要用来做四层负载均衡

LVS（Linux Virtual Server），也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目。使用LVS技术要达到的目标是：通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能、高可用的服务器群集，它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。

Nginx ：Nginx主要用来做七层负载均衡

Nginx（发音同engine x）是一个网页服务器，它能反向代理HTTP, HTTPS, SMTP, POP3, IMAP的协议链接，以及一个负载均衡器和一个HTTP缓存。

HAProxy ：HAProxy主要用来做七层负载均衡

HAProxy是一个使用C语言编写的自由及开放源代码软件，其提供高可用性、负载均衡，以及基于TCP和HTTP的应用程序代理。



4-5、应用服务器的Session管理

4-5-1、Session复制

所有服务器保存session，任何一个服务器的session修改后，同步到其它服务器；

这种方案已经被过时，【集群规模受限制】，如果集群机器数量很大，复制session需要消耗网络请求；当请求变大后，应用服务器的压力更大；



4-5-2、Session绑定

来自相同的IP总是能分发到同一个服务器上；

实现方式：IP作为Key，通过Hash取模确定到对应服务器，取模中的除数是机器数量；

被淘汰的原因是：

可用性低：如果会话绑定，当系统发布时，导致绑定的服务不可用，用户请求到发布中的服务器因为找不到Session而导致服务失败；



4-5-3、利用Cookie记录Session

会话从Cookie中获取Session；

缺点：

1、每次请求都要发送Cookie，网络请求大；

2、有些终端禁用Cookie后，导致无法记录Session；



4-5-4、Session服务器

通过专门的Session服务器（如Redis服务器）保存Session



5、分布式数据库

5-1、MySQL主从复制

目的：

分摊数据库读操作压力，将读操作不会影响到主服务器；

• 数据库更新数据后，将操作（包括 insert、update、delete，不会记录select）记录到BinLog文件；

• 客户端线程从Binlog中获取操作，将操作同步到从服务器上；

• 从服务器不提供写操作，仅提供只读操作；

关键角色：

BinLog 和 RelayLog

一般DDL不同步到从服务器上，比如alter耗时较长，导致其他命令同步要等待alter处理完，导致主从数据不一致；

解决方案：

• 新增字段，先在主库上增加，一定要在应用程序发布前；

• 删除字段，先从应用程序中删除，再从数据库中删除；

在从库上【手工操作】DDL命令；



注意事项：

• 主主复制的数据库不能并发写入，主要原因是会出现数据冲突；

• 复制只是增加数据的读写并发处理能力，并没有增加写并发能力和存储能力；

• 更新表结构会导致巨大的同步延迟，要关闭DDL同步操作；



5-2、MySQL一主多从复制

优点：

• 分摊负载

• 专机专用

• 数据热备

• 高可用

问题：

主服务器挂了，影响写操作；



5-3、MySQL主主复制

主主复制，客户端只会往一台主服务器进行写操作；

并不是为了双写，而是为了数据库的高可用；

不双写的原因，无法保证数据一致性，会出现数据冲突；



问题：

A、主主复制，会不会出现 正在写的数据库 挂了，此时写入的数据 没有同步 到 另一台主机，导致数据丢失？如果出现这样的问题，有什么好的解决办法？

Q、目前没有好的方法；





主服务器失效恢复



MySQL主主失效维护过程



5-4、MySQL复制注意事项

• 主主复制的两个数据库不能并发写入；

• 复制只是增加了数据的【读并发】处理能力，没有增加【写并发】和【存储】能力；

• 更新表结构会导致巨大的同步延迟；



总结

本周学习到几个方面知识中，其中关于性能优化有以下两类

1、提升读性能，可以使用缓存；使用缓存需要注意：

• 需要存储到缓存的数据一定是被【经常读取】的数据；

• 缓存的主要数据结构是哈希表，是一种数组类型的结构；

• 在分布式场景下，通常使用分布式一致性Hash算法；



2、提升写性能，可以使用消息队列；

使用消息队列，需要注意：

• 消息的发送和消费，如果处理失败都需要补偿；

• 消息队列一般使用在后续任务操作耗时在秒级以上的操作，如果是因此存库时间慢引入消息队列，尽量先将数据库升级成更好的硬件或者使用分库分表方式，因为消息队列引入本身增加系统复杂性；



3、架构设计不要局限于技术怎么用，而是通过学习这种技术找到其中的优缺点，总结出架构设计的方法；训练自己的架构思维；最重要的是架构设计的思维；