分布式系统简介

什么是分布式系统

分布式系统（distributed  system）具备高度的 内聚性 和 透明性。

    内聚性：每个节点高度自治，有本地的数据库管理系统；

    透明性：每个数据库分布节点对用户来讲是透明的，用户是感受不到"分布"的，即用户不须要知道关系是否分割、有无副本、数据位于哪一个节点、事物在哪一个站点上执行等；

CAP原理

• c：一致性（Consistency）

在分布式系统中的全部数据备份，在同一时刻是否一样的值；

• a：可用性（Availability）

在集群中一部分节点故障后，集群总体是否还能响应客户端的读写请求；

• p： 分区 容忍性（Partition Rolerance）

分区至关与对通讯的时限要求，消息体若是不能在时限内达成数据一致性，意味着发生了分区的状况。

所以分区容忍性是基本要求，不然就失去了价值。所以分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数的web应用，并不须要强一致性，一般作法是以强一致性为代价换取高可用，这也是多数分布式数据库产品的方向。

这里的牺牲一致性，指的是再也不要求关系型数据库中的强一致性，只要能达到最终一致性便可，这个时间窗口对用户来讲是透明的，用户是感知不到的。一般的作法，是通过多份异步复制来实现系统的高可用和数据的最终一致性，时间窗口取决于数据复制到一致状态的时间。

关于最终一致性

    一致性问题是由于出现了并发的读操做或者写操做。对于客户端，多进程并发访问时，更新过的数据在不一样进程中如何获取的不一样策略，决定了不一样的一致性。

    强一致性：对于关系型数据库，要求更新过的数据能被后续的访问都能看到；

    弱一致性：若是容忍后续的部分或者所有访问不到，这就是弱一致性；

    最终一致性：若是通过一段时间以后，要求可以访问到更新后的数据，就是最终一致性；

从数据的同步看强弱一致性

    对于服务器而言，如何尽快将更新后的数据分布到整个系统，下降最终一致性的时间窗口，对分布式系统来讲是十分重要的。

    咱们假设，如今有一个分布式系统，数据保存了 N 份，更新数据须要保证写完成的节点数为 W ，读取数据时须要读取的节点数为 R ：

    若是 W＋R > N, 说明读写节点重复，则是强一致性，如一主一备同步复制的关系型数据库；

    若是 W＋R <= N, 则是弱一致性，好比一主一备异步复制的数据库，读取备库，可能没法读取主库已经更新过的数据。

    对于分布式数据库而言，为了保证高可用，通常设置 N >= 3。

分布式系统架构思路

两种思路

    1. 如今有一台服务器，一台服务器能够处理 100w/s 的请求，随着业务增加，据估算，访问量最高会达到 200w/s ，若是不进行处理，服务器会拒绝访问，甚至会 出现宕机。最简单的方案，就是再增长一台机器（在实际环境中，增长机器来解决问题是经常使用的一种解决方案），每台机器承担一半的请求，若是访问量继续增长的话，能够继续经过增长机器来解决问题。这就是水平扩展。这里暂时不讨论如何进行负载的均衡；

    2. 如今有一个应用对外提供项服务，每项服务都是一个请求，当前服务器能够承担 100w/s 的请求，目前统计， A 服务 40w/s ， B 服务 40w/s。业务一样扩大，服务 A 和服务 B 的请求都增长了一倍，有须要进行扩展。使用两台机器进行平分，每台机器承担服务 A 和服务 B 各一半，平分的话太复杂，不如一台机器只负责服务 A， 亮一台机器只负责业务 B，这种方式叫作垂直扩展。

    简单对水扩展和垂直扩展进行总结，能够发现，按照业务进行拆分，便是垂直扩展；按请求进行拆分，即水平扩展。

负载均衡

负载均衡要作的任务，就是肯定客户端的请求，应该发往分布式系统中的哪一台服务器上，一般的作法，就是经过一台中间服务器，来实现请求的分配。

常见的负载均衡策略：

1. FastDFS 分布式系统：client 向 tracker 询问一台能够进行文件下载的 storage ，tracker 返回一台可用的 storage，client 直接和 storage 进行通讯完成文件下载；

这里的 tracker 就是负载均衡服务器；

2. 分布式RPC中间件 Hedwig：client 向 zookeeper询问哪台服务器能够执行请求；zookeeper 返回一台可用的 server；client 直接和 service 完成通讯。

zookeeper 是分布式系统中一个负载均衡框架，Google 的 chubby 的一个开源实现，是 Hadoop 和 Hbase 的重要组件

3. nginx也是一个负载均衡服务器，面向的是分布式web服务器

负载均衡调度算法

1. 轮询

    使用这种方式，全部标记进入虚拟服务的服务器应该有相近的资源容量以及负载形同的应用程序。

2. 加权轮循(Weighted Round Robin)

    解决了轮询的缺点，提早为每台服务器根据资源及能力大小分配权重，传入的请求按顺序，根据权重，顺序分配给集群中的服务器。

3. 最少链接数

    上面两种方式，都不可以肯定系统不能识别在给定的时间里保持了多少链接。因为不一样链接处理的时间不一样，可能发生服务器 A 上处理的链接少于 B，可是A已经超载，由于A上用户打开链接持续的时间更长。

    这种潜在的问题，能够经过“最少链接数”算法来避免，客户端的请求是根据每台机器当前打开的链接数来分配的，即活跃链接数最少的服务器会自动接收下一个传入的请求。

与简单轮询同样，每台服务器也须要有相近的资源容量以及负载形同的应用程序；须要注意的是，在流量率低的配置环境中，个服务器的流量并不相同，会有限考虑第一台服务器。

4. 加权最少链接

    若是服务器资源容量各不相同，那么“加权最少链接”更为合适。这种分配方式结合了链接和权重二者的优点，大多数状况下，这是一种至关公平的算法。

一样，这种方式须要和最少链接数注意相同的问题。

5. 最少链接数慢启动时间

    对于方式 3 和方式 4 来讲，当集群中新增一个节点后，能够为其配置一个时间段，这个段时间内链接数是有限制的，并且是缓慢增长的，这为服务器提供了一个“过分时间”。

6. 源 IP 哈希

    经过生成源 IP 的哈希值，并经过这个哈希值来找到正确的真实服务器，意味着对于同一主机的请求，对应的服务器老是相同的，可是这种方式会致使服务器负载不均衡。