初始Redis之分布式

一.简单介绍:

        Redis是用来在内存中, 存储数据的, 他的初心是用来搞'消息中间件'(或者说消息队列 很熟悉了吧~~),但是呢用的不多,他现在主要是用来做 数据库,缓存

        用来存储数据, 为什么不直接存储呢?   Redis的优势就在于'分布式系统'

二.分布式系统

        要说其分布式系统,简单想想都能感觉到~分布开,说明应该不只有一个~~ 那我们从最底层的开始,如果只有一个系统的时候又是什么呢?为什么要搞出那么多的系统?难道复杂程度不会直线上升吗?

1)单机架构: 只有一台主机,负责所有的工作 应用服务器(处理业务逻辑)->存储服务器(记录数据)

        okk~~我们都知道,服务器处理请求的时候,每一次都要消耗一些资源,那资源太多了处理不过来了,怎么办?

        两个办法~~i) 节流: 软件优化~性能测试,哪里不行优化哪里(有一定的技术要求)

                          ii)开源 -> 简单粗暴,哪里资源不够扩充哪里,当然这边必然有上限啊 --> 那一台扩展到极限了,我们就引入多台~~这个时候系统就叫'分布式系统'了

2)分布式系统 : 多台主机,负责工作(所以,复杂程度是上升的~)

        这个时候,应用服务器和存储服务器也不在一台主机上了, 根据他们的业务逻辑不同,我们分别对应更好的硬件给他们,性价比更高

        如果应用服务器承担不了请求, 我们就再扩充增加应用服务器,然后利用负载均衡给他们相对平均的分配任务

        如果存储服务器承担不了数据, 我们就也增加, 搞出一个主数据库(专门用来写数据),之后让他把数据同步到从数据库(专门读取数据)就可以了~~~敲黑板:一主可多从

        数据库的表很大怎么办? 我们这个时候可以进行分库分表呀~~就像一个大的项目,拆分成不同的小任务~

        但是,数据库响应很慢,能不能解决一下?? 其实我们都知道~有一些高频的信息它能满足绝大部分需求,那我们将这些重点信息扔到缓存里,不就行了吗!(Redis在分布式系统中,就扮演缓存的角色~~ -> 其实有一个问题,数据库如果修改数据,缓存这里怎么及时修改)

        有没有发现,其实这样扩充扩充,很复杂? 我们其实可以搞出微服务架构~拆分成更多,功能更单一,更小的服务器~~但是这件事是有利弊的

简单来说,当一台服务器不足以去处理请求,我们就引入多台->分布式系统, 什么不足就增添什么,对于数据存储的话,搞出来提高读取速度的缓存数据库,读写各肩其职的主从数据库,以及库表太大的分库分表操作