分布式系统的发展史

程序猿小马

已于 2024-03-28 09:07:29 修改

阅读量844

点赞数 24

文章标签：分布式

于 2024-03-27 18:00:30 首次发布

本文链接：https://blog.csdn.net/qq_54469537/article/details/137002176

版权

🐳今日良言：且视他人之疑目如盏盏鬼火，大胆地去走自己的夜路

🐇一、常见概念

🐇二、发展史

今日良言：且视他人之疑目如盏盏鬼火，大胆地去走自己的夜路

一、常见概念

在正式介绍分布式系统之前，让我们先来了解一下分布式相关的一些常见概念。

应用（Application）/ 系统（System)

为了完成⼀整套服务的⼀个程序或者⼀组相互配合的程序群。

举例：为了完成一项任务，由此搭建的由一个人活着一群相配合的人组成的团队

模块（Module）/ 组件（Component）

当应用较复杂时，为了分离职责，将其中具有清晰职责的、内聚性强的部分，抽象出概念，便于理解。

举例：军队中为了进⾏某据点的攻克，将人员分为突击小组、爆破小组、掩护小组等。

分布式（Distributed）

系统中的多个模块被不属于不同服务器之上，就可以将这个系统称为分布式系统。比如：Web 服务器和数据库分别在不同服务器上工作，或者多台 Web 服务器被分别部署在不同服务器上。

举例：在疫情期间，无法到公司上班，因此，为了某些工作需要，原来在同一个办公室工作的的小组成员被分散到一个城市的不同场地或者多个城市的不同场地进行远程配合工作完成目标。

跨主机之间的模块间的通信基本要记住网络支撑完成。

集群（Cluster）

被部署于多台服务器上的，为了实现特定目标的一个/组特定的组件，整个整体被称为集群。

举例1：多个MySQL工作在不同服务器上，共同提供数据库目标服务，由此可以被称为一组数据库集群。

举例2：广义的集群：只要是多个机器，构成了分布式系统，都可以称为是一个“集群”。

举例3：狭义的集群：redis 提供的集群模式，这个集群模式之下，主要是解决存储空间不足的问题（拓展存储空间）。

主（Master）/ 从(Slave)

集群中，通常有一个程序需要承担更多的责任，被称为主。其他承担附属职责的被称为从。

举例：学校小组任务一般会选举一个组长，组长就需要承担比组员更多的责任，而组员就需要承担另外一些责任来配合组长完成任务。

中间件（Middleware）

可以理解成一种软件，它可以帮助不同的应用系统之间进行沟通和数据交换。

举个例子：可以想象一个邮局的场景：

邮局作为中间件：假设你住在城市A，你的一个朋友住在城市B，你们两个都想要互相寄送信件。如果没有邮局（中间件），你们可能需要自己亲自前往对方的城市去递送信件，这不仅耗时耗力，而且效率低下。而有了邮局这样的服务机构（中间件），你们只需要将信件交给邮局，邮局会负责将信件从城市A运送到城市B，并最终交到你朋友的手中。这样，即使你们身处不同的地方，也能轻松地通信。
邮局提供的服务：邮局不仅仅提供传递信件的服务，还提供了如挂号、保险、快递等多种服务（共性功能），这些都是为了满足不同客户的需求而设计的。无论客户需要哪种服务，邮局都能提供相应的解决方案，这样就避免了每个人为了寄信而自己建立一套复杂的传送系统的情况。

总的来说，中间件就像是一个连接不同应用和服务的桥梁，它提供了一种便捷的方式来实现资源共享和功能共享。在技术领域中，中间件的存在极大地简化了复杂系统的开发和维护工作，提高了软件的复用性和效率。

二、发展史

在介绍完了分布式相关的一些常见概念之后，接着就上主菜了，让博主来介绍一下分布式系统是如何蓬勃发展，如今这么火爆的。

2.1单机架构

在初始阶段，小型系统的应用程序、数据库、文件等所有资源都部署在一台服务器上，这通常被称为LAMP（Linux, Apache, MySQL, PHP）架构。

2.2 功能分离架构

随着系统上线，我们收获了一些忠实用户，这使得系统的访问量逐步上升，逐渐逼近了硬件资源的极限。面对当前的性能压力，我们需要进行系统重构，以提升系统的承载能力以，因此，我们可以选择将应用和数据分离，放到不同的主机上部署。

2.3应用服务器集群架构

我们的系统被广大用户所喜爱，单台应用服务器已经无法满足需求了，针对这种情况，我们了解到有两种方案可以解决这个问题：

垂直扩展 / 纵向扩展 Scale Up。

通过购买性能更优、价格更⾼的应⽤服务器来应对更多的流量。这种方案的优势在于完全不需要对系统软件做任何的调整；但劣势也很明显：硬件性能和价格的增长关系是⾮线性的，意味着选择性能 2 倍的硬件可能需要花费超过 4 倍的价格，其次硬件性能提升是

有明显上限的。

⽔平扩展 / 横向扩展 Scale Out。

通过调整软件架构，增加应用层硬件，将用户流量分担到不同的

应用层服务器上，来提升系统的承载能⼒。这种⽅案的优势在于成本相对较低，并且提升的上限空间也很大。但劣势是带给系统更多的复杂性，需要掌握更丰富的经验。

经过深思熟虑，我们决定使用水平扩展的方案来解决这个问题，但是和需要引入一个新的组件---负载均衡；为了解决用户流量向哪台应用服务器分发的问题，需要⼀个专门的系统组件做流量分发。

实际中负载均衡不仅仅指的是工作在应用层的，甚至可能是其他的网络层之中。同时流量调度算法也有很多种，这⾥简单介绍几种较为常见的：

Round-Robin 轮询算法

即非常公平地将请求依次分给不同的应用服务器。

Weight-Round-Robin 轮询算法

为不同的服务器（比如性能不同）赋予不同的权重（weight），能者多劳

一致性哈希散列算法

通过计算⽤⼾的特征值（比如 IP 地址）得到哈希值，根据哈希结果做分发，优点是确保来相同用户的请求总是被分给指定的服务器。也就是我们平时遇到的专项客⼾经理服务。

2.4读写分离/主从分离架构

在上述的架构里，无论扩展多少台服务器，这些请求最终都会从数据库读写数据，到一定程度之

后，数据的压力就是系统承载能力的瓶颈点，

此时，不妨想想，我们是否可以像扩展应用服务器一样扩展数据库服务器？

答案是否定的，因为数据库服务有特殊性。

如果将数据分散到各台服务器之后，数据的⼀致性将⽆法得到保障。所谓数据的⼀致性，此处是指：针对同⼀个系统，无论何时何地，我们都应该看到⼀个始终维持统⼀的数据。想象⼀下，银行管理的账⼾⾦额，如果收到⼀笔转账之后，⼀份数据库的数据修改了，但另外的数据库没有修改，则用户得到的存款⾦额将是错误的。

因此，就得采用另一种方法。

我们保留一个主要的数据库作为写入的主数据库，其他的数据库作为从属数据库。从库的所有数据都来自主库，经过数据同步后，从库可以维护与主库一致的数据，然后为了分担数据库的压力，我们可以将写数据请求全部交给主库处理，但读请求分散给所有从库。在绝大多数系统中，读请求是远大于写请求的，所以，将读请求分散给各个从库以后，数据库的压力就没那么大了。

2.5引入缓存-冷热分离架构

随着访问量持续增加，我们发现业务中一些数据的读取频率远大于其他数据的读取频率。比如：dy搜索框会展示每天的热搜词，这部分数据就是当天读取频率比较多的数据。我们把这部分数据成为热点数据。与之相对应的，就是冷数据。

针对热数据，我们想要提高它们的读取相应时间，因此，可以增加本地缓存，并在外部增加分布式缓存。通过缓存，就能避免有大量的请求同时操作数据库，作为一面护盾，为数据库 “抵挡伤害”，避免数据库宕机。

2.6 垂直分库（分库分表）

随着业务的数据量增大，大量的数据存储在同⼀个库中已经显得有些力不从心了，所以可以按照业务，将数据分别存储。比如针对评论数据，可按照商品ID进⾏hash，路由到对应的表中存储；针针对支付记录，可按照小时创建表，每个小时表继续拆分为小表，使用用户ID或记录编号来路由数据。只要实时操作的表数据量足够小，请求能够⾜够均匀的分发到多台服务器上的⼩表，那数据库就能通过

水平扩展的方式来提⾼性能。这种做法显著的增加了数据库运维的难度，对DBA的要求较⾼。数据库设计到这种结构时，已经可以称为分布式数据库，但是这只是⼀个逻辑的数据库整体，数据库里不同的组成部分是由不同的组件单独来实现的，如分库分表的管理和请求分发，由Mycat实现，SQL的解析由单机的数据库实现，读写分离可能由网关和消息队列来实现，查询结果的汇总可能由数据库接口层来实现等等，这种架构其实是MPP（大规模并行处理）架构的⼀类实现。