Redis --- 第一讲 --- 分布式简单介绍

最新推荐文章于 2024-09-27 21:26:22 发布

ljp_nan

最新推荐文章于 2024-09-27 21:26:22 发布

阅读量602

点赞数 11

分类专栏： Redis 文章标签： redis 数据库缓存

本文链接：https://blog.csdn.net/m0_67635008/article/details/142594890

版权

Redis 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

一、认识Redis

定义变量，不就是在内存中存储数据吗？Redis是在分布式系统中，才能发挥威力的。如果只是单机程序。直接通过变量存储数据的方式势必使用Redis更优的选择。由于进程的的隔离性。进程之间通过网络通信，就能共享数据。Redis就是基于网络，可以把自己内存中的变量给别的进程甚至别的主机的进程进行使用。

数据库：MySQL最大的问题在于访问的速度比较慢。很多互联网产品中，对于性能要求是很高的。Redis也可以作为数据库使用，它的特点是非常快。定性的角度，可以知道Redis快很多，但是很难定量衡量。和MySQL相比，最大的劣势，存储空间时有限的。虽然有不少的互联网产品，对于性能要求比较高得，更多的互连网产品对于性能要求没那么高的要求。我们可以把Redis和MySQL结合起来使用。二八原则。但是这种做法使系统的复杂程度大大提升了。而且如果数据发生修改。还涉及到Redis和MySQL之间的数据同步问题。

Redis的初心，最初就是用来作为一个消息中间件（消息队列）的分布式系统下的生产者消费者模型。当前很少会直接使用Redis作为消息中间件的使用，因为业界有很多更专业的消息中间件的使用。

分布式是Redis谈论的重点。

二、分布式系统

单机架构，只有一台服务器，这个服务器负责所有的工作。绝大部分公司的产品都是这种单机架构。哪怕只有一台主机，这一台主机的性能也是很高的。如果业务进一步增长，用户量和数据量都水涨船高，一台主机难以应付的时候，就需要引入更多的主机。

一台主机的硬件资源是有上限的。包括不限于一下几种：CPU，内存，硬盘，网络。服务每次收到一个请求，都是需要消耗上述的一些资源的。如果同一时刻处理的请求多了，此时就导致某个硬件资源不够用了。无论是哪个方面不够用了都可能会导致服务器处理请求的事件变长。甚至处理出错。

如果我们遇到了服务器资源不够用的场景，采用开源，节流。软件上的优化，对于程序员的水平要求就比较高了。开源，简单粗暴，增加更多的硬件资源。一个主机上面能增加的硬件资源也是有限的。一台主机扩展到极限了，但是还不够，就只能引入多台主机了。不是说新的机器买来就直接可以解决问题了也需要提出对应的调整和适配。一旦引入了多台主机了，咱们的系统就可以称为是分布式系统，引入分布式这是万不得已的，系统的复杂程度会大大提高。

应用服务和数据库服务分离

请求又增加了，我们的应用服务器又扛不住了，所以我们可以引入更多的应用服务器

假设有1w个用户请求，有2个应用服务器，此时按照负载均衡的方式，就可以让每个应用服务器承担5K的访问量。用户的请求先到达负载均衡器这里，会有很多的具体的算法。比如轮询。

负载衡器，对于请求量的承担能力，要远超过应用服务器。但是也有可能请求量达到负载均衡器也扛不住了，也是有可能的。引入更多的负载均衡器。

如上面讨论，增加应用服务器，确实能够处理更高的请求量。但是随之存储服务器，要承担的请求量也就更多了。开源方法，数据库读写分离

实际的应用场景中，读的频率是比写要高的。主服务器是一个写服务器，从服务器可以有多个也就是读服务器。同时从数据库通过负载均衡的方式，让应用服务器进行访问。

数据库天然有个问题，响应速度是更慢的。把数据区分冷热，热点数据放到缓存中，缓存的访问速度往往比数据库要快很多了。

缓存里面只是放一小部分热点数据，会频繁被访问的数据就是热点数据。20%的数据，能够支持80%的访问量。实际场景的不同会达到一九原则。数据库中存储的仍然是完整的全量数据。

缓存要想快，就要付出代价 =》小！Redis就是作为一个缓存服务器的。缓存服务器帮助数据库服务器负重前行。要想得到一个效果，就要付出一定的代价。

引入分布式系统，不光要能够去应对更高的请求量（并发量），同时也能应对更大的数据量。是否可能会出现一台服务器已经存不下数据了当然会存在！！虽然一个服务器存储的数据量可以达到几十个TB，即使如此也可能会存不下。如果存储短视频呢。一台主机存不下，就需要多态主机来存储。

针对数据库进行进一步的拆分，分库分表。本来一个数据库服务器，这个数据库服务器上有多个数据库（指的是逻辑上的数据集合，create database创建的数据库）现在就可以引入多个数据库服务器，每个数据库服务器存储一个或者一部分数据库。如果某个表特别大，大到一台主机存不下，也可以针对表进行拆分。

具体分库分表如何实践，还是要结合实际场景来展开，业务至关重要。技术只是给业务提供支持的。业务决定了技术。

引入微服务架构

之前应用服务器，一个服务器程序里面做了很多的业务这就可能会导致这一个服务器的代码变得越来越复杂，为了更方便于代码得维护，就可以把这样的一个复杂的服务器，拆分成更多的，功能单一的，但是更小的服务器。这个更小的服务器就是微服务。服务器的种类和数量就增加了。注意服务器本质上是在解决人的问题。当应用服务器复杂了势必就需要更多的人来维护了，当人多了，就需要配套的管理把这些人组织好，划分组织结构，分成多个组，每个组分别配套对应的领导进行管理。分成多个组，就需要进行分工，按照功能，拆分成多组微服务，就可以有利于上述人员的组织结构的分配了。引入微服务，解决了人的问题，付出的代价是

1、系统的性能下降，要想保证性能不下降太多。只能引入更多的机器，更多的硬件资源。

拆出来更多的服务，多个功能之间要更依赖，网络通信，网络通信的速度很可能是比硬盘还慢的！

2、系统复杂度程度更高，可用性受到影响

服务器更多了，出现问题的概率就更大了，这就需要一系列的手段，来保证系统的可用性。更丰富的监控报警，以及配套的运维人员。

微服务的优势：

1、解决了人的问题

2、使用微服务，可以更方便功能的复用

3、可以给不同的服务进行不同的部署。

但是微服务并不是终点。