【Redis】如何从单机架构演化为分布式系统

时光不染。回忆不淡

已于 2024-08-19 08:41:58 修改

阅读量425

点赞数 10

分类专栏： Redis 文章标签： redis 架构数据库

于 2024-08-18 21:55:39 首次发布

本文链接：https://blog.csdn.net/m0_74105656/article/details/141304395

版权

Redis 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

分布式系统的演化过程

一.相关的概念.
二. 演化过程.
三. 总结.

一.相关的概念.

1.1 应用(Application) / 系统(System)

为了完成一套服务的一个/一组互相配合的程序群. 也就是一个/一组服务器程序.
举个例子:
- 为了完成一个任务, 而搭建的由一个人或者一群相互配的人组成的团队.

1.2 模块(Module) / 组件(Component)

当应用较复杂时, 为了分离职责, 将其中具有清晰职责的,内聚性强的部分,抽象出概念,以便于理解. 也可以理解为每一个独立的功能.
举个例子:
- 军队中为了进行某据点的攻克,将人员分为突击小组, 爆破小组, 掩护小组, 通信小组等, 每一个小组都具有自己独立的功能,但是他们彼此又被一个事件联系起来.

1.3 分布式(Distributed)

系统中的多个模块被部署在不同的服务器上, 就可以成为分布式系统. 如Web服务器与数据库分别工作在不同的服务器上,或者多台Web服务器被分别部署在不同的服务器上. 也就是引入多个主机/服务器,协同配合完成一系列的工作.
举个例子:
- 为了更好的满足现实需要,一个在同一个办公场地的工作小组被分散到多个城市的不同工作场地中进行远程配合工作完成目标. 跨主机模块之间的通信基本要借助网络支撑完成.

1.4 集群(Cluster)

集群是指一组相互独立的计算机，通过高速通信网络组成的一个较大的计算机服务系统，每个集群节点都是运行各自服务的独立服务器。这些服务器之间可以彼此通信，协同向用户提供应用程序、系统资源和数据，并以单一系统的模式进行管理. 和分布式是一样的,也是引入多个主机/服务器, 协同配合完成一系列的工作. 但是分布式是物理上的多个主机, 而集群是逻辑上的多个主机

1.5 主(Master) / 从(Slave)

在集群中, 通常有一个程序需要承担更多的责任, 称为主; 其他承担附属职责的被称为从.
举个例子:
- MySQL集群中,只有其中一台服务器上的数据允许进行数据的写入(增删改), 其他数据库的数据修改全部要从这台数据库同步而来, 我们把能够写入的数据库称为主库, 其他的数据库称为从库.

1.6 中间件(Middleware)

一种独立的系统软件或服务程序，用于在分布式应用软件中共享不同技术之间的资源。它位于客户端/服务器操作系统之上，管理计算机资源和网络通信
举个例子:
- 一家饭店开始的时候, 每天都会去菜市场挑选买菜, 但随着饭店业务量的变大, 就会成立一个采购部门,由采购部门专门负责买菜, 此时这个采购部门就成为了厨房和菜市场之间的桥梁, 被称为中间件.

二. 演化过程.

2.1 单机架构

单机架构: 简单来说就是只有一个服务器, 并且这个服务器负责所有的工作.

在这里插入图片描述

2.2 应用服务器和数据库服务器分离

随着用户数量的增多, 应用服务器和数据库服务器就会出现互相争抢硬件资源的情况. 此时一个合理的解决方案就是—>数据库服务器和应用服务器分离
- 应用服务器: 里面包含更多的可能是业务逻辑,因此可能会消耗更多的CPU和内存;
- 数据库服务器: 主要是存储数据,因此可能会消耗更多的硬盘空间, 更快的数据访问.

2.3 引入更多的应用服务器和负载均衡.

由于应用服务器比较吃"CPU"和"内存" , 如果把CPU或者内存吃没了, 此时就会出现一系列的问题,
于是我们就需要引入更多的应用服务器,才能有效的解决上述的问题.
随着用户的请求数量不断增多,此时又会出现另一个问题, 当请求到达的时候该如何合理的分配这些请求到那个应用服务器. 于是就引入了负载均衡.
当用户发送请求过来时, 请求会先到达负载均衡器(网关服务器), 然后负载均衡器再将请求分发给下面的应用服务器. (上图看起来是两个应用服务器, 实际上可能是多个)
负载均衡也可能会出现"吃不消"的情况,此时只需引入更多的负载均衡来解决这个问题.

2.4 引入数据库读写分离.

上面已经解决了请求过度导致的硬件资源不足的部分问题, 但是数据库也面临着请求量过多的问题, 因此我们引入了读写分离的策略.
当我们引入多台数据库服务器时, 数据库服务器又分为两大类, 一种叫做主数据库(master), 一种叫做从数据库(slave). 主数据库负责写 (增删改), 从数据库负责读(查), 并且从数据库中的数据需要从主数据库中同步, 也就是说上面的应用服务器需要读数据的时候, 就从从数据库中读, 需要写数据的时候, 就在主数据库中写, 同时主数据库也会实时地, 定期地将数据同步到从数据库.
这样从一个数据库既负责读又负责写, 过渡到了两个数据库, 一个数据库负责写, 一个数据库负责读, 从而就把每一台机器的压力就降低了.
而且实际应用场景中, 读的频率是比写的频率要高很多的, 所以一般使用到数据库分离时, 主数据库服务器一般是一个, 从服务器可以有多个 (一主多从). 同时这多个从服务器又可以使用负载均衡的方式让上面的应用服务器进行访问, 这样又可以进一步降低每一台从服务器的压力

2.5 引入缓存.

由于数据库天然有个问题, 响应速度 “慢” !! 不管怎么进行分库, 它终究是要从硬盘读取数据, 而读硬盘在某些场景下是接受不了的, 所以为了更进一步的提高数据访问效率, 还可以将数据进行 “冷热” 拆分, 其中热点数据放到缓存中, 而缓存的访问速度往往比数据库快很多.
根据二八原则: 20% 的数据, 能够支持 80% 的访问量. 所以缓存服务器中只是存储了一小部分热点数据, 也就是会被频繁访问到的数据, 而数据库中存储的仍然是完整的全量数据.
后续应用服务器想要读数据的时候, 就可以先从缓存中读取, 如果缓存中存在, 就不需要读数据库了, 如果缓存中不存在, 那么再去读数据库. 由于二八原则, 所以大部分的应用服务器请求都能在缓存中找到答案, 这就是数据库服务器所承担的压力又进一步减小了.

2.6 数据库分库分表

咱们引入分布式系统, 不光要能够应对更高的请求量(并发量), 同时也要能够应对更大的数据量. 请求量咱们目前解决了, 那么是否可能会出现, 一台数据库服务器已经存不下数据了呢 ? 答案无疑是肯定的. 虽然一台服务器存储的数据量可以达到几十个 TB, 即使如此也可能会存不下, 比如 : 短视频. 于是我们就需要针对数据库进行分库分表.
最初我们的架构是一个数据库服务器里头有多个数据库(create database…), 而分库就相当于引入多个数据库服务器, 每个数据库服务器存储一个或者一部分数据库.
用户表由一个主服务器来存, 然后引入多个从服务器, 商品表由一个主服务器来存, 然后引入多个从服务器…
- 此时应用服务器想要读取用户表, 就可以访问用户表的服务器, 想要读取商品表, 就可以访问商品表的服务器, 当然读数据之前仍然可以先读缓存, 缓存没有再读数据库(主从).
- 如果某一张表特别大, 比如交易表大到一台主机存不下, 我们也可以针对表进行拆分. 可以将交易表拆成多张表, 分别存储到不同的数据库服务器上

在这里插入图片描述

2.7 微服务架构

在一个应用服务器之中, 一个服务器程序里面做了很多业务,这就可能导致一个服务器的代码越来越复杂,为了方便代码的维护, 就可以把这样一个复杂的服务器拆分为更多的功能更单一, 更小的服务器.

引入微服务是为了解决 “人” 的问题!!
代价:
- 系统性能下降–>在引入微服务之前, 我们的用户, 商品, 交易这些模块的相互调用, 直接进程内就能调用. 而现在我们需要跨主机通过网络进行通信, 而网络通信这件事情可就比进程内通信慢太多太多了.网络比硬盘的速度还慢
- 系统的复杂程度提高, 可用性受到影响—>在微服务环境下, 服务器更多了, 出现问题的概率就更大了, 这就需要一系列的手段来保证系统的可用性了. 比如 : 更丰富的监控报警, 配套的运维人员等等…
优势:
- 解决了人的问题.
- 使用微服务,更方便于功能的复用.
- 可以给不同的服务进行不同的部署.