分布式：分布式系统的设计

骑猪看日落 2024-04-17 05:37 83阅读 0赞

\#整理了一些博文作为分布式相关理论的学习笔记，同时加上了一些个人的理解，尊重原创者，文章属性就设为转载吧，参考博文的链接已附在最后。

### 分布式 ###

*  **[概要，与集群的区别][Link 1]**
 *  **[分布式系统的设计][Link 2]**
 *  **[CAP 和 BASE 理论][CAP _ BASE]**

# 一、分布式系统 #

在计算机领域，当单机性能达到瓶颈时，一般有两种方式解决性能问题：

*  堆硬件，进一步提升配置；
 *  分布式设计，如水平拆分、垂直拆分。  
    分布式系统有很多种：分布式文件系统、分布式数据库、分布式 WebService、分布式计算等等，面向的情景不同，但分布式的思路大致相同，万法归一。

而分布式系统的设计说白了就是： 如何合理将一个系统拆分成多个子系统部署到不同机器上。  
讲设计方法前，先介绍分布式系统的特性：

## 1. 分布式系统的特性 ##

**（1）分布性**

空间中随机分布。这些计算机可以分布在不同的机房，不同的城市，甚至不同的国家。

**（2）对等性**

分布式系统中的计算机没有主/从之分，组成分布式系统的所有节点都是对等的。在分布式系统最常见的概念之一是副本–数据副本和服务副本。数据副本是指在不同的节点上持久化同一份数据，当某一个节点上存储的 数据丢失时，可以从副本上读取到该数据，这是解决分布式系统数据丢失问题最为有效的手段。服务副本，指多个节点提供同样的服务，每个节点都有 能力接收来自外部的请求并进行相应的处理。

**（3）并发性**

同一个分布式系统的多个节点，可能会并发地操作一些共享的资源，诸如数据库或分布式存储。

**（4）缺乏全局时钟**

既然各个计算机之间是依赖于交换信息来进行相互通信，很难定义两件事件的先后顺序，缺乏全局始终控制序列。

**（5）故障总会发生**

组成分布式的计算机，都有可能在某一时刻突然间崩掉。分的计算机越多，可能崩掉一个的几率就越大。如果再考虑到设计程序时的异常故障，也会加大故障的概率。

**（6）处理单点故障**

单点 SPoF（Single Point of Failure）：某个角色或者功能只有某一台计算机在支撑，在这台计算机上出现的故障是单点故障。当然处理方式可以是采用上面所讲的：集群。

## 2. 分布式系统的设计 ##

将系统拆分成多个子系统，这就意味着拆分后的系统必然需要通过网络进行互相通信联系。所以通信中的稳定和安全也显得尤为重要。随着业务慢慢的增长，扩展性、可靠性、数据一致性都需要进行考虑。

（1）系统拆分成子系统。这个需要设计师好好设计，将一个大系统拆分成多个小系统，分层次来维护。

（2）设计系统间的通信。在这儿我们可以使用消息中间件，开源框架帮我们解决了这个问题。如Apache ActiveMQ、RabbitMQ、Apache RocketMQ、Apache Kafka等。

（3）设计分布式计算。开源框架有 apReduce、Apache Hadoop、Apache Spark 等。

（4）大数据和分布式存储。有 Apache HBase、Apache Cassandra、Memcached、Redis、MongoDB等。

（5）分布式监控控制。常用的技术包括Nagios、Zabbix、Consul、ZooKeeper等。

#### 2.1 水平拆分和垂直拆分 ####

##### 水平拆分： #####

以购物平台为例：  
**水平拆分**是指按照 业务 对系统进行划分 。比如原来的系统中包括了交易，运营两大类，按照水平拆分的原则进行拆分，系统可以拆分成 交易系统 和 运营系统。  
优点：不同业务，往往性能要求，以及请求量是不一样的。拆分后保证业务之间的可用性影响最小化。  
缺点：拆分过程中，多个系统中可能存在重复的轮子，难于维护。

假设我们有一台服务器，它可以承担 1 百万/秒的请求，这个请求可以的是：通过 http 访问网页、通过 tcp 下载文件、jdbc 执行 sql、RPC 调用接口等等方式，现在我们有一条数据的请求是 2 百万/秒，很显然服务器很难hold 住，会各种拒绝访问，甚至宕机，怎么办呢？

一台机器解决不了的问题，那就两台。所以我们加一台机器，每台承担 1 百万。如果请求继续增加呢，两台解决不了的问题，那就三台呗。这种方式我们称之为**水平拆分**，如果实现请求的平均分配便是负载均衡了。

##### 垂直拆分： #####

垂而直拆分是将**同样的系统按照应用场景(调用方)进行拆分** 。  
比如交易系统的支付模块，上游有用户支付和商家支付两个调用流程。按照垂直拆分的规则就可以将支付模块拆分为用户支付和商家支付。  
优点：按需配给（预估调用方的流量，配置对应的机器数），各个垂直调用之间相互不影响，通过配置可以进行上游调用降级。  
缺点：几乎完全重复的轮子。

在如，我们现在有两个数据请求，数据1有 190 万，数据2有 280 万，上面那台机器也 hold 不住，我们加一台机器来负载均衡一下，每台机器处理 45 万数据1和 40 万数据2，但是平分太麻烦，不如一台处理数据1，一台处理数据2，同样能解决问题，这种方式我们称之为垂直拆分。

垂直拆分更多是用在数据库的拆分，如将某一张列很多的数据表拆分成多张数据表。

水平拆分和垂直拆分是分布式架构的两种思路，但并不是一个二选一的问题，更多的是兼并合用。

**注意：要将分布式设计中的水平拆分、垂直拆分与高并发中的水平扩展、垂直扩展区分开来。**

#### 2.2 负载均衡 ####

前面我们谈到了分布式来解决性能问题，但其附带的问题是怎么分布，即如何负载均衡。这里要解决的问题是当客户端发出请求时，应该让哪一台服务器对该请求进行处理，通常的做法是通过一台中间服务器来给客户端分配目标服务器。  
常见如 zookeeper 是分布式系统中一个负载均衡框架，它是 google 的 chubby 的一个开源实现，是 Hadoop 和 Hbase 的重要组件。  
同样的在 http 中，常听说的 nginx 也是一个负载均衡服务器，它面向的是分布式 web 服务器。

#### 2.3 同步问题 ####

分布式系统中，解决了负载均衡的问题后，另外一个问题就是数据的一致性了，这个就需要通过同步来保障。根据不同的场景和需求，同步的方式也是有选择的。

在分布式文件系统中，比如商品页面的图片，如果进行了修改，同步要求并不高，就算有数秒甚至数分钟的延迟都是可以接受的，因为一般不会产生损失性的影响，因此可以简单的通过文件修改的时间戳，隔一定时间扫描同步一次，可以牺牲一致性来提高效率。

但银行中的分布式数据库就不一样了，一丁点不同步就是无法接受的，甚至可以通过加锁等牺牲性能的方式来保障完全的一致。

在一致性算法中 paxos 算法是公认的最好的算法，chubby、zookeeper 中 paxos 是它保证一致性的核心。

# 二、分布式架构下的高可用设计 #

1.  避免单点故障  
    ○ 负载均衡技术（failover ，选址，硬件负载，软件负载，去中心化负载（gossip（redis-cluster））；  
    ○ 热备 linux HA；  
    ○ 多机房（同城灾备，异地灾备）；
2.  应用的高可用  
    ○ 故障监控（系统监控（cpu，内存）、链路监控、日志监控）自动预警；  
    ○ 应用的容错设计 （服务降级，限流） 自我保护能力；  
    ○ 数据量 （数据分片，读写分离）。  
    (待补充)

————————————————  
参考链接：  
https://blog.csdn.net/cutesource/article/details/5811914  
https://blog.csdn.net/mcb520wf/article/details/82456456  
https://my.oschina.net/niepanLs/blog/875578  
https://blog.csdn.net/yuhaiyang\_1/article/details/80892492

[Link 1]: https://steve.blog.csdn.net/article/details/100025865
[Link 2]: https://steve.blog.csdn.net/article/details/100026110
[CAP _ BASE]: https://steve.blog.csdn.net/article/details/100026209