【Redis】从单机架构到分布式，回溯架构的成长设计美学

📚️1.单机架构

所谓的单机架构，其实就是一台服务器完成所有的工作，包括业务处理，数据库数据存储等等

大致如下所示：

应用服务主要负责我们业务处理，而数据库主要负责存储数据，那么这就是一个比较基础的单体架构；

那么单体架构已经被淘汰了吗？ 1、当然没有，随着计算机的快速的发展，硬件以发展非常快，那么一台主机就能够处理极高的并发，以及存储大量的数据； 2、并且单体架构对于分布式来说，系统的复杂程度大大下降，方便开发；

但是日益增长的请求和访问量，单体架构无法胜任，（硬件资源是有上限的，包括CPU，硬盘，带宽，内存......）那么就有两种解决方式

1、开源：引入更多的硬件资源

2、节流：在软件层面，对于代码进行性能的提高，但是比较困难

所以引入下面的应用服务和数据库进行分离

📚️2.应用服务于数据库分离

具体的格式如下图所示：

那么在引用服务器中，要处理我们的业务数据，那么就会吃CPU和内存，所以可以对症下药；

在存储服务器中，我们就可以用硬盘进行数据的存储，这里我们可使用固态硬盘提高访问的速度；

将两者分离后，大大降低了单台服务器（主机）的压力；

📚️3.引入负载均衡

具体的图示如下：

假如单台应用服务器，承受不住压力，或者把CPU吃没了，那么就会崩溃；所以就引入了两个应用服务器；

但是，我们如何对于我们的来的情求进行合理的分配呢？那么就要引如负载均衡了；那么他就可以针对来的请求，进行处理，合理的进行分配~~~

负载均衡的负载能力很强，但是假如请求量大到负载均衡也处理不了，就可以引入多个，即多个机房

📚️4.数据读写分离

如下图所示：

其实如果请求过大，那么又由于数据库的访问速度比较慢，那么就可以将数据库进行分离，一个主数据库，一个从数据库；

主数据库主要负责写的操作，然后从数据库负责读的操作，并且写完后要同步到从数据库数据中；

注意：在大多数对于数据库的访问多是查询操作，写的操作比较少；并且这里遵守一主多从，通过负载均衡进行数据库的访问~~~

那么这样就可以减轻我们数据库的访问压力了；

📚️5.引入缓存

数据库有一个天然的缺点，即访问的速度慢；那么我们如何提高数据的访问速度呢？

那么就有一个很出名的定律：二八定律； 即百分之二十的数据可以满足百分之八十的数据访问；

那么我们就可引入缓存（特点速度更快，存在内存上，空间不大）

那么就正好可以存那百分之二十的数据，满足百分之八十访问需求；

如下所示：

其中我们把百分之二十的热点数据存储到缓存中，极大的提高的我们数据的访问速率；

但是这里要将我们的数据的缓存和我们的数据库进行同步~~~

📚️6.分库分表

如下所示：

假如越来越大的数据需要存储，那么就要更多的数据库来存储数据；

此时就可以针对某特定类的数据进行存储，称为数据库的集群~~~

并且如果某一个表非常大，就可以针对这个表来进行分表的操作~~~

📚️7.微服务架构

如下图所示：

即将我们上述的所有的分为几个板块，将我们的业务拆分，然后针对每个业务采用我们上述讲解的架构模式 ；

其实由于一个服务器的代码越来越多，那么我们将代码功能分为小块，简化了代码的复杂程度；

但是我们的微服务真的没有什么缺点吗？当然是存在缺点的~~

1、系统的性能下降（由于进程之间通信，所以拆分出来的多个服务需要依靠网络通信来进行数据的传输）网络传输的熟读比硬盘还慢 2、复杂度提高，可用性收到影响（服务器更多了，那么出现问题的概率增加）

BUT微服务也有好处：

第一：解决了人源问题，针对每个业务功能分配不同的人力资源

第二：使用微服务，方便了我们功能的复用；

第三：可以给不同的服务，进行不同的部署（假如一个核心功能，请求高，那么可以分配部署在一个性能更好的服务器上）

📚️8.总结

本期小编主要讲解了分布式微服务的发展来源，从单机架构到分布式，再到微服务，小编都进行了一一的讲解~~~