关于分布式系统的几个问题-电子发烧友网

本文摘自：华为云社区

作者：华为加拿大研究院软件专家 Jet老师

小引

分布式系统是一个古老而宽泛的话题，而近几年因为 “大数据” 概念的兴起，又焕发出了新的青春与活力。本文将会通过对如下几个问题展开谈一下分布式系统：

什么是分布式系统？

为什么要用分布式系统？

分布式系统设计推演

CAP定理是什么？

分布式系统如何进行分布？

分布式应用通常使用的架构类型哪些?

分布式系统的优缺点有哪些？

1. 什么是分布式系统？

简单的来说，一个分布式系统是一组计算机系统一起工作，在终端用户看来，就像一台计算机在工作一样。

这组一起工作的计算机，拥有共享的状态，他们同时运行，独立机器的故障不会影响整个系统的正常运行。

我们现在举个例子，传统的数据库是存储在一台机器的文件系统上的。每当我们取出或者插入信息的时候，我们直接和那台机器进行交互。那么现在我们把这个传统的数据库设计成分布式数据库。假设我们使用了三台机器来构建这台分布式数据库，我们追求的结果是，在机器1上插入一条记录，需要在机器3上可以返回那条记录，当然了，机器1和2也要能够返回这条记录。

2. 为什么要用分布式系统？

管理分布式系统是一个非常复杂的话题，里面充满了陷阱和地雷。部署维护和调试分布式系统也是非常头疼的一件事情，那为什么还要去做呢？

分布式系统最大的好处就是能够让你横向的扩展系统。

以前面提到的单一数据库为例，能够处理更多流量的唯一方式就是升级数据库运行的硬件，这就是纵向扩展。而纵向扩展的是有局限性的。当到了一定程度以后，我们会发现即使最好的硬件，也不能够满足当前流量的需求。横向扩展是指通过增加更多的机器来提升整个系统的性能，而不是靠升级单台计算机的硬件。从价格上来说，横向扩展相比纵向扩展更容易控制。最根本的问题是纵向扩展有很强的局限性，达到最新硬件的能力以后，还是无法满足中等或者大型工作负载的技术要求。横向扩展则没有这个限制，它没有上限，每当性能下降的时候，你就需要增加一台机器，这样理论上讲可以达到无限大的工作负载支持。除此之外，在容错和低延迟上也有很多优势。容错性是指你的分布式系统的某个节点出现错误以后，并不会导致整个系统的瘫痪。而单机系统出错以后，可能会导致整个系统的崩溃。低延迟是通过在不同的物理位置部署不同的机器，通过就近获取的原则降低访问的延迟时间。

上面讨论了分布式系统的种种好处，但是我们必须要清楚设计和运行分布式系统并非易事。

3. 分布式系统设计推演

我们先讲一个场景，我们现有的网络应用变得越来越流行，服务的人数也越来越多，导致我们的应用程序每秒收到的请求，远远超过能够正常处理的数量。这会导致应用程序性能下降明显，用户也会注意到这一点。

那我们下面就来扩展一下我们的应用程序来满足更高的要求。一般来说我们读取信息的频率要远远超过插入或者修改的频率。

下面我们使用主从复制策略来实现扩展系统。我们可以创建两个新的数据库服务器，他们与主服务器同步。用户业务对这两个新的数据库只能读取。每次当向主数据库插入和修改信息时，都会异步的通知副本数据库进行更新变化。

在这一步上我们已经有了三倍于原来系统读取数据的性能支持。但是这里有一个问题，在数据库事务的设计当中，我们遵循ACID原则。但是在我们同时对其他两个数据库进行数据更新的时候，我们有一个时间窗口失去了一致性原则。如果在这个时间窗口内对两个新的数据库进行查询，可能查不到数据。这个时候如果同步这三个数据库的数据，就会影响写操作的性能。这是我们在设计分布式系统的时候，不得不承受的一些代价。

上面的主从复制策略解决了用户读取性能方面的需求，但是当数据量达到一定程度，一台机子上无法存放的时候，我们需要扩展写操作性能。要解决这样的问题，我们可以使用分区技术。分区技术是指根据特定的算法，比如用户名a到z作为不同的分区，分别指向不同的数据库写入，每个写入数据库会有若干读取的从数据库进行同步提升读取性能。

当然，这样使得整套系统变得更加复杂。最重要的难点是分区算法。你们试想一下，如果c开头的用户名比其他开头的用户名要多很多，这会导致c区的数据量非常庞大，相应地，对于c区的请求也会远远大于其他区。此时c区成为热点。要避免热点，需要对c区进行拆分。此时要进行共享数据就会变得非常昂贵，甚至可能导致停机。

如果一切都很理想，那我们就拥有了 n倍的写入流量，n是分区的数目。

当然这里也存在一个陷阱，我们进行数据分区以后，导致除了分区键以外的查询都变得非常低效，尤其是对于sql语句如join查询就变得非常之糟糕，导致一些复杂的查询根本无法使用。

这里有一个思考题:如何选择更好的分区策略算法？

4. CAP定理是什么？

这个定理是指一个分布式系统不能同时具有一致性，可用性和分区容忍性。

一致性Consistency：依次读写的是什么就是什么。

可用性Availability:整个系统不会崩溃, 每个非故障节点总会有一个相应。

分区容忍Partition tolerant:尽管有分区，系统仍能继续运行并保持其一致性和可用性。

对于任何分布式系统来说，分区容忍是一个给定的条件，如果没有这一点，就不可能做到一致性和可用性。试想如果两个节点链接断掉了，他们如何能够做到既可用又一致?

最后你只能选择在网络分区情况下，你的系统要么强一致，要么高可用。

实践表明大多数应用程序更看重可用性。这个考量的主要原因是在不得不同步机器里实现强于一致性是时，网络延迟会成为一个问题。这类因素使得应用程序通常会选择提供高可用性的解决方案。

此时采用的是最弱的一致性模型来解决的，这种模型保证了如果没有对某个项目进行新的更新，最终对该项目的所有访问都会返回最新的值。这些系统提供了BASE属性，这是相对于传统数据库的ACID来讲的。

也就是( Basically available)基本上是可用的，系统总会返回一个响应。

( Soft state)软状态, 系统可以随着时间的推移而变化，甚至在没有输入的情况下也可以变化, 如保持最终的一致性的同步。 ( Eventual consistency)最终的一致性, 在没有输入的情况下，数据迟早会传播到每一个节点上，从而变得一致。

追求高可用的分布式数据库例子有Cassandra；看重强一致性的数据库，有HBase， Redis， Zookeeper。

5. 分布式系统如何进行分布？

我们来看一下分布系统进行分布的常用方式：

5.1哈希

以哈希方式把不同的值进行哈希运算，映射到不同的机器或者节点上。这种方式在扩展的时候比较困难，因为数据分散在多个机器上很容易出现分布不均的情况，常见的哈希对象有ip，url，id等。

5.2 数据范围

按数据范围分布，比如ID在1~100的在机器a上，ID在100~200的在机器b上，诸如此类。这种分布方法数据比较均匀。如果某个节点处理能力有限，可以直接分裂这个节点。维护数据分布的这些原数据，如果量非常大的话，可能会出现单点瓶颈。因此一定要严格控制元数据量。

5.3 数据量

按数据量来分布数据，是以较为固定的大小将数据划分为若干的数据块，再把不同的数据块分布到不同的服务器上。以数据量来进行分布的这些数据，也需要被记录下来作为元数据来管理。当集群规模很大时，元数据的量也会变大。

5.4副本与数据分布

这种方式是指把数据给分散到多个服务器上。如果其中一台出现问题，请求就会被转到其他服务器上。其原理是多个机器互为副本，这是比较理想的实现负载分压的方式。

5.5一致性哈希

一致性哈希。通过哈希域构造哈希环，在增加机器时，变动的是其附近的节点，分摊的是附近节点的压力，其元数据的维护和按数量分布的维护方式一致。

我们现在来看一下使用以上方式进行分布的例子:GFS, HDFS:按数据量分布。 Map reduce:按GFS数据分布做本地化。 BigTable, HBase按数据范围分布。 Pnuts:按哈希方式或者数据范围分布。 Dynamo, Cassndra:按一致性哈希分布。 Mola, Armor, BigPipe:按哈希方式分布。 Doris:按哈希方式和按数据量分布进行组合。

6. 分布式应用通常使用的架构类型哪些?

6.1 客户端服务器

在这个类型中，分布式系统架构有一个服务器作为共享资源。比如打印机数据库或者网络服务器。它有多个客户机，这些客户机决定何时使用共享资源，如何使用和显示改变数据，并将其送回服务器，像git这样的代码仓，这是一个很好的例子。

6.2 三层架构

这种架构把系统分为表现层，逻辑层和数据层，这简化了应用程序的部署，大部分早期的网络应用都是三层的。

6.3 多层架构

上面的三层架构是多层架构的一种特殊形式。一般会把上面的三层进行更详细的划分，比如说以业务的形式进行分层。

6.4 点对点架构

在这种架构中，没有专门的机器提供服务或管理网络资源。而是将责任统一分配给所有的机器，成为对等机，对等机既可以作为客户机，也可以作为服务器。这种架构的例子，包括bittorrent和区块链。

6.5 以数据库为中心

这种架构是指用一个共享的数据库，使分布式的各个节点在不需要任何形式直接通信的情况下，进行协同工作的架构。

7. 分布式系统的优缺点有哪些？