一、谈谈业务中使用分布式的场景
分布式主要是为了提供可扩展性以及高可用性，业务中使用分布式的场景主要有分布式存储以及分布式计算。
分布式存储中可以将数据分片到多个节点上，不仅可以提高性能（可扩展性），同时也可以使用多个节点对同一份数据进行备份（高可用性）。
至于分布式计算，就是将一个大的计算任务分解成小任务分配到多个节点上去执行，再汇总每个小任务的执行结果得到最终结果。MapReduce 是分布式计算最好的例子。
二、分布式事务
指事务的操作位于不同的节点上，需要保证事务的 AICD 特性。
产生原因
数据库分库分表
SOA 架构，比如一个电商网站将订单业务和库存业务分离出来放到不同的节点上。
应用场景
下单：减少库存、更新订单状态。库存和订单如果不在同一个数据库，就涉及分布式事务。
支付：买家账户扣款、卖家账户入账。买家和卖家账户信息如果不在同一个数据库，就涉及分布式事务。
解决方案
1. 两阶段提交协议
两阶段提交协议可以很好地解决分布式事务问题。它可以使用 XA 来实现，XA 包含两个部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如 Oracle、DB2 这些商业数据库都实现了 XA 接口；而事务管理器作为全局的协调者，负责各个本地资源的提交和回滚。
2. 消息中间件
为什么需要使用消息中间件
通过服务调用让其他系统感知事件发生
通过服务调用
通过消息中间件解耦服务调用
通过消息中间件解耦服务调用
消息中间件带来的好处
解耦:比如登录系统和日志系统它们之间通过消息中间件完成解开耦合，它们自己在后端异步得执行。
异步横向扩展:当我们登陆系统有很多用户登陆，然后这些消息全部都需要告诉积分系统去要增加积分。而增加积分这个处理过程比较麻烦，比较耗时；这个时候它就可以启用多台积分系统，然后同时去消费消息中间件里面的登陆消息，达到一个横向扩展的作用。
安全可靠:因为消息中间件会把我们的消息进行保存，直到我们的业务系统把这条消息消费为止。如果没有消费或者业务系统出现异常的情况下，它可以下一次正常之后继续消费这条消息。
顺序保证
介绍
消息中间件也可称作消息系统 (MQ)，它本质上是一个暂存转发消息的一个中间件。在分布式应用当中，我们可以把一个业务操作转换成一个消息，比如支付宝的余额转入余额宝操作，支付宝系统执行减少余额操作之后向消息系统发送一个消息，余额宝系统订阅这条消息然后进行增加余额宝操作。
消息处理模型
（一）点对点
点对点
（二）发布/订阅
发布/订阅
消息的可靠性
（一）发送端的可靠性
发送端完成操作后一定能将消息成功发送到消息系统。
实现方法：在本地数据建一张消息表，将消息数据与业务数据保存在同一数据库实例里，这样就可以利用本地数据库的事务机制。事务提交成功后，将消息表中的消息转移到消息中间件，若转移消息成功则删除消息表中的数据，否则继续重传。
（二）接收端的可靠性
接收端仅且能够从消息中间件成功消费一次消息。
实现方法：
保证接收端处理消息的业务逻辑具有幂等性：只要具有幂等性，那么消费多少次消息，最后处理的结果都是一样的。
保证消息具有唯一编号，并使用一张日志表来记录已经消费的消息编号。
三、负载均衡的算法与实现
负载均衡，就是将请求分发到不同服务器上去响应，让每个服务器的负载达到均衡的状态。
负载均衡算法
1. 轮询（Round Robin）
轮询算法把每个请求轮流发送到每个服务器上。下图中，一共有 6 个客户端产生了 6 个请求，这 6 个请求按 (1, 2, 3, 4, 5, 6) 的顺序发送。最后，(1, 3, 5) 的请求会被发送到服务器 1，(2, 4, 6) 的请求会被发送到服务器 2。
轮询（Round Robin）
该算法比较适合每个服务器的性能差不多的场景，如果有性能存在差异的情况下，那么性能较差的服务器可能无法承担多大的负载（下图的 Server 2）。
缺点
2. 加权轮询（Weighted Round Robbin）
加权轮询是在轮询的基础上，根据服务器的性能差异，为服务器赋予一定的权值。例如下图中，服务器 1 被赋予的权值为 5，服务器 2 被赋予的权值为 1，那么 (1, 2, 3, 4, 5) 请求会被发送到服务器 1，(6) 请求会被发送到服务器 2。
加权轮询（Weighted Round Robbin）
3. 最少连接（least Connections）
由于每个请求的连接时间不一样，使用轮询或者加权轮询算法的话，可能会让一台服务器当前连接数多大，而另一台服务器的连接多小，造成负载不均衡。例如下图中，(1, 3, 5) 请求会被发送到服务器 1，但是 (1, 3) 很快就断开连接，此时只有 (5) 请求连接服务器 1；(2, 4, 6) 请求被发送到服务器 2，只有 (2) 的连接断开。该系统继续运行时，服务器 2 会承担多大的负载。
image
最少连接算法就是将请求发送给当前最少连接数的服务器上。例如下图中，服务器 1 当前连接数最小，那么新到来的请求 6 就会被发送到服务器 1 上。
最少连接（least Connections）
4. 加权最小连接（Weighted Least Connection）
在最小连接的基础上，根据服务器的性能为每台服务器分配权重，根据权重计算出每台服务器能处理的连接数。
加权最小连接（Weighted Least Connection）
5. 随机算法（Random）
把请求随机发送到服务器上。和轮询算法类似，该算法比较适合服务器性能差不多的场景。
image
负载均衡实现
1. HTTP 重定向【协议层】
HTTP重定向负载均衡有一台重定向服务器，它也是一台普通的服务器，其唯一的功能就是根据用户的HTTP请求计算一台应用集群中服务器的地址，并将此地址写入HTTP重定向响应中返回给用户。
HTTP 重定向负载均衡服务器收到 HTTP 请求之后会返回服务器的地址，并将该地址写入 HTTP 重定向响应中返回给浏览器，浏览器收到后需要再次发送请求。
缺点：
重定向服务器很容易编程瓶颈
因为一次重定向返回的过程，也是一次标准HTTP请求，如果集群内有10台机器，那HTTP重定向服务器的流量将是应用服务器的10倍，如果有100台估计就要宕机了，所以伸缩性能受到了很大的限制。用户访问的延迟会增加
如果负载均衡器宕机，就无法访问该站点
使用302响应码重定向，不利于网站的SEO
HTTP 重定向
2. DNS 重定向【协议层】
DNS域名解析负载均衡的优点是将负载均衡的工作转交给DNS，省掉了网站管理维护负载均衡服务器的麻烦，同时还可以使用智能DNS可以基于地理位置或者ISP来做域名解析，用户将会得到距离最近或者速度最快的一个服务器地址，这样可以加快用户的访问速度，改善性能。
使用 DNS 作为负载均衡器，根据负载情况返回不同服务器的 IP 地址。大型网站基本使用了这种方式做为第一级负载均衡手段，然后在内部使用其它方式做第二级负载均衡。
缺点：
DNS 查找表可能会被客户端缓存起来，那么之后的所有请求都会被重定向到同一个服务器
DNS是多级解析，每一级都会缓存DNS记录，如果某个服务器变动了，DNS记录更新的时间将会很长
DNS 重定向
3. 修改 MAC 地址【链路层】
目前链路层的负载均衡是特别常见的一种手段，典型的产品有LVS（Linux Virtual Server）。使用 LVS（Linux Virtual Server）这种链路层负载均衡器，根据负载情况修改请求的 MAC 地址。
修改 MAC 地址
负载均衡服务器的IP和它所管理的web 服务群的虚拟IP一致
负载均衡数据分发过程中不修改访问地址的IP地址，而是修改Mac地址
通过这两点达到不修改数据包的原地址和目标地址就可以进行正常的访问。
优点：
不需要负载均衡服务器进行地址的转换。
数据响应时不需要经过负载均衡服务器。
缺点：
负载均衡服务器的网卡带宽要求较高。
4. 修改 IP 地址【网络层】
在网络层修改请求的目的 IP 地址。
image
用户访问请求到达负载均衡服务器，负载均衡服务器在操作系统内核进程获取网络数据包，根据算法得到一台真实服务器地址，然后将用户请求的目标地址修改成该真实服务器地址，数据处理完后返回给负载均衡服务器，负载均衡服务器收到响应后将自身的地址修改成原用户访问地址后再讲数据返回回去。类似于反向服务器负载均衡。
优点：在响应请求时速度较反向服务器负载均衡要快。
缺点：当请求数据较大（大型视频或文件）时，速度较慢。
5. 反向代理【协议层】
反向代理
5.1 什么是反向代理？
在介绍 反向代理”之前，首先要介绍一下 正向代理的概念。
正向代理
在 NAT 技术 (Network Address Translation) 出现之前，所有主机无法直接与外网相连，要想上网，需要连接到一台能够访问外网的 Web 服务器，再通过这台服务器访问外网。而这台 Web 服务器就叫做 “正向代理服务器”。
现在的 “翻墙” 技术也是如何，我们把请求发给一台可以连接外面世界的 Web 服务器，由它转发我们的请求，再将结果返回给我们。这台 Web 服务器就是 “正向代理服务器”。
综上所述：正向代理服务器是客户端和目的服务器之间的一个中介，客户端通过正向代理服务器访问客户端原本无法访问的目标服务器。
反向代理
客户端向一个服务器 A 提交请求后，服务器 A 偷偷地去服务器 B 上获取资源，并返回给客户端。客户端天真地以为数据是服务器 A 给他的。
在这过程中，服务器 A 称为 “反向代理服务器”，服务器 B 称为反向代理服务器的 “后端服务器”。
正向代理与反向代理的区别
两者最直观的区别是在用户的角度。
正向代理：发生在客户端，是由用户主动发起的。比如翻墙，客户端通过主动访问代理服务器，让代理服务器获得需要的外网数据，然后转发回客户端。
反向代理：发生在服务器端，用户不知道代理的存在。用户向服务器发送请求后，服务器在用户不知情的情况下去其他服务器上获取资源并返回给用户。
5.2 什么是反向代理服务器
反向代理服务器用于存储静态数据和缓存数据，它处于 Web 服务器之前。当用户发起请求时，请求首先被反向代理服务器截获，若请求的是静态数据或缓存数据，则反向代理服务器直接将数据返回。
若请求的是动态数据，且缓存中不存在，则反向代理服务器将请求转发给后端的 Web 服务器，在获取后端服务器的数据后再返回给用户。
5.3 反向代理服务器有何作用？
反向代理服务器能够分担后端服务器的压力。在请求数很高的情况下，即使服务器使用了缓存，但仍然无法应对巨大的并发数，因此需要反向代理服务器的帮忙。
反向代理服务器收到请求后，如果请求的是缓存数据或静态数据，则直接返回给用户，而无需再劳驾后端服务器了，从而缓解后端服务器的压力。
5.4 什么是反向代理负载均衡？
反向代理服务器是一个位于实际服务器之前的服务器，所有向我们网站发来的请求都首先要经过反向代理服务器，服务器根据用户的请求要么直接将结果返回给用户，要么将请求交给后端服务器处理，再返回给用户。
之前我们介绍了用反向代理服务器实现静态页面和常用的动态页面的缓存。接下来我们介绍反向代理服务器更常用的功能——实现负载均衡。
我们知道，所有发送给我们网站的请求都首先经过反向代理服务器。那么，反向代理服务器就可以充当服务器集群的调度者，它可以根据当前后端服务器的负载情况，将请求转发给一台合适的服务器，并将处理结果返回给用户。
5.5 优点
隐藏后端服务器
与 HTTP 重定向相比，反向代理能够隐藏后端服务器，所有浏览器都不会与后端服务器直接交互，从而能够确保调度者的控制权，提升集群的整体性能。
故障转移
与 DNS 负载均衡相比，反向代理能够更快速地移除故障结点。当监控程序发现某一后端服务器出现故障时，能够及时通知反向代理服务器，并立即将其删除。
合理分配任务
HTTP 重定向和 DNS 负载均衡都无法实现真正意义上的负载均衡，也就是调度服务器无法根据后端服务器的实际负载情况分配任务。但反向代理服务器支持手动设定每台后端服务器的权重。
我们可以根据服务器的配置设置不同的权重，权重的不同会导致被调度者选中的概率的不同。
作者：stoneyang94
链接：https://www.jianshu.com/p/94390e8a0d4a
随时随地看视频
