极客大学架构师训练营 系统架构 消息队列 数据库备份 第 10 课 听课总结

发布于: 2020 年 07 月 04 日

说明

讲师:李智慧

消息队列与异步架构

同步调用

发邮件时序图:同步调用,每个调用都会阻塞等待。

同步调用:线程前后执行,都要一步一步同步等待结果。

多个耗时操作同步调用

异步调用

异步调用:写入消息队列里面,就直接返回。1毫秒就可以返回,比同步调用快了1,000倍以上。

有回调的异步调用

多次异步调用,不阻塞应用线程

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

重要角色:

  • 消息生产者

  • 消息队列

  • 消息消费者

点对点模型

发布订阅模型

消息队列的好处

实现异步处理,提升写操作处理性能。

支付、订单等需要消息队列,提升的是写操作的性能,特别是双十一这种大促的时候感受等待的时间比较长。

缓存提升的是读的性能,消息队列提升的是写的性能。

更好的伸缩性

削峰填谷

比如服务器的处理能力为100TPS,100并发;当来了200TPS,200并发的时候,消息队列还是按照100TPS,100并发来处理。

失败隔离和自我修复

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

生产者和消费者互相不受双方失败影响。

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

解耦

事件驱动架构 EDA (Event Driven Architecture)

同步调用耦合度高、事件驱动异步调用耦合度低

主要 MQ 产品比较

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

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

  • RocketMQ 是阿里推出的一个开源产品,也是使用 Java 开发,性能比较哈,可靠性也比较高。(社区 35 Million)

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

负载均衡

负载均衡架构

负载均衡就是把请求分发到服务器上。

负载均衡服务器配置的应用服务器为内网ip地址。这样能保护内网服务器的安全。

HTTP 重定向负载均衡

  1. 用户访问一个http请求,DNS解析域名为ip地址,ip地址指向负载均衡服务器;

  2. 负责均衡服务器,获取服务器集群列表,修改http的header为集群中的某台的服务器地址,告诉客户端做302跳转;

  3. 客户端请求集群中的某台的服务器

  4. 集群中的某台的服务器处理完后,返回response。

重定向服务10来行代码,就能实现。

缺点:

  1. 两次http请求,性能差。

  2. 暴露了应用服务器的公网ip,安全性很差。

一般不会采用HTTP 重定向负载均衡。

DNS 负载均衡

  1. 性能方面没有问题,DNS解析只在第一次请求的时候会用到,后面就记录在客户端里面。而且域名的解析是缓存起来的。

  2. 安全方面也没有问题。DNS解析的IP地址是负载均衡服务器的ip地址。

这里用了2级负载均衡服务器。DNS,和DNS返回的ip地址都是负载均衡服务器。

反向代理负载均衡

小型应用会用,通常10几台应用服务器的时候会用。多了以后就不够用了。为什么呢?

因为反向代理服务器转发的是http请求,http请求每次通信的时间比较慢,对反向代理服务器的压力比较大。当并发比较高的时候,反向代理服务器就会成为瓶颈。

IP 负载均衡

TCP/IP 的数据包比较小,一般是几K。

  1. 客户端发起请求,请求到达负载均衡服务器,负载均衡服务器修改发起的ip为自己,目标地址为应用服务器。

  2. 应用服务器处理请求后返回给负载均衡服务器,负载均衡服务器修改发起的ip为客户端,目标地址为负载均衡服务器,返回给客户端。

缺点:

请求和响应的压力都在负载均衡服务器。负载均衡服务器,网卡的出口网络带宽会不够用。

数据链路层负载均衡

  1. 客户端请求到达负载均衡服务器,负载均衡服务器的网卡和应用服务器的网卡为一样,这是虚拟网卡。修改Mac地址,分发给应用服务器,达到负载均衡。

  2. 应用服务器处理完后,直接返回给客户端。

LVS

数据链路层负载均衡是张文冲,现任 滴滴的首席科学家发明的。

负载均衡算法

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

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

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

  • 最少连接:记录每个应用服务器正在处理的连接数(请求数),将新到的请求分发到最少连接的服务器上,应该说,这是最符合负载均衡定义的算法。

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

应用服务器集群的 Session 管理

应用服务器的高可用架构设计主要基于服务无状态这一特性,但是事实上,业务总是由状态的,在交易类的电子商务网站,需要有购物车记录用户的购买信息,用户每次国脉请求都是向购物车种增加商品;在社交类网站中,记录用户的当前登录状态、最新发布的消息以便及时将这些信息通知他的好友。Web应用中将这些状态信息称作会话(Session),单机情况下,Session可交给Web容器管理,在使用负载均衡的集群环境中,Session 管理主要有以下几种手段。

Session 复制

这种方案是已经淘汰的。每台服务器都同步session,http请求很重。做集群本来就是为了分担负载均衡,但是session复制又加重了服务器的压力。计算稍微大一点,就会被session拖垮了。

Session 绑定

相同的IP地址,总是到达相同的服务器。Session绑定,IP地址Hash值的作为Key去模服务器。

Session绑定是不好的,也已经被淘汰了。为什么?

业务的快速发展、快速迭代,7 x 24 小时运转,没法支持快速发布版本。发布版本的流程为,关闭应用服务器,发布新应用,重启服务器。如果关闭应用服务器,session就丢失了,导致用户处理失败,用户就丢失了。

利用 Cookie 记录 Session

缺点:每次请求响应,都要维护session,如果浏览器禁用cookie,那么就用不了了。

在Web的时代,这种方案还是比较流行的,生命力强很多。

Session 服务器

分布式数据库

MySQL 主从复制

主服务器修改表,更新表数据操作会记录到Binlog里面,Binlog会启动一个客户端线程,把更新的数据同步到从服务器的Relay Log里面。

更改字段的流程:

  • 增加字段的时候,数据库表结构要先加字段,应用服务器更新再上线。

  • 删除字段的时候,所有应用服务器先取出该字段,数据库表结构才能删掉该字段。

MySQL 一主多从复制

一主多从复制的优点

  • 分摊负载

  • 专机专用

  • 便于热备份和冷备分

  • 高可用

MySQL 主主复制

客户端线程更新数据,更新数据,追加到binlog,主服务器启动客户端线程,主服务器A从

MySQL 主主失效恢复

MySQL 主主失效的维护过程

MySQL 复制注意事项:

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

  • 主主复制/主从复制,只是增加了数据的读并发处理能力,没有增加写并发能力和存储能力。

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

MySQL支持的记录量级是千万级的,千万不能增加过亿的数据。

注意:以上信息如有侵权,请联系笔者删除。谢谢。

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

John(易筋)

关注

问渠那得清如许?为有源头活水来 2018.07.17 加入

前阿里巴巴资深无线开发,目前汇丰银行专家。客户端架构师,全栈工程师。擅长算法、数据结构、设计模式、iOS、Java、 Spring Boot、Spring Cloud、Docker

评论

发布
暂无评论
极客大学架构师训练营 系统架构 消息队列 数据库备份 第10课 听课总结