一.简单介绍:
Redis是用来在内存中 ,存储数据 的, 他的初心是用来搞'消息中间件 '(或者说消息队列 很熟悉了吧~~),但是呢用的不多,他现在主要是用来做数据库,缓存
用来存储数据, 为什么不直接存储呢? Redis的优势就在于'++分布式系统++'
二.分布式系统
要说其分布式系统,简单想想都能感觉到~分布开,说明应该不只有一个~~ 那我们从最底层的开始,如果只有一个系统的时候又是什么呢?为什么要搞出那么多的系统?难道复杂程度不会直线上升吗?
1)单机架构: ++只有一台主机,负责所有的工作++ 应用服务器(处理业务逻辑)->存储服务器(记录数据)
okk~~我们都知道,服务器处理请求的时候,每一次都要消耗一些资源,那资源太多了处理不过来了,怎么办?
两个办法~~i) 节流: 软件优化~性能测试,哪里不行优化哪里(有一定的技术要求)
ii)开源 -> 简单粗暴,哪里资源不够扩充哪里,当然这边必然有上限啊 --> 那一台扩展到极限了,我们就引入多台~~这个时候系统就叫'分布式系统'了
2)分布式系统 : 多台主机,负责工作(所以,复杂程度是上升的~)
这个时候,应用服务器和存储服务器也不在一台主机上了, 根据他们的业务逻辑不同,我们分别对应更好的硬件给他们,性价比更高
如果应用服务器承担不了请求, 我们就再扩充增加应用服务器,然后利用负载均衡给他们相对平均的分配任务
如果存储服务器承担不了数据, 我们就也增加, 搞出一个主数据库(专门用来写数据),之后让他把数据同步到从数据库(专门读取数据)就可以了~~~敲黑板:一主可多从
数据库的表很大怎么办? 我们这个时候可以进行分库分表呀~~就像一个大的项目,拆分成不同的小任务~
但是,数据库响应很慢,能不能解决一下?? 其实我们都知道~有一些高频的信息它能满足绝大部分需求,那我们将这些重点信息扔到缓存里,不就行了吗!(Redis在分布式系统中,就扮演缓存的角色~~ -> 其实有一个问题,数据库如果修改数据,缓存这里怎么及时修改)
有没有发现,其实这样扩充扩充,很复杂? 我们其实可以搞出微服务架构~拆分成更多,功能更单一,更小的服务器~~但是这件事是有利弊的
简单来说,当一台服务器不足以去处理请求,我们就引入多台->分布式系统, 什么不足就增添什么,对于数据存储的话,搞出来提高读取速度的缓存数据库,读写各肩其职的主从数据库,以及库表太大的分库分表操作