初始Redis && 分布式结构的发展演变

目录

Redis的特点和使用场景

分布式系统的引入

单机系统

分布式系统 

应用服务器的增多（处理更多的请求）

数据库读写分离（数据服务器的增多)

引入缓存

应对更大的数据量 

业务拆分：微服务

---

Redis的特点和使用场景

我们先来回顾下我们之前学过的MySQL

mysql的数据是存储到硬盘上的，他的读取速度比较慢，但是容量大

而Redis则是使用了内存，数据是在内存上，读取速度比较快，但是容量小。

这里补充一点：

我们一开始学习编程，所了解的变量是存储找内存中。那么既然都是存储到内存中，我们干嘛还要弄一个Redis呢？

是这样的——Redis主要是用在分布式系统上的，他可以实现各个进程间数据的通讯，共享，甚至不同主机上的进程间数据的互相访问 

分布式系统的引入

单机系统

下面是一个单机架构，只有一台服务器，这个服务器负责处理所有的事情

我们之前写的java--web类项目，属于是HTTP服务器（处理前端发来的请求）

对与数据来说

我们上面所说的web程序，springboot属于是HTTP服务器（属于Mysql的客户端）, 向Mysql服务器发生请求（查询数据）

而MySQL是一个客户端服务器结构的程序，是作为数据的服务器，他的本体就是Mysql服务器（用来存储和组织数据）

分布式系统 

虽然对于现在的计算机硬件来说，哪怕只有一台主机，这一台主机也是可以支持非常高的并发 & 非常大的数据存储。

但是如果业务进一步增长，用户量和数据量继续增多，当一台主机难以应付的时候，就需要引入更多的主机，引入更多的硬件资源

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

上面就是一个最简单的分布式的结构——应用服务和数据库服务分离 

应用服务器的增多（处理更多的请求）

但是因为应用服务器可能会比较吃CPU和内存。

比如要同时要处理的应用请求过多，把CPU和内存给吃没了，就会出现相应的问题

这个时候，我们就需要引入更多的应用服务器，来解决上述问题

这里的应用服务器，可能是两个，也可能是多个。用户的请求先到达负载均衡器/网关服务器，将任务分配给下面的多个应用服务器

这里我们介绍下负载均衡器

负载均衡器的请求承受能力，大大高于应用服务器。（负载均衡服务器主要用于任务的分配，分配任务一般不会消耗太多的资源，任务的执行——也就是应用服务器消耗的资源会多一些）

当然如果系统的请求实在太多，负载均衡器的压力也过大的时候，我们这里可以引入更多的负载均衡服务器来承受这增多的访问量

这里需要注意的是，当我们的服务器增多了后，管理成本也会变高，系统也变得越来越复杂，出现问题的概率也随之提升 

数据库读写分离（数据服务器的增多)

这里面有一个主从结构

在实际应用场景中，读的频率是比写的频率要高的 

那么我们就可以有多个从服务器——一主多从

引入缓存

数据库天然有一个问题，相应速度是相对更慢的

为了解决这个问题，我们可以把数据区分 ”冷热“， 热点数据（使用频繁的数据）放到缓存中，缓存的访问速度往往要比数据库要快很多！！！

 

我们的redis主要就是应用在缓存中，虽然存的数据少，但速度快（存的也都是热点数据）

另外因为二八原则， 缓存服务器中的热点数据可以应对80%以上的请求。因此缓存服务器的使用，不仅提高了访问速度，还缓解了其他数据服务器的压力。

 虽然引入缓存这样的好处，但同时也会带来一些问题，比如数据一致性（数据同步）问题。

应对更大的数据量 

我们上面不管是引入更多的应用服务器，还是数据库读写分离、引入缓存，都是为了应对更高的请求量。但是对于一个完善的系统来说我们不光要能够去应对更高的请求量，也还要能够应对更大的数据量

业务拆分：微服务

随着⼈员增加，业务发展，我们将业务分给不同的开发团队去维护，每个团队独⽴实现⾃⼰的微服务，然后互相之间对数据的直接访问进⾏隔离，可以利⽤Gateway、消息总线等技术，实现相互之间的调⽤关联。甚⾄可以把⼀些类似⽤⼾管理、安全管理、数据采集等业务提成公共服务