分布式系统 概念 高可用 高并发 学习笔记

分布式系统 概念 高可用 高并发 学习笔记

0. 分布式系统基本概念

0.1 背景

分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。

首先需要明确的是，只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候，且硬件的提升（加内存、加磁盘、使用更好的CPU）高昂到得不偿失的时候，应用程序也不能进一步优化的时候，我们才需要考虑分布式系统。因为，分布式系统要解决的问题本身就是和单机系统一样的，而由于分布式系统多节点、通过网络通信的拓扑结构，会引入很多单机系统没有的问题，为了解决这些问题又会引入更多的机制、协议，带来更多的问题。

那么分布式系统怎么将任务分发到这些计算机节点呢，很简单的思想，分而治之，即分片（partition）。对于计算，那么就是对计算任务进行切换，每个节点算一些，最终汇总就行了，这就是MapReduce的思想；对于存储，更好理解一下，每个节点存一部分数据就行了。当数据规模变大的时候，Partition是唯一的选择，同时也会带来一些好处：

1. 提升性能和并发，操作被分发到不同的分片，相互独立
2. 提升系统的可用性，即使部分分片不能用，其他分片不会受到影响

理想的情况下，有分片就行了，但事实的情况却不大理想。原因在于，分布式系统中有大量的节点，且通过网络通信。单个节点的故障（进程crash、断电、磁盘损坏）是个小概率事件，但整个系统的故障率会随节点的增加而指数级增加，网络通信也可能出现断网、高延迟的情况。在这种一定会出现的“异常”情况下，分布式系统还是需要继续稳定的对外提供服务，即需要较强的容错性。最简单的办法，就是冗余或者复制集（Replication），即多个节点负责同一个任务，最为常见的就是分布式存储中，多个节点复杂存储同一份数据，以此增强可用性与可靠性。同时，Replication也会带来性能的提升，比如数据的locality可以减少用户的等待时间。

0.2 挑战

分布式系统需要大量机器协作，面临诸多的挑战：

　　第一，异构的机器与网络：

　　　　分布式系统中的机器，配置不一样，其上运行的服务也可能由不同的语言、架构实现，因此处理能力也不一样；节点间通过网络连接，而不同网络运营商提供的网络的带宽、延时、丢包率又不一样。怎么保证大家齐头并进，共同完成目标，这四个不小的挑战。

　　第二，普遍的节点故障：

　　　　虽然单个节点的故障概率较低，但节点数目达到一定规模，出故障的概率就变高了。分布式系统需要保证故障发生的时候，系统仍然是可用的，这就需要监控节点的状态，在节点故障的情况下将该节点负责的计算、存储任务转移到其他节点

　　第三，不可靠的网络：

　　　　节点间通过网络通信，而网络是不可靠的。可能的网络问题包括：网络分割、延时、丢包、乱序。

　　　　相比单机过程调用，网络通信最让人头疼的是超时：节点A向节点B发出请求，在约定的时间内没有收到节点B的响应，那么B是否处理了请求，这个是不确定的，这个不确定会带来诸多问题，最简单的，是否要重试请求，节点B会不会多次处理同一个请求。

0.3 特性与衡量标准

• 透明性：使用分布式系统的用户并不关心系统是怎么实现的，也不关心读到的数据来自哪个节点，对用户而言，分布式系统的最高境界是用户根本感知不到这是一个分布式系统，在《Distributed Systems Principles and Paradigms》一书中，作者是这么说的：

A distributed system is a collection of independent computers that appears to its users as a single coherent system.　　

• 可扩展性：分布式系统的根本目标就是为了处理单个计算机无法处理的任务，当任务增加的时候，分布式系统的处理能力需要随之增加。简单来说，要比较方便的通过增加机器来应对数据量的增长，同时，当任务规模缩减的时候，可以撤掉一些多余的机器，达到动态伸缩的效果
• 可用性与可靠性：一般来说，分布式系统是需要长时间甚至7*24小时提供服务的。可用性是指系统在各种情况对外提供服务的能力，简单来说，可以通过不可用时间与正常服务时间的必知来衡量；而可靠性而是指计算结果正确、存储的数据不丢失。
• 高性能：不管是单机还是分布式系统，大家都非常关注性能。不同的系统对性能的衡量指标是不同的，最常见的：高并发，单位时间内处理的任务越多越好；低延迟：每个任务的平均时间越少越好。这个其实跟操作系统CPU的调度策略很像
• 一致性：分布式系统为了提高可用性可靠性，一般会引入冗余（复制集）。那么如何保证这些节点上的状态一致，这就是分布式系统不得不面对的一致性问题。一致性有很多等级，一致性越强，对用户越友好，但会制约系统的可用性；一致性等级越低，用户就需要兼容数据不一致的情况，但系统的可用性、并发性很高很多。

1. CAP定理与BASE理论

说到分布式系统的特性，这里有个著名的定理可以顺便了解一下。

1.1 CAP 定理

在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer's theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

• 一致性（Consistence） :所有节点访问同一份最新的数据副本
• 可用性（Availability）:每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据
• 分区容错性（Partition tolerance） : 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

CAP仅适用于原子读写的NOSQL场景中，并不适合数据库系统。现在的分布式系统具有更多特性比如扩展性、可用性等等，在进行系统设计和开发时，我们不应该仅仅局限在CAP问题上。

注意：不是所谓的3选2（不要被网上大多数文章误导了）:

大部分人解释这一定律时，常常简单的表述为：“一致性、可用性、分区容忍性三者你只能同时达到其中两个，不可能同时达到”。实际上这是一个非常具有误导性质的说法，而且在CAP理论诞生12年之后，CAP之父也在2012年重写了之前的论文。

当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能2选1。也就是说当网络分区之后P是前提，决定了P之后才有C和A的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。

1.2 BASE 理论

BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，它大大降低了我们对系统的要求。

BASE理论的核心思想： 即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

BASE理论三要素：

1. 基本可用： 基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。 比如： ①响应时间上的损失:正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒；②系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面；
2. 软状态： 软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时；
3. 最终一致性： 最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

2. 高可用

基本概念

高可用描述的是一个系统在大部分时间都是可用的，可以为我们提供服务的。高可用代表系统即使在发生硬件故障或者系统升级的时候，服务仍然是可用的。

一般情况下，我们使用多少个 9 来评判一个系统的可用性，比如 99.9999% 就是代表该系统在所有的运行时间中只有 0.0001% 的时间是不可用的，这样的系统就是非常非常高可用的了！当然，也会有系统如果可用性不太好的话，可能连 9 都上不了。

img

除此之外，系统的可用性还可以用某功能的失败次数与总的请求次数之比来衡量，比如对网站请求 1000 次，其中有 10 次请求失败，那么可用性就是 99%。

为什么分布式系统中必须要考虑可用性呢，这是因为分布式系统中故障的概率很高。分布式系统由大量异构的节点和网络组成，节点可能会crash、断电、磁盘损坏，网络可能丢包、延迟、网络分割。系统的规模放大了出故障的概率，因此分布式系统中，故障是常态。那么分布式系统的其中一个设计目标就是容错，在部分故障的情况下仍然对外提供服务，这就是可用性。

2.2 高可用策略

冗余是提高可用性、可靠性的法宝。

冗余就是说多个节点负责相同的任务，在需要状态维护的场景，比如分布式存储中使用非常广泛。在分布式计算，如MapReduce中，当一个worker运行异常缓慢时，master会将这个worker上的任务重新调度到其它worker，以提高系统的吞吐，这也算一种冗余。但存储的冗余相比计算而言要复杂许多，因此主要考虑存储的冗余。

维护同一份数据的多个节点称之为多个副本。我们考虑一个问题，当向这个副本集写入数据的时候，怎么保证并发情况下数据的一致性，是否有一个节点有决定更新的顺序，这就是中心化、去中心话副本协议的区别。

• 中心化与去中心化

中心化就是有一个主节点（primary master）负责调度数据的更新，其优点是协议简单，将并发操作转变为顺序操作，缺点是primar可能成为瓶颈，且在primary故障的时候重新选举会有一段时间的不可用。

去中心化就是所有节点地位平等，都能够发起数据的更新，优点是高可用，缺点是协议复杂，要保证一致性很难。

提到去中心化，比较有名的是dynamo，cassandra，使用了quorum、vector clock等算法来尽量保证去中心化环境下的一致性。

• 节点更新策略

primary节点到secondary节点的数据时同步还是异步，即客户端是否需要等待数据落地到副本集中的所有节点。

同步的优点在于强一致性，但是可用性和性能（响应延迟）比较差；异步则相反。

• 数据流向

即数据是如何从Primary节点到secondary节点的，有链式和主从模式。

链式的优点时充分利用网络带宽，减轻primary压力，但缺点是写入延迟会大一些。GFS，MongoDB（默认情况下）都是链式。

• 部分节点写入异常

理论上，副本集中的多个节点的数据应该保持一致，因此多个数据的写入理论上应该是一个事务：要么都发生，要么都不发生。但是分布式事务（如2pc）是一个复杂的、低效的过程，因此副本集的更新一般都是best effort 1pc，如果失败，则重试，或者告诉应用自行处理。

• primary的选举

在中心化副本协议中，primary节点是如何选举出来的，当primary节点挂掉之后，又是如何选择出新的primary节点呢，有两种方式：自治系统，依赖其他组件的系统。（ps，这两个名字是我杜撰的 。。。）

所谓的自治系统，就是节点内部自行投票选择，比如mongodb，tfs，zookeeper

依赖其他组件的系统，是指primary由副本集之后的组件来任命，比如GFS中的primary由master（GFS的元数据服务器）任命，hdfs的元数据namenode由zookeeper心跳选出。

• secondary是否对外提供服务（读服务）

中心化复制集中，secondary是否对外提供读服务，取决于系统对一致性的要求。

比如前面介绍到节点更新策略时，可能是异步的，那么secondary上的数据相比primary会有一定延迟，从secondary上读数据的话无法满足强一致性要求。

比如元数据，需要强一致性保证，所以一般都只会从primary读数据。而且，一般称主节点为active（master），从节点为standby（slave）。在这种情况下，是通过冗余 加上 快速的failover来保证可用性。

2.3 哪些情况会导致系统不可用？

1. 黑客攻击；
2. 硬件故障，比如服务器坏掉。
3. 并发量/用户请求量激增导致整个服务宕掉或者部分服务不可用。
4. 代码中的坏味道导致内存泄漏或者其他问题导致程序挂掉。
5. 网站架构某个重要的角色比如 Nginx 或者数据库突然不可用。
6. 自然灾害或者人为破坏。

2.4 提高系统可用性的方法

1. 注重代码质量，测试严格把关

代码质量有问题比如比较常见的内存泄漏、循环依赖都是对系统可用性极大的损害。

1. 使用集群，减少单点故障
2. 限流

流量控制（flow control），其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。

1. 超时和重试机制设置

一旦用户请求超过某个时间的得不到响应，就抛出异常。这个是非常重要的，很多线上系统故障都是因为没有进行超时设置或者超时设置的方式不对导致的。我们在读取第三方服务的时候，尤其适合设置超时和重试机制。一般我们使用一些 RPC 框架的时候，这些框架都自带的超时重试的配置。如果不进行超时设置可能会导致请求响应速度慢，甚至导致请求堆积进而让系统无法在处理请求。重试的次数一般设为 3 次，再多次的重试没有好处，反而会加重服务器压力（部分场景使用失败重试机制会不太适合）。

1. 熔断机制

超时和重试机制设置之外，熔断机制也是很重要的。 熔断机制说的是系统自动收集所依赖服务的资源使用情况和性能指标，当所依赖的服务恶化或者调用失败次数达到某个阈值的时候就迅速失败，让当前系统立即切换依赖其他备用服务。 比较常用的是流量控制和熔断降级框架是 Netflix 的 Hystrix 和 alibaba 的 Sentinel。

1. 异步调用

异步调用的话我们不需要关心最后的结果，这样我们就可以用户请求完成之后就立即返回结果，具体处理我们可以后续再做，秒杀场景用这个还是蛮多的。但是，使用异步之后我们可能需要 适当修改业务流程进行配合，比如用户在提交订单之后，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完该订单之后，甚至出库后，再通过电子邮件或短信通知用户订单成功。除了可以在程序中实现异步之外，我们常常还使用消息队列，消息队列可以通过异步处理提高系统性能（削峰、减少响应所需时间）并且可以降低系统耦合性。

1. 使用缓存

如果我们的系统属于并发量比较高的话，如果我们单纯使用数据库的话，当大量请求直接落到数据库可能数据库就会直接挂掉。使用缓存缓存热点数据，因为缓存存储在内存中，所以速度相当地快！

1. 其他
   1. 核心应用和服务优先使用更好的硬件
   2. 监控系统资源使用情况增加报警设置。
   3. 注意备份，必要时候回滚。
   4. 灰度发布： 将服务器集群分成若干部分，每天只发布一部分机器，观察运行稳定没有故障，第二天继续发布一部分机器，持续几天才把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可
   5. 定期检查/更换硬件： 如果不是购买的云服务的话，定期还是需要对硬件进行一波检查的，对于一些需要更换或者升级的硬件，要及时更换或者升级。

3. 高性能 / 高并发

1. 提高硬件能力、增加系统服务器。（当服务器增加到某个程度的时候系统所能提供的并发访问量几乎不变，所以不能根本解决问题）
2. 使用缓存（本地缓存：本地可以使用JDK自带的 Map、Guava Cache.分布式缓存：Redis、Memcache.本地缓存不适用于提高系统并发量，一般是用处用在程序中。比如Spring是如何实现单例的呢？大家如果看过源码的话，应该知道，S把已经初始过的变量放在一个Map中，下次再要使用这个变量的时候，先判断Map中有没有，这也就是系统中常见的单例模式的实现。）
3. 消息队列 （解耦+削峰+异步）
4. 采用分布式开发 （不同的服务部署在不同的机器节点上，并且一个服务也可以部署在多台机器上，然后利用 Nginx 负载均衡访问。这样就解决了单点部署(All In)的缺点，大大提高的系统并发量）
5. 数据库分库（读写分离）、分表（水平分表、垂直分表）

当MySQL单表记录数过大时，数据库的CRUD性能会明显下降，一些常见的优化措施如下：

1. 限定数据的范围： 务必禁止不带任何限制数据范围条件的查询语句。比如：我们当用户在查询订单历史的时候，我们可以控制在一个月的范围内；
2. 读/写分离： 经典的数据库拆分方案，主库负责写，从库负责读；
3. 垂直分区： 根据数据库里面数据表的相关性进行拆分。 例如，用户表中既有用户的登录信息又有用户的基本信息，可以将用户表拆分成两个单独的表，甚至放到单独的库做分库。简单来说垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表。 如下图所示，这样来说大家应该就更容易理解了。
   
   垂直拆分的优点： 可以使得行数据变小，在查询时减少读取的Block数，减少I/O次数。此外，垂直分区可以简化表的结构，易于维护。垂直拆分的缺点： 主键会出现冗余，需要管理冗余列，并会引起Join操作，可以通过在应用层进行Join来解决。此外，垂直分区会让事务变得更加复杂；
4. 水平分区： 保持数据表结构不变，通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中，达到了分布式的目的。 水平拆分可以支撑非常大的数据量。 水平拆分是指数据表行的拆分，表的行数超过200万行时，就会变慢，这时可以把一张的表的数据拆成多张表来存放。举个例子：我们可以将用户信息表拆分成多个用户信息表，这样就可以避免单一表数据量过大对性能造成影响。
   
   水平拆分可以支持非常大的数据量。需要注意的一点是:分表仅仅是解决了单一表数据过大的问题，但由于表的数据还是在同一台机器上，其实对于提升MySQL并发能力没有什么意义，所以 水平拆分最好分库 。水平拆分能够 支持非常大的数据量存储，应用端改造也少，但 分片事务难以解决 ，跨界点Join性能较差，逻辑复杂。《Java工程师修炼之道》的作者推荐 尽量不要对数据进行分片，因为拆分会带来逻辑、部署、运维的各种复杂度 ，一般的数据表在优化得当的情况下支撑千万以下的数据量是没有太大问题的。如果实在要分片，尽量选择客户端分片架构，这样可以减少一次和中间件的网络I/O。

下面补充一下数据库分片的两种常见方案：

• 客户端代理： 分片逻辑在应用端，封装在jar包中，通过修改或者封装JDBC层来实现。 当当网的 Sharding-JDBC 、阿里的TDDL是两种比较常用的实现。
• 中间件代理： 在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。 我们现在谈的 Mycat 、360的Atlas、网易的DDB等等都是这种架构的实现。

1. 采用集群 （多台机器提供相同的服务）
2. CDN 加速 (将一些静态资源比如图片、视频等等缓存到离用户最近的网络节点)
3. 浏览器缓存
4. 使用合适的连接池（数据库连接池、线程池等等）
5. 适当使用多线程进行开发。

4. 一致性

4.1 系统角度的一致性

1. 强一致性：当更新操作在某个副本上执行成功后，之后所有的读操作都要能够获得最新的数据。对于单副本而言，读写操作都是在同一数据上执行，很容易保证一致性；而对于多副本数据，则需要使用分布式协议如2PC协议。
2. 弱一致性：当更新某数据时，用户读到最新的数据需要一段时间。
3. 最终一致性：它是一种特殊形式的弱一致性。它不能保证当某个数据Ｘ更新后，在所有后续对Ｘ的操作能够看到新数据，而是需要一个时间片段，在经过该时间片段之后，则能保证。在这个时间片段内，数据可能是不一致的，该片段称“不一致窗口“。

4.2 用户角度的一致性

1. 单调读一致性（Monotonic-read Consistency）当进程从一个地方读出数据x，那么以后再读到的x应该是和当前x相同或比当前更新的版本。也就是说，如果进程迁移到了别的位置，那么对x的更新应该比进程先到达。以分布式邮件数据库系统为例。每个用户的邮箱可能分布式地复制在多台机器上。邮件可能被插入任何一个位置的邮箱。但是，数据更新是以一种懒惰的方式传播的。假设用户在杭州读取了他的邮件（假定只读取邮件不会影响其他邮箱，也就是说，消息不会被删除，甚至不会被标记为已读），当用户飞到惠州后，单调读一致性可以保证当他在惠州打开他的邮箱时，邮箱中仍然有杭州邮箱里的那些消息。
2. 单调写一致性（Monotonic-write Consistency）跟单调读相似，如果一个进程写一个数据 x，那么它在本地或迁移到别的地方再进行写操作的时候，原来的写操作必须先传播到这个位置。也就是说，进程要在任何地方至少和上一次写一样新的数据。
3. 读写一致性（Read-your-writes Consistency) 读写一致性指一个进程对于数据x的写操作，进程无论到任何副本上都应该能被后续读操作看到这个写操作的影响，也就是看到写操作的影响或更新的值。也就是说，写操作总是在同一个进程执行的后续读操作之前完成的，而不管这个后续读操作发生在什么位置。
4. 写读一致性（Writes-follow-reads Consistency)顾名思义，写读一致性就是在读操作后面的写操作基于至少跟上一次读出来一样新的值。也就是说，如果进程在地点1读了x，那么在地点2要写x的副本的话，至少写的时候应该基于和地点1读出的一样新的值。举个例子，用户先读了文章A，然后他回复了一篇文章B。为了满足读写一致性，B被写入任何副本之前，需要保证A必须已经被写入那个副本。即，当原文章存储在某个本地副本上时，该文章的回应文章才能被存储到这个本地副本上。

5. 可扩展

可扩展性是指当系统的任务（work）增加的时候，通过增加资源来应对任务增长的能力。可扩展性是任何分布式系统必备的特性，这是由分布式系统的概念决定的：

分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统

分布式系统的出现是为了解决单个计算机无法完成的计算、存储任务。那么当任务规模增加的时候，必然就需要添加更多的节点，这就是可扩展性。

扩展性的目标是使得系统中的节点都在一个较为稳定的负载下工作，这就是负载均衡，当然，在动态增加节点的时候，需要进行任务（可能是计算，可能是数据存储）的迁移，以达到动态均衡。

　　那么首先要考虑的问题就是，如何对任务进行拆分，将任务的子集分配到每一个节点，我们称这个过程问题Partition（Sharding）。

1. 分片分式，即按照什么算法对任务进行拆分

常见的算法包括：哈希（hash），一致性哈希（consistency hash），基于数据范围（range based）。每一种算法有各自的优缺点，也就有各自的适用场景。

1. 分片的键，partition key

partition key是数据的特征值，上面提到的任何分片方式都依赖于这个partition key，那么该如何选择呢

partition key会影响到任务在分片之间的均衡，而且一些系统中（mongodb）几乎是不能重新选择partition key的，因此在设计的时候就得想清楚

1. 分片的额外好处

提升性能和并发：不同的请求分发到不同的分片

提高可用性：一个分片挂了不影响其他的分片

1. 分片带来的问题

如果一个操作需要跨越多个分片，那么效率就会很低下，比如数据中的join操作

1. 元数据管理

元数据记录了分片与节点的映射关系、节点状态等核心信息，分布式系统中，有专门的节点（节点集群）来管理元数据，我们称之为元数据服务器。元数据服务器有以下特点：

高性能：cache

高可用：冗余 加 快速failover

强一致性（同时只有一个节点对外提供服务）

1. 任务的动态均衡

为了达到动态均衡，需要进行数据的迁移，如何保证在迁移的过程中保持对外提供服务，这也是一个需要精心设计的复杂问题。

Ref

1. https://www.cnblogs.com/hxsyl/p/4381980.html CAP定理
2. https://www.cnblogs.com/xybaby/p/7787034.html 分布式系统概念
3. https://www.cnblogs.com/xybaby/p/8544715.html
4. 《亿级流量网站架构核心技术》