1.Redis之初识Redis分布式系统

1.初识Redis

1.1 官网

Redis中文网

Redis 教程 | 菜鸟教程 (runoob.com)

1.2 解释

在内存中存储数据

定义变量,不就是在内存中存储数据嘛??

Redis 是在分布式系统（进程的隔离性：Redis 就是基于网络，可以把自己内存中的变量给别的进程甚至别的主机的进程进行使用。）中,才能发挥威力的~~

如果只是单机程序,直接通过变量存储数据的方式是比使用 Redis 更优的选择

Redis 就是基于网络可以把自己内存中的变量给别的进程甚至别的主机的进程进行使用.

1.3 用途

可用作数据库，高速缓存和消息队列代理（Redis的初心：最初就是用来作为一个"消息中间件"的(消息队列)分布式系统下的生产者消费者模型，但现在很少用）

1.数据库

优势：Redis速度快，因为Redis在内存中存储，而Mysql在硬盘中存储。

劣势：存储空间有限

• 如何做到又大又快？？？
• Redis和Mysql结合起来->(会导致系统的复杂程度大大提升)

2.分布式系统 

单机架构,只有一台服务器,这个服务器负责所有的工作。

如果业务进一步增长,用户量和数据量都水涨船高,,一台主机难以应付的时候,就需要引入更多的主机, 引入更多的硬件资源~~ 

• 为什么难以应付？？？

一台主机的硬件资源是有上限的!!! 

包括不限于以下几种:
1. CPU
2.内存
3.硬盘
4. 网络
5......

服务器每次收到一个请求,都是需要消耗上述的一些资源的~~
如果同一时刻,处理的请求多了,此时就可能会导致某个硬件资源不够用了!!!
无论是哪个方面不够用了,都可能会导致服务器处理请求的时间变长~甚至于处理出错~~

• 如果我们真的遇到了这样的服务器不够用的场景,怎么处理呢?

1.开源
简单粗暴,增加更多的硬件资源~

一个主机上面能增加的硬件资源也是有限的，取决于主板的扩展能力~~
2.节流-软件上优化.

(各凭本事了,需要通过性能测试,找到是哪个环节出现了瓶颈,再去对症下药)

->一台主机扩展到极限了，但是还不够~~就只能引入多台主机了!!!

->不是说新的机器买来就直接可以解决问题了.也需要软件上做出对应的调整和适配~~

->一旦引入多台主机了,咱们的系统就可以称为是"分布式系统"

引入分布式,这是万不得已~~无奈之举~~系统的复杂程度会大大提高~~出现 bug 的概率越高

• 应用服务（第一个服务器）和数据库服务（第二个服务器）分离 

 

• 引入更多的应用服务器节点

负载均衡器:公平公正的“平均分配”（涉及很多的算法）

• 负载均衡器,看起来不是承担了所有的请求嘛?这个东西能顶住嘛??

负载均衡器,对于请求量的承担能力,要远超过应用服务器的.
负载均衡器,是领导, 分配工作,
应用服务器,是组员,执行任务

引入更多机器->请求量太大

• 是否可能会出现,请求量大到负载均衡器也扛不住了呢??

也是有可能的!!!引入更多的负载均衡器~~(引入多个机房)

当机器变多了,管理成本也会提高~~ 出现问题的概率也会提高

• 如上面讨论,增加应用服务器,确实能够处理更高的请求量但是随之存储服务器,要承担的请求量也就更多了!!!咋办?

主要进行开源

开源（引入更多的机器）+节流(门槛高, 更复杂)
引入更多的机器->读写分离~

主服务器一般是一个.

从服务器可以有多个~~(一主多从)
同时从数据库通过负载均衡的方式,让应用服务器进行访问~~

数据冷热区分->响应速度慢

数据库天然有个问题,响应速度是更慢的!!

• 如何解决？？？

把数据区分"冷热"，热点数据放到缓存中~缓存的访问速度往往比数据库要快很多了!!

要想得到一个效果,就要付出一定的代价~~~
欲戴其冠,必承其重!!!

分库分表->存储空间不足 

• 引入分布式系统,不光要能够去应对更高的请求量(并发量),同时也要能应对更大的数据量~~是否可能会出现,一台服务器已经存不下数据了呢??

当然会存在!!!短视频~~虽然一个服务器,存储的数据量可以达到 几十个 TB,即使如此也可能会存不下~~台主机存不下,就需要多台主机来存储~~ 

微服务架构-解决人的问题

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

(微服务)->服务器的种类和数量就增加了~~

【注意】微服务本质上是在解决"人"的问题~~（大厂才会考虑此情形）

当应用服务器复杂了~~势必就需要更多的人来维护了~~当人多了,就需要配套的管理,把这些人组织好~~
划分组织结构,分成多个组,每个组分别配备领导进行管理~~（分成多个组,就需要进行分工~~）

按照功能,拆分成多组微服务,就可以有利于上述 人员的组织结构的分配了~~

• 引入微服务,解决了人的问题,付出的代价?

1.系统的性能下降~~(要想保证性能不下降太多,只能引入更多的机器,更多的硬件资源 =>充钱~~)

拆出来更多的服务,多个功能之间要更依赖

网络通信网络通信的速度很可能是比硬盘还慢的!!!

幸运的是,硬件技术的发展,网卡现在有 万兆 网卡【贵】,读写速度已经能过超过硬盘读写了~~

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

微服务的优势

1.解决了人的问题.
2.使用微服务,可以更方便于功能的复用
3.可以给不同的服务进行不同的部署~~

2.1 基本概念

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

一个应用,就是一个/组 服务器程序

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

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

• 分布式(Distributed)

物理上的多个主机引入多个主机/服务器, 协同配合完成一系列的工作.

• 集群(Cluster)

逻辑上的多个主机,引入多个主机/服务器,协同配合完成一系列的工作.

• 主(Master)/从(Slave)

分布式系统中一种比较典型的结构~~
多个服务器节点,其中一个是主,另外的是从,从节点的数据要从主节点这里同步过来~~

• 中间件(Middleware)

和业务无关的服务(功能更通用的服务)
1.数据库
2. 缓存
3. 消息队列

• 中间件(Middleware)

和业务无关的服务(功能更通用的服务)
1.数据库
2.缓存
3. 消息队列

• 可用性(Availability)（最核心）

系统整体可用的时间/总的时间
一个系统的第一要务.
360/365 =>可用性~~
4个9即系统可以提供99.99%的可用性，5个9是99.999%

• 响应时长(Response Time RT)

衡量服务器的性能
和具体服务器要做的业务密切相关的~~
越小越好~~

• 吞吐(Throughput)ys并发(Concurrent)

衡量系统的处理请求的能力.衡量性能的一种方式

 

3.分布式系统小节

1.单机架构 (应用程序 +数据库服务器)

2.数据库和应用分离
应用程序和数据库服务器 分别放到不同主机上部署了

3.引入负载均衡, 应用服务器 =>集群
通过负载均衡器,把请求比较均匀的分发给集群中的每个应用服务器.【当集群中的某个主机挂了,其他的主机仍然可以承担服务~~提高了整个系统的可用性~-】

4.引入读写分离,数据库主从结构
一个数据库节点作为主节点,其他N个数据库节点作为从节点,
主节点负责 写 数据. 从节点负责 读 数据.
主节点需要把修改过的数据同步给从节点~二八原则【Redis 在一个分布式系统中,通常就扮演着缓存这样的角色~.引入的问题: 数据库和缓存的数据一致性问题~~】

5.引入缓存, 冷热数据分离
进一步的提升了服务器针对请求的处理能力.

6.引入分库分表,数据库能够进一步扩展存储空间

7.引入微服务,从业务上进一步拆分应用服务器~~~从业务功能的角度,把应用服务器,拆分成更多的功能更单一,更简单, 更小的服务器.

上述这样的几个演化的步骤,只是一个粗略的过程.实际上一个商业项目，真实的演化过程,都是和他的业务发展密切相关的,业务是更重要的,技术只是给业务提供支持的
所谓的 分布式 系统, 就是想办法引入更多的硬件资源!