架构师训练营第 0 期第五周学习总结

发布于: 2020 年 07 月 08 日

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、使用消息队列的好处

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

2、更好的伸缩性

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

3、消峰填谷

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

4、失败隔离和自我修复

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

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

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

5、解耦

3-4、事件驱动架构(EDA)

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

3-5、同步调用的耦合

3-6、事件驱动的耦合

问题

1、异步的失败如何做业务的补偿?通常有哪些手段?

用户通知一致性

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地址进行访问;

优点:

1、不需要每次进行域名解析,域名解析结果会在本地进行缓存;

2、DNS解析返回的IP地址不是应用服务器的真实IP,域名解析的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、架构设计不要局限于技术怎么用,而是通过学习这种技术找到其中的优缺点,总结出架构设计的方法;训练自己的架构思维;最重要的是架构设计的思维;

发布于: 2020 年 07 月 08 日 阅读数: 24
用户头像

Albert

关注

还未添加个人签名 2018.08.31 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第0期第五周学习总结