【Redis】初识分布式系统

单机架构

分布式系统

应用数据分离架构

应用服务集群架构

读写分离/主从分离架构

冷热分离架构

垂直分库

微服务架构

分布式名词概念

本篇博文，将根据分布式系统的演进一步一步介绍每一种架构的形式，最后为大家总结了一些分布式中常用的名词解释

单机架构

单机架构简单来说就是只有一台服务器，这台服务器完成项目中的所有工作

假设项目是一个电商网站，那么单机架构图如下：

上图中，后端服务主要分为两部分：

应用服务：应用服务就是程序员编写的一些应用程序
数据库服务：数据库服务常见的有MySQL服务
注意：MySQL是一个C/S结构的程序，本体是MySQL服务器(存储和组织数据的部分)

在上图中，数据库服务可以去掉，由应用服务即处理业务，也存储数据。也可以实现但较为麻烦！

在早些年，单机架构有着一系列的性能瓶颈，但随着硬件水平的提高，哪怕只有一台主机，主机的性能也是很高的，基本能满足。

在单机架构中上述服务都由一台服务器提供，单机结构在大多数小公司(服务器请求较少时)当中被采用

分布式系统

分布式系统的引入

尽管我们说现在服务器的性能经过多年的发展，已经非常高了，但它的性能也有瓶颈。

如果一个项目业务进一步增加(请求繁忙，处理不过来)，用户量和数据量都水涨船高，高到最后达到了一台主机难以应付时我们应该怎么办呢？

办法分为两种：

开源：这种解决方法简单粗暴，啥不够加啥就好，CPU不够用就换个更牛的CPU，内存不够换个更牛的内存，依次类推
节流：软件优化，这比较考验程序员的能力，程序员需要通过性能测试找到哪个环节的瓶颈，并对此进行一系列优化

对于节流方式，我们能理解，但当节流方式不可用了，即优化已经到了极致了，还是难以应付大量的业务，我们只能采用开源方法！

但对于一台主机来说，它的硬件资源也是有上限的

硬件资源包括但不限于如下几种：

CPU
内存
硬盘
网络

可以看出，一台主机加装的硬件数量受主板的扩展能力限制。你总不可以一台主机装20个CPU吧？

那么如果我们一台主机开源也已经做到极致了，还是无法应付大量的业务，我们应该怎么办呢？

此时我们只能引入多台主机了！当然，不是说一台主机买来了就可以直接解决问题了，而是需要我们在软件上做出对应的调整和适配后才可以！

一旦引入了多台主机，那么我们的系统可以称之为分布式系统

分布式系统正确认识

通过上述的一系列过程，我们会发现一个项目不是一定要设计成分布式系统才是最优的，设计成分布式系统是要根据业务来判断的，这是万不得已的下下策，因为分布式系统会带来弊端

分布式系统的弊端：系统的复杂程度大大提高，引入越多的主机，那么分布式系统的复杂程度可以说是成指数增长的，也就是出现bug的概率会提高！

分布式系统的分类

根据演化过程，分布式系统可以分成如下几类：

应用数据分离架构
应用服务集群架构
读写分离/主从分离架构
冷热分离架构
垂直分库
微服务架构

接下来，本文将根据如上架构进行一一详解

应用数据分离架构

应用数据分离架构指的是把单机架构中的应用服务和数据库服务分别由两台服务器来提供，如下图：

当分离以后，对于两个服务器我们可以分情况讨论：

对于应用服务来说，它伴随着大量的业务处理，也就比较吃CPU和内存资源，那么我们可以为应用服务器提供较好的CPU和较大的内存
对于数据库服务来说，它伴随着大量的存储需求，也就比较吃硬盘空间和硬盘访问速度，那么我们可以为存储服务器配置更大硬盘(硬盘空间)，也可以上SSD(硬盘访问速度)。

可以看到，当我们把两个服务分别部署到两台服务器以后，我们可以根据服务器的具体业务场景，为服务器进行不同的硬件配置，刀都花在了刀刃上，有效提高了性价比。这也就是应用数据分离架构的主要优势！

应用服务集群架构

应用服务集群架构指的是把单机架构中的应用服务分别部署到多台服务器当中，并配备一个负载均衡器(网关服务器)，负载均衡器主要应用于请求到来时分析该请求应该分发给哪个应用服务器！负载均衡器的分发采用特定算法！

如下图：

为什么有应用服务集群架构？

在应用数据分离架构中，如果业务处理需要占用大量的CPU和内存，导致CPU和内存资源耗尽，那么我们只能引入更多的应用服务器。原先的业务处理请求分别分发给不同的应用服务器，有效减小了单机的弊端

假设业务请求一共有10000个，应用服务器有两个，那么每个应用服务器只需要处理5000个请求即可

需要注意的是：应用服务集群架构的每一个应用服务器都能处理单个完整的业务请求。区别一下微服务

负载均衡器的负载问题

通过应用服务集群架构图我们可以看出，尽管应用服务器确实分别承担了部分请求，但对于负载均衡器来说，它承担了所有的请求，那么它会不会顶不住呢？

实际上，负载均衡器，对于请求量的承受能力，要远超过应用服务器。

负载均衡器只进行请求的分发，就好比公司中的领导只负责分配工作，我们会发现公司领导分配工作时的时间是远远小于我们开发的时间的，也就是成本低。负载均衡器也同理

应用服务器就相当于程序员，当领导分配给你任务时，你是完成具体的工作的，完成具体工作的时间肯定是比公司领导分配给你任务时的时间大的多的！

多负载均衡器

尽管我们说负载均衡器对于请求的承受能力是很大的，但再大也会有一个上限。

比如说一个老板分配10个人的任务时还好，那么如果要一个老板分配1000或10000个人的任务呢？

所以当请求量大到负载均衡器也扛不住了，那么我们可以引入多个负载均衡器，实际上就是多个机房，每个负载均衡器处理一个机房的服务器请求，并配备全局负载均衡器用于发送请求给下级负载均衡器，全局负载均衡器可以一次发送多个请求给下级负载均衡器

依次类推，理论上来说我们处理请求个数是无限的

但多负载均衡器也带来了一些挑战：分布式系统中有的主机个数越来越多，导致系统的复杂程度越来越高，出现BUG的概率也越来越大

读写分离/主从分离架构

读写分离架构指的是把存储服务器分为两个部分

主(master)服务器
从(slave)服务器

主服务器负责处理数据库的写入，从服务器负责读数据库

由于一般来说对数据库的写入操作远远小于访问数据库的次数，所以一般来说主服务器是一个，而从服务器可以有多个(一主多从)

如下图：

其中主服务器负责写入数据库，从服务器负责读取数据库

同时，当应用服务访问从服务器时通过负载均衡的方式调用从服务器！

当主服务器发生写入操作时，需要保证数据一致性，所以数据要同步到所有从服务器中

为什么要有读写分离/主从分离架构？

上述，增加应用服务器，确实能够处理更高的业务请求量，但是随之存储服务器，要承担的请求量也就增多了，并且存储服务器的请求都堆积到一台服务器当中，那么存储服务器会不会扛不住呢？

显然是可能会的，那么如何处理呢？

主要方式还是开源节流，我们接下来讨论假设节流已经做到了极致，无法进行优化，那么我们只能从开源入手，即引入更多的存储服务器，其中较为经典的就是读写分离/主从分离架构

冷热分离架构

冷热分离架构是针对存储服务器的效率问题的。

二八原则：20%的数据，大概率能支持80%的访问量

我们可以把对读数据时分为两种，第一种是访问的是20%热点数据，那么我们可以让它直接访问缓存服务器，第二种是访问的是80%的数据，那么我们可以让它访问从服务器

注意：缓存服务器就是Redis的功能体现！

根据二八原则，冷热分离架构能大大服务器访问数据的效率

冷热分离架构的弊端

缓存服务器的介入，又进一步提高了系统的复杂程度，引入了一系列问题

当存储服务器写入时，缓存服务器同步成功，但从服务器同步失败怎么处理？
当存储服务器写入时，缓存服务器同步失败，从服务器同步成功怎么处理？
。。。

垂直分库

垂直分库解决的问题是，当数据库的内容过大时，可以把一个数据库分为多个存储集群，每个存储集群保存一部分数据。

当某个表的内容过大时，也可以对表内部项进一步划分成多个表

如下图，为垂直分库架构的基本结构：

具体的分库分表如何实现，需要根据具体业务具体分析！总的来说垂直分库解决的是单机存储空间的问题

微服务架构

在之前的架构体系中，都是由应用服务器独立完成所有的业务逻辑，哪怕分成多个应用服务器以后也还是单机独立完成所有业务。

这会导致这一个应用服务器的代码逻辑越来越复杂！

于是人们就把一个单独的业务逻辑进行进一步划分，也就是把应用服务器分为多个子服务器，每个子服务器完成一小块业务逻辑。

例如一个电商系统的业务逻辑包含用户模块、商品模块、交易模块。当设计了子服务器以后每一个子服务器只需要完成单独的模块即可，如下图：

图中，这些子系统集群就是我们所说的微服务，而这个电商系统就是微服务系统！

不难看出，有了微服务以后，服务器的种类和数量就增加了！

为什么要有微服务架构？

实际上微服务本质上解决的是"人"的问题

对于一个小公司来说，只有两三个开发，那么完全没有必要搞成微服务架构！

但对于一个大公司来说，有着数以百计的开发，那么设计成微服务是合理的

对于大公司来说，由于人太多，那么就需要有配套的管理机制。于是就把人划分组织结构，分成多个组，每个组配备领导进行管理。当划分成多个组以后，就需要进行分工。那么微服务是有利于组和组之间的分工的！

还是以电商系统为例，我们划分三个组：用户组、商品组、交易组

那么对于每一个组来说，只需要专精好它们组的代码即可，有利于代码优化

微服务的劣势

引入微服务，解决了人的问题，但与此同时也付出了一些代价

系统性能下降：拆出来更多的服务，多个功能之间要更依赖网络通信。网络通信的速度很可能是比硬盘慢的。

系统性能下降的解决方案：要想保证性能不下降太多，只能引入更多的机器，更多的硬件资源。幸运的是，随着硬件技术的发展，现在已经有了万兆网卡，万兆网卡的读写速度大概率是大于磁盘/硬盘的。但万兆网卡非常贵！

系统复杂程度提高，可用性受到影响的解决方案：服务器更多了，出现问题的概率就更大了，这就需要有一系列的手段，来保证系统的可用性(更丰富的监控报警，以及配套的运维人员)

微服务的优势

微服务最主要的优势就是解决了"人"的问题

使用微服务，可以更方便于功能的复用！

微服务系统可以给不同的服务进行不同的部署，当某个服务模块使用频繁，那么我们可以给该模块配备更多的主机，更多的硬件资源。相反，则可以减少该模块配套的资源

分布式名词概念

常见名词

应用/系统：一个应用，指的就是一个/一组服务器程序

模块/组件：一个应用，里面有很多个功能，每个独立的功能，就可以称之为是一个模块/组件

分布式：从物理上引入多个主机/服务器，协同配合完成一系列的工作

集群：从逻辑上引入多个主机/服务器，协同配合完成一系列的工作

注意：在实际工程中，基本上不会过于纠结分布式和集群的区别，一般视它们为等价

主(master)/从(slave)：分布式中的一种比较典型的结构。多个服务器结点，其中一个是主，另外的是从。从节点的数据要从主节点这里同步过来

中间件：与业务无关的服务(功能更通用的服务)，例如数据库、缓存、消息队列...

可用性

分布式系统的第一要务：可用性

计算分布式系统可用性：系统整体可用的时间 / 总的时间

例如一年365天，分布式系统正常工作360天，则可用性为 360 / 365

可用性越高越好

性能指标

衡量服务器性能指标：响应时长

响应时长是指从客户端发起请求到收到完整响应的时间间隔。

响应时长越小越好，但不需要过度纠结这个指标，需要根据具体业务具体分析。例如有些业务处理逻辑要花费更多的时间，那么响应时长自然高。有些业务处理逻辑简单，花费时间少，响应时长自然低！

衡量服务器性能指标：吞吐和并发

这两是衡量系统的处理请求的能力，也就是衡量服务器性能的一种方式。