分布式原理

   分布式系统是一个硬件和软件系统分布在不同的网络计算机，批次之间仅仅通过消息传递进行通讯和协调的系统。在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息的交换。

为为什么会出现分布式应用？

为提高系统处理能力，我们首先想到的扩展方式就是升级系统配置，8核cpu升级为32核，

64核，内存64G升级为128G，256H，带宽上万兆，十万兆，这就叫垂直扩展，但这样的扩展将无法持续下去，原因如下

1.单机系统的处理能力最终会打到瓶颈

2.单机升级的边际成本将越来越大

当垂直扩展到达瓶颈或投入产出比超过预期，我们可以考虑通过增加服务器数量来提高并发能力，这种方式就是水平扩展。

分布式就是为了满足以下目标而设计的：

Transparency:透明性，即用户是不关心系统背后的分布式的，无论系统是分布式的还是单机的，对用户来说都应该是透明的，用户只需要关心系统可用的能力。这里的透明性就包括以下方面：

访问透明性：固定同意的访问接口和方式，不因为分布式系统内部的变动而改变系统的访问方式。

位置透明性：外部访问者不需要知道分布式系统具体的地址，系统节点的变动也不会影响其功能。

并发透明性：几个进程能并发的使用共享资源而不互相干扰。

复制透明性：使用资源的多个实力提升可靠性和性能，而用户和程序员无需知道副本的相关信息。

故障透明性：分布式系统内部部分节点的故障不影响系统的整体功能。

移动透明性：资源和客户能够再系统内移动儿不受影响。

性能透明性：负载变化时，系统能够被重新配置以提高性能

伸缩透明性：系统和应用能够进行扩展而不改变系统结构和应用算法

Openness：开放性，通用的协议和使用方式。

Scalability：可伸缩性，随着资源数量的增加和用户访问的增加，系统仍然能保持其有效性，该系统被称为可伸缩性。分布式系统应该在系统大小，系统管理方面都可扩展。

Performance: 性能，相对于单体应用，分布式系统应该用更加突出的性能。Reliability:

Reliabiity:可靠性，与单体系统相比，分布式系统应具有更好安全性，一致性和掩盖错误的能力。

分布式挑战

1.节点故障：

节点数量越多，出故障的概率就变高了。分布式系统需要保证故障发生的时候，系统仍然是可用的，这就需要系统能够感知所有节点服务状态，在节点发生故障的情况下将该节点负责的计算、存储任务转移到其他节点。

2.不可靠网络

节点间通过网络通信，我们都知道网络是不可靠的。可能网络问题包括：网络分割、延时、丢包、乱序。相比单机过程调用，网络通信最让人头疼的是超时已经双向通行的不确定性。出现超时状态时，网络通信发起方是无法确定当前请求是否被成功处理的。

在不可靠的网络和节点中，分布式系统依然要保证其可用，稳定，高效，这是一个系统最基本的要求。因此分布式系统的设计和架构充满了挑战。

分而治之

分布式就是充分利用更多的资源进行并运算和存储来提升系统的性能，这就是分而治之的原理

不同集群类型的分

sharding 同样是分，在不同领域的，甚至不同实现的系统中通常会有不同的说法。sharding通常是在数据存储系统中将不同数据分布到不同节点，数据分片。

比如在 MongoDB 中，当 MongoDB 存储海量的数据时，一台机器可能不足以存储数据，也可能不足以提供可接受的读写吞吐量。这时，我们就可以通过在多台机器上分割数据，使得数据库系统能存储和处理更多的数据。

比如在 Elasticsearch 中，每个索引有一个或多个分片，索引的数据被分配到各个分片上，相当于一桶水用了 N 个杯子装。分片有助于横向扩展，N 个分片会被尽可能平均地（rebalance）分配在不同的节点上。

partition的概念经常在Kafka中可以看到，在kafka中topic是一个逻辑概念，从分布式队列 的角度看，topic对使用者来说就是一个队列，topic在kafka的具体视线中，由分布在不同节点上的partition组成，每个partition就是根据分区算法拆分多个分区，在kafka中，同一个分区不能被同一group下的多个consumer消费，所以一个topic有多少partion在一定意义上就表示这个topoc具有多少并发处理能力。

在 Amazing 的分布式数据库DynamoDB中，一张表在底层实现中也被分区为不同的 partition。

load balance

负载均衡是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。

比如nginx的负载均衡，通过不同的负载均衡分配策略，将http请求分发到web应用的不同节点之上，从而提高应用的并发处理能力。

比如dubbo的客户端负载能力，可以将dubbo请求路由到具体的producer提供节点上，负载均衡是一个完善的rpc所应该具有的能力。

在Spring Cloud的体系中Robbin 组件可以通过Spring Cloud的各微服务之间的通信的负载均衡分配问题，依旧是将请求分发到集群中的不同节点上去。

分的策略

无论是分区还是分片，还是分区路由，其实都是一些通用的分区算法，一种可复制，一种不可复制。

可复制，这种策略根据一定算法分配计算和数据，在相同的条件下，无论什么时间点得出的结果相同，因此对于相同条件的请求和数据来说是可复制的，在不同时间点相同的请求和数据始终在统一节点上。

不可复制，这种策略使用全随机方式，即使在相同条件下，不同时间点得出的结果也不一致，因此也是不可还原的，如果只是为了可还原，通过元数据记录已经分配好的数据，之后需要还原时通过元数据就可以准确的得知数据所在位置了。

Dubbo 的负载均衡

Random LoadBalance 随机，可以按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance 轮询，按公约后的权重设置轮询比率。存在慢的提供者累积请求的问题，比如：第二胎机器慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有的请求都卡在第二台上了。

LeastActive LoadBalance 最少活跃调用数，相同活跃数的随机，活跃数指调用前后技术差，使慢的提供者收到更少请求，因为越慢的提供者的调用前后技术差会越大。

ConsistentHash LoadBalance

一致性Hash,相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不会引起剧烈变动。

Kafka 的分区分配策略

Kafka 中提供了多重分区分配算法（PartitionAssignor）的实现：

RangeAssignor

RangeAssignor 策略的原理是按照消费者总数和分区总数进行整除运算来获得一个跨度，然后将分区按照跨度进行平均分配，以保证分区尽可能均匀地分配给所有的消费者。对于每一个 Topic，RangeAssignor 策略会将消费组内所有订阅这个 Topic 的消费者按照名称的字典序排序，然后为每个消费者划分固定的分区范围，如果不够平均分配，那么字典序靠前的消费者会被多分配一个分区。

RoundRobinAssignor

RoundRobinAssignor 的分配策略是将消费组内订阅的所有 Topic 的分区及所有消费者进行排序后尽量均衡的分配（RangeAssignor 是针对单个 Topic 的分区进行排序分配的）。

StickyAssignor

从字面意义上看，Sticky 是“粘性的”，可以理解为分配结果是带“粘性的”——每一次分配变更相对上一次分配做最少的变动（上一次的结果是有粘性的），其主要是为了实现以下两个目标：

1. 分区的分配尽量的均衡

2. 每一次重分配的结果尽量与上一次分配结果保持一致 

Mysql 的主从架构

目前，大部分的主流关系型数据库都提供了主从热备功能，通过配置两台（或多台）数据库的主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。这既可以实现数据库的读写分离，从而改善数据库的负载压力，也可以提高数据高可用，多份数据备份降低了数据丢失的风险。

 

Elasticsearch 的副本机制

在 ES 中有主分片和副本分片的概念。副本分片的主要目的就是为了故障转移，如果持有主分片的节点挂掉了，一个副本分片就会晋升为主分片的角色从而对外提供查询服务。

CAP理论 

在理论计算机科学中，CAP定理（CAP theorem）,又被称作布鲁尔定理（Brewers themorem）,它指出对于一个分布式计算机系统来说，不可能同事满足分布式系统一致性、可用性和分区容错（即 CAP 中的"C"，"A"和"P"）

一致性 意味着所有客户端同时看到相同的数据，无论它们连接到哪个节点。要发生这种情况，每当将数据写入一个节点时，必须立即将数据转发或复制到系统中的所有其他节点，然后才能将写入视为成功。

可用性 任何客户端请求都能得到响应数据，不会出现响应错误。可用性是站在分布式系统的角度，对访问本系统的客户的另一种承诺 我一定会给您返回数据，不会给你返回错误，但不保证数据最新，强调的是不出错。

分区容错  分区即分布式系统中通讯中断，两个节点之间丢失或暂时延迟连接。分区容错意味着群集必须工作，尽管系统中节点之间存在通讯故障

     CA：完全严格的仲裁协议，例如2PC（两阶段提交协议，第一阶段投票，第二阶段事物提交）

• CP：不完全（多数）仲裁协议，例如 Paxos、Raft

• AP：使用冲突解决的协议，例如 Dynamo、Gossip

CA 和 CP 系统设计遵循的都是强一致性理论。不同的是 CA 系统不能容忍节点发生故障。CP 系统能够容忍 2f+1 个节点中有 f 个节点发生失败。

Base 理论

CAP理论表明，对于一个分布式系统而言，它是无法同事满足Consistency(强一致性)、Availability(可用性)和Partition tolerance(分区容忍性) 这三个条件的，最多只能满足其中两个。

在分布式环境中，我们会发现必须选择 P（分区容忍）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。也就是说分区容错性是分布式系统的一个最基本要求。

CAP 定理限制了我们三者无法同时满足，但我们可以尽量让 C、A、P 都满足，这就是 BASE 定理。

BASE 理论是 Basically Available（基本可用），Soft State（软状态）和 Eventually Consistent（最终一致性）三个短语的缩写。即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

基本可用 (Basically Available)

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

电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务，这就是损失部分可用性的体现。

软状态 ( Soft State)

什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。

软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

最终一致性 ( Eventual Consistency)

最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

BASE 理论面向的是大型高可用、可扩展的分布式系统。与传统 ACID 特性相反，不同于 ACID 的强一致性模型，BASE 提出通过牺牲强一致性来获得可用性，并允许数据段时间内的不一致，但是最终达到一致状态。

分布式是系统扩展的必然方向，分布式系统所遇到的问题是普遍，随着大量优秀的项目在分布式的道路上披荆斩棘，前人已经总结了大量丰富的理论。并且不同领域的分布式系统也层出不穷，我们既应该学习好这些好的理论知识，也应该去多看看不同分布式系统的实现，总结它们的共性，发现它们在不同领域独特的亮点权衡，更重要的，我们应该将所学用于日常项目的实践当中，也应该在实践中总结出更多的规律理论。