分布式整理

CAP

分布式存储系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容忍性（P：Partition tolerance），最多只能同时满足其中两项。

在设计分布式系统时，需要根据实际需求弱化某一要求。因此就有了下图中的三种设计：CA、CP 和 AP。

需要注意的是，分区容忍性必不可少，因为需要总是假设网络是不可靠的，并且系统需要能够自动容错，因此实际上设计分布式存储系统需要在一致性和可用性之间做权衡。上一节介绍的强同步协议和异步复制协议就是在一致性和可用性做权衡得到的结果。

BASE

BASE 是 Basically Available（基本可用）、Soft State（软状态）和 Eventually Consistent（最终一致性）三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的结果，是基于 CAP 定理逐步演化而来的。BASE 理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

1. 基本可用

指分布式系统在出现故障的时候，保证核心可用，允许损失部分可用性。

例如，电商在做促销时，服务层可能只提供降级服务，部分用户可能会被引导到降级页面上。

2. 软状态

指允许系统存在中间状态，而该中间状态不会影响系统整体可用性，即不同节点的数据副本之间进行同步的过程允许存在延时。

3. 最终一致性

一致性模型包含以下三种：

• 强一致性：新数据写入之后，在任何数据副本上都能读取到最新值；
• 弱一致性：新数据写入之后，不能保证在数据副本上能读取到最新值；
• 最终一致性：新数据写入之后，只能保证过了一个时间窗口后才能在数据副本上读取到最新值；

强一致性通常运用在需要满足 ACID 的传统数据库系统上，而最终一致性通常运用在大型分布式系统中。应该注意的是，上面介绍的强同步复制协议和异步复制协议都不能保证强一致性，因为它们是分布式系统的复制协议。这两种复制协议如果要满足最终一致性，还需要多加一些控制。

在实际的分布式场景中，不同业务单元和组件对一致性的要求是不s同的，因此 ACID 和 BASE 往往会结合在一起使用。

分布式事务

指事务的操作位于不同的节点上，需要保证事务的 AICD 特性。例如在下单场景下，库存和订单如果不在同一个节点上，就需要涉及分布式事务。

两阶段提交协议

Two-phase Commit（2PC）。

两类节点：协调者（Coordinator）和参与者（Participants），协调者只有一个，参与者可以有多个。

1. 运行过程

① 准备阶段：协调者询问参与者事务是否执行成功；

② 提交阶段：如果事务在每个参与者上都执行成功，协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。

需要注意的是，在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。

2. 分析

2PC 可以保证强一致性，但是因为在准备阶段协调者需要等待所有参与者的结果才能进入提交阶段，因此可用性差。

3. 存在的问题

• 参与者发生故障。解决方案：可以给事务设置一个超时时间，如果某个参与者一直不响应，那么认为事务执行失败。
• 协调者发生故障。解决方案：将操作日志同步到备用协调者，让备用协调者接替后续工作。

4. XA 协议

XA 协议是多数数据库的 2PC 协议的实现，包含了事务管理器和本地资源管理器。

本地消息

1. 原理

本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性。

1. 在分布式事务操作的一方，它完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。
2. 之后将本地消息表中的消息转发到 Kafka 等消息队列（MQ）中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。
3. 在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。

2. 分析

本地消息表利用了本地事务来实现分布式事务，并且使用了消息队列来保证最终一致性。

分布式 Session

一、Session Replication 方式管理 (即session复制)

        简介：将一台机器上的Session数据广播复制到集群中其余机器上

        使用场景：机器较少，网络流量较小

        优点：实现简单、配置较少、当网络中有机器Down掉时不影响用户访问

        缺点：广播式复制到其余机器有一定廷时，带来一定网络开销

二、Session Sticky 方式管理

        简介：即粘性Session、当用户访问集群中某台机器后，强制指定后续所有请求均落到此机器上

        使用场景：机器数适中、对稳定性要求不是非常苛刻

        优点：实现简单、配置方便、没有额外网络开销

        缺点：网络中有机器Down掉时、用户Session会丢失、容易造成单点故障

三、缓存集中式管理

       简介：将Session存入分布式缓存集群中的某台机器上，当用户访问不同节点时先从缓存中拿Session信息

       使用场景：集群中机器数多、网络环境复杂

       优点：可靠性好

       缺点：实现复杂、稳定性依赖于缓存的稳定性、Session信息放入缓存时要有合理的策略写入

四、数据库持久化

负载均衡

load-balance 算法

1. 轮询（Round Robin）

轮询算法把每个请求轮流发送到每个服务器上。下图中，一共有 6 个客户端产生了 6 个请求，这 6 个请求按 (1, 2, 3, 4, 5, 6) 的顺序发送。最后，(1, 3, 5) 的请求会被发送到服务器 1，(2, 4, 6) 的请求会被发送到服务器 2。

该算法比较适合每个服务器的性能差不多的场景，如果有性能存在差异的情况下，那么性能较差的服务器可能无法承担过大的负载（下图的 Server 2）。

2. 加权轮询（Weighted Round Robbin）

加权轮询是在轮询的基础上，根据服务器的性能差异，为服务器赋予一定的权值。例如下图中，服务器 1 被赋予的权值为 5，服务器 2 被赋予的权值为 1，那么 (1, 2, 3, 4, 5) 请求会被发送到服务器 1，(6) 请求会被发送到服务器 2。

3. 最少连接（least Connections）

由于每个请求的连接时间不一样，使用轮询或者加权轮询算法的话，可能会让一台服务器当前连接数过大，而另一台服务器的连接过小，造成负载不均衡。例如下图中，(1, 3, 5) 请求会被发送到服务器 1，但是 (1, 3) 很快就断开连接，此时只有 (5) 请求连接服务器 1；(2, 4, 6) 请求被发送到服务器 2，只有 (2) 的连接断开。该系统继续运行时，服务器 2 会承担过大的负载。

4. 加权最少连接（Weighted Least Connection）

在最少连接的基础上，根据服务器的性能为每台服务器分配权重，再根据权重计算出每台服务器能处理的连接数。

5. 随机算法（Random）

把请求随机发送到服务器上。和轮询算法类似，该算法比较适合服务器性能差不多的场景。

6. 源地址哈希法 (IP Hash)

源地址哈希通过对客户端 IP 哈希计算得到的一个数值，用该数值对服务器数量进行取模运算，取模结果便是目标服务器的序号。

• 优点：保证同一 IP 的客户端都会被 hash 到同一台服务器上。
• 缺点：不利于集群扩展，后台服务器数量变更都会影响 hash 结果。可以采用一致性 Hash 改进。

实现负载均衡的方式

1. HTTP 重定向（最少见，速度太慢）

HTTP 重定向负载均衡服务器收到 HTTP 请求之后会返回服务器的地址，并将该地址写入 HTTP 重定向响应中返回给浏览器，浏览器收到后需要再次发送请求。

2. DNS 重定向

使用 DNS 作为负载均衡器，根据负载情况返回不同服务器的 IP 地址。大型网站基本使用了这种方式做为第一级负载均衡手段，然后在内部使用其它方式做第二级负载均衡。

 3. 修改 MAC 地址

使用 LVS（Linux Virtual Server）这种链路层负载均衡器，根据负载情况修改请求的 MAC 地址。

4、IP负载均衡(SNAT)

      这里的关键在于真实WEB服务器相应数据包如何返回给负载均衡服务器，一种是负载均衡服务器在修改目的IP地址的同时修改源地址，将数据包源地址改为自身的IP，即源地址转换（SNAT），另一种方案是将负载均衡服务器同时作为真实物理服务器的网关服务器，这样所有的数据都会到达负载均衡服务器。

      IP负载均衡在内核进程完成数据分发，较反向代理均衡有更好的处理性能。但由于所有请求响应的数据包都需要经过负载均衡服务器，因此负载均衡的网卡带宽成为系统的瓶颈。

5、反向代理负载均衡(nginx)

传统代理服务器位于浏览器一端，代理浏览器将HTTP请求发送到互联网上。
而反向代理服务器则位于网站机房一侧，代理网站web服务器接收http请求。

反向代理的作用是保护网站安全，所有互联网的请求都必须经过代理服务器，相当于在web服务器和可能的网络攻击之间建立了一个屏障。

除此之外，代理服务器也可以配置缓存加速web请求。当用户第一次访问静态内容的时候，静态内存就被缓存在反向代理服务器上，这样当其他用户访问该静态内容时，就可以直接从反向代理服务器返回，加速web请求响应速度，减轻web服务器负载压力。

另外，反向代理服务器也可以实现负载均衡的功能