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

说明

讲师：李智慧

消息队列与异步架构

同步调用

发邮件时序图：同步调用，每个调用都会阻塞等待。
同步调用：线程前后执行，都要一步一步同步等待结果。

多个耗时操作同步调用

异步调用

异步调用：写入消息队列里面，就直接返回。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支持的记录量级是千万级的，千万不能增加过亿的数据。

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