【Redis】从单机架构到分布式，回溯架构的成长设计美学
前言
🌟🌟本期讲解关于分布式架构的发展相关知识介绍~~~
🌈感兴趣的小伙伴看一看小编主页：GGBondlctrl-CSDN博客
🔥 你的点赞就是小编不断更新的最大动力
🎆那么废话不多说直接开整吧~~
目录
📚️1.单机架构
📚️2.应用服务于数据库分离
📚️3.引入负载均衡
📚️4.数据读写分离
📚️5.引入缓存
📚️6.分库分表
📚️7.微服务架构
📚️8.总结
📚️1.单机架构
所谓的单机架构，其实就是一台服务器完成所有的工作，包括业务处理，数据库数据存储等等
大致如下所示：
应用服务主要负责我们业务处理，而数据库主要负责存储数据，那么这就是一个比较基础的单体架构；
那么单体架构已经被淘汰了吗？
1、当然没有，随着计算机的快速的发展，硬件以发展非常快，那么一台主机就能够处理极高的并发，以及存储大量的数据；
2、并且单体架构对于分布式来说，系统的复杂程度大大下降，方便开发；
但是日益增长的请求和访问量，单体架构无法胜任，（硬件资源是有上限的，包括CPU，硬盘，带宽，内存......）那么就有两种解决方式
1、开源：引入更多的硬件资源
2、节流：在软件层面，对于代码进行性能的提高，但是比较困难
所以引入下面的应用服务和数据库进行分离
📚️2.应用服务于数据库分离
具体的格式如下图所示：
那么在引用服务器中，要处理我们的业务数据，那么就会吃CPU和内存，所以可以对症下药；
在存储服务器中，我们就可以用硬盘进行数据的存储，这里我们可使用固态硬盘提高访问的速度；
将两者分离后，大大降低了单台服务器（主机）的压力；
📚️3.引入负载均衡
具体的图示如下：
假如单台应用服务器，承受不住压力，或者把CPU吃没了，那么就会崩溃；所以就引入了两个应用服务器；
但是，我们如何对于我们的来的情求进行合理的分配呢？那么就要引如负载均衡了；那么他就可以针对来的请求，进行处理，合理的进行分配~~~
负载均衡的负载能力很强，但是假如请求量大到负载均衡也处理不了，就可以引入多个，即多个机房
📚️4.数据读写分离
如下图所示：
其实如果请求过大，那么又由于数据库的访问速度比较慢，那么就可以将数据库进行分离，一个主数据库，一个从数据库；
主数据库主要负责写的操作，然后从数据库负责读的操作，并且写完后要同步到从数据库数据中；
注意：在大多数对于数据库的访问多是查询操作，写的操作比较少；并且这里遵守一主多从，通过负载均衡进行数据库的访问~~~
那么这样就可以减轻我们数据库的访问压力了；
📚️5.引入缓存
数据库有一个天然的缺点，即访问的速度慢；那么我们如何提高数据的访问速度呢？
那么就有一个很出名的定律：二八定律；
即百分之二十的数据可以满足百分之八十的数据访问；
那么我们就可引入缓存（特点速度更快，存在内存上，空间不大）
那么就正好可以存那百分之二十的数据，满足百分之八十访问需求；
如下所示：
其中我们把百分之二十的热点数据存储到缓存中，极大的提高的我们数据的访问速率；
但是这里要将我们的数据的缓存和我们的数据库进行同步~~~
📚️6.分库分表
如下所示：
假如越来越大的数据需要存储，那么就要更多的数据库来存储数据；
此时就可以针对某特定类的数据进行存储，称为数据库的集群~~~
并且如果某一个表非常大，就可以针对这个表来进行分表的操作~~~
📚️7.微服务架构
如下图所示：
即将我们上述的所有的分为几个板块，将我们的业务拆分，然后针对每个业务采用我们上述讲解的架构模式 ；
其实由于一个服务器的代码越来越多，那么我们将代码功能分为小块，简化了代码的复杂程度；
但是我们的微服务真的没有什么缺点吗？当然是存在缺点的~~
1、系统的性能下降（由于进程之间通信，所以拆分出来的多个服务需要依靠网络通信来进行数据的传输）网络传输的熟读比硬盘还慢
2、复杂度提高，可用性收到影响（服务器更多了，那么出现问题的概率增加）
BUT微服务也有好处：
第一：解决了人源问题，针对每个业务功能分配不同的人力资源
第二：使用微服务，方便了我们功能的复用；
第三：可以给不同的服务，进行不同的部署（假如一个核心功能，请求高，那么可以分配部署在一个性能更好的服务器上）
📚️8.总结
本期小编主要讲解了分布式微服务的发展来源，从单机架构到分布式，再到微服务，小编都进行了一一的讲解~~~
🌅🌅🌅~~~~最后希望与诸君共勉，共同进步！！！
💪💪💪以上就是本期内容了， 感兴趣的话，就关注小编吧。
😊😊 期待你的关注~~~