初识Redis
- Redis
- 认识Redis
- 分布式系统
- 单机架构
- 为什么要引入分布式
- 理解负载均衡
- 数据库的读写分离
- 引入主从数据库
- 引入缓存
- 数据库分库分表
- 业务拆分——微服务
- 常见概念了解
- Redis背景介绍
- 特性
- 应用场景
- Redis不能做的事情
- Redis客户端
- redis客户端的多种形态
Redis
认识Redis
- 存储数据
- 在内存中
Redis是在分布式系统中,才能发挥威力,如果只是一个单机程序,直接通过变量存储数据的方式,是比Redis更优的选择。
Redis就是基于网络可以吧内存中的变量给别的进程,甚至别的主机的进程进行使用
Mysq和Redis
- Mysql最大的问题在于,访问速度比较慢(用硬盘存的),很多互联网产品中,对与性能要求很高
- Redis也可以作为数据库使用,速度快(用内存存的)
- 两个用到的功能和使用场景不一样
- Redis相对于MySql最大的劣势——存储空间是有限的,且Mysql提供的增删改查的功能更多
有没有一种方案可以 存储空间又大,速度又快的?——典型方案:可以吧Redis和Mysql结合起来使用
- 用Redis来作为Mysql的Cache
二八原则 :20%的热点数据,能满足80%的访问需求
代价——系统的复杂度大大提升,而且如果数据发生修改,还涉及到Redis和Mysq的数据同步问题
Redis的初心,最初是用来作为分布式系统下来作为一个“消息中间件”的(消息队列)分布式系统下的生产者消费者模型
当前很少会直接随时用Redis作为消息中间件(业界有更多更专业的消息中间件使用)
分布式系统
单机架构
只有一台服务器,这个服务器负责所有的工作
如果业务进一步增长,用户量和数据流都水涨船高,一台主机难以应付的时候,就需要引入更多的主机,引入更多的硬件资源——这个时候就要过渡到分布式系统中。
为什么要引入分布式
一台主机的硬件资源是有上限的(CPU,内存,硬盘,网络,...),服务器每次收到一个请求都需要小号上述的一些资源,如果同一时刻处理的请求多了,此时资源就不够用了,无论是哪一方面不够用了,都可能会导致服务器处理的请求时间变长,甚至处理出错
一旦引入多台主机了,咱们的系统就可以称为“分布式系统”
- 引入分布式,是万不得已的无奈之举,系统的复杂程度会大大提高,随之出现Bug的概率也回变高
– | – |
---|---|
应用服务器 | 存储服务器 |
里面可能会包括很多的有业务逻辑,可能会吃CPU和内存 | 需要更大的硬盘空间,更快的数据访问速度,可以配置更大硬盘的服务器,甚至可以上SSD硬盘(固态硬盘) 【机械硬盘,便宜,慢】【固态硬盘,贵,快】 |
应用服务器可能会比较吃CPU和内存,如果把CPU或者内存吃没了,此时应用服务器就扛不住了,这时候就要引入更多的应用服务器
理解负载均衡
负载均衡器,就相当于领导,给员工分配工作,减轻自己的负担
应用服务器,就相当于员工,执行领导的分配,分担领导的工作
(从上往下) | 负载均衡器 | (从上往下) |
---|---|---|
应用服务器 | 应用服务器 | 应用服务器 |
存储服务器 |
对于负载均衡器来说,有很多的 负载均衡 具体的算法比如轮询等,对于请求量的承担能力,要远超应用服务器
数据库的读写分离
当负载均衡器的负担增加后,可以增加应用服务器来处理请求量,但是随之存储服务器要承担的请求量也就增多了,这时候该怎么办呢?
引入主从数据库
实际的应用场景中,读的频率是比写的频率要高的!所以主服务一般是一个,只负责写,从数据库可以有多个,只负责写,同时从数据库通过负载均衡的方式,让应用服务器进行访问
引入缓存
数据库有个天然的问题,响应速度是更慢的,所以可以把数据区分“冷热”,热点数据放到缓存中~缓存的访问速度往往比数据库快很多。
20%的数据,能够支持80%的访问量
引入一个缓存服务器,而这个缓存服务器,也就是Redis的主要应用场景,而缓存想要快,就要付出代价,也就是存储空间小
数据库分库分表
引入分布式系统,不光要能够去应对更高的请求量(并发量),同时也要能够应对更大的数据量,这时候就会出现一台服务器空间不够用,存不下数据,需要多台主机来存储。
针对数据库进行进一步拆分: 分库分表
- 分库:本来一个数据库服务器,这个数据库服务器上有多个数据库(database),现在就可以引入多个数据库服务器,每个数据库服务器存储一个或者一部分数据库
- 分表:如果一个表特别大,大到一台主机存不下,也可以针对表进行拆分
- 具体分库分表如何实践?还是要结合实际的业务场景来展开
业务拆分——微服务
什么叫微服务—— 之前的应用服务器,一个服务器程序里面做了很多的业务,这就可能会导致一个服务器的代码变得越来越复杂,为了更方便于代码的维护,就可以把这样一个复杂的服务器,拆分成更多的,功能更单一,但是更小的服务器
微服务的本质是在解决“人”的问题,当应用服务器复杂了,势必就需要更多的人来维护,当人多了,就需要配套的管理,把这些人组织好,划分组织结构,分成多个组,就需要进行分工,按照功能,拆分微多组微服务,有利于上述人员组织结构的分配(大厂)
微服务的缺点:
- 系统的性能下降,网络通信的速度可能是比硬盘还慢的(现在又万兆网卡,读写速度已经超过硬盘读写)
- 系统复杂程度更高,可用性受到影响,服务器更多了,出现问题的概率也变大了,这就需要一系列的手段来保证系统的可用性
微服务的优势:
- 解决了人的问题
- 使用微服务,可以更方便于功能的复用
- 可以给不同的服务进行不同的部署
常见概念了解
- 应用/系统:一个应用,就是一个/组服务器程序
- 模块/组件:一个应用,里面有很多个功能,每个独立的功能,就可以称为是一个模块/组件
- 分布式:引入多个主机/服务器,协同配合完成一系列工作
- 集群:引入多个主机/服务器,协同完成一系列工作
- 中间件:和业务无关的服务(数据库,缓存,消息队列)
- 可用性:系统整体可用的时间/总的时间(360天/365天=>可用性)
Redis背景介绍
Redis的一些特性(优点)
Mysq主要是通过“表”的方式来存储组织数据的,“关系型数据库”
Redis主要是通过“键值对”的方式来存储组织数据的,“非关系型数据库”
特性
- 在内存中存储数据
- 针对Redis的操作,可以直接通过简单的交互式命令进行操作,也可以通过一些脚本的方式,批量执行一些操作(可以带有一些逻辑)
- 可以在Redis原有的功能的基础上再进行扩展,Redis提供了一组API ,可以支持(c,c++,rust等语言)拓展
- 持久化:Redis把数据存储在内存上和硬盘上,以内存为主,硬盘为辅(硬盘相当于对内存的数据备份了一下),如果Redis重启了,就会在重启时加载硬盘中的备份数据使Redis的内存恢复到重启前的状态
- 集群:Redis能存储的数据是有限的(内存空间有限),引入多个主机,部署多个Redis节点,每个Redis存储数据的一部分
- 高可用:=> 冗余/备份 ————Redis自身支持“主从”结构,从节点相当于主节点的备份
- 速度快:为什么快?1. Redis数据在内存中,就比访问硬盘的数据库,快很多 2. Redis核心功能都是比较简单的逻辑 3.从网络角度上,Redis使用了多路复用的方式(epoll) 4. Redis使用的是单线程模型,减少了不必要额度线程之间的进程开销 5.Redis是使用C语言开发的,所以就快(? 同样是数据库,Mysql也是C语言开发的)
多线程提高效率的前提是,CPU密集型的任务,使用多个线程可以充分利用CPU多核资源
但是Redis的核心任务,主要就是操作内存的数据结构,不会吃很多CPU
应用场景
- 当做数据库(对访问速度要求快,实时性高),如搜索引擎->广告搜索(商业搜索)
- 作为缓存——>Redis存储部分数据,全量数据以Mysql为主,哪怕Redis数据没了,还可以从mysql这边再加载回来
- 会话
- 消息队列(服务器)(不是Linux进程间通信的那个消队列)——>基于这个可以实现以一个网络版本的生产者消费者模型;如果当前场景中,对于消息队列的功能依赖的不是很多,并且又不想引入额外的依赖了,Redis可以作为一个选择。
Redis不能做的事情
- 存储大规模数据
Redis客户端
首先,要知道Redis也是一个客户端-服务器结构的程序(Mysql)
客户端和服务器((本体)负责存储和管理数据)之间,通过网络通信,可以在同一个主机上,也可以在不同主机上。
redis客户端的多种形态
- 自带了命令行客户端 redis-cli
redis -cli
或者
redis -cli -h 127.0.0.1 -p 6379
- 图形化界面的客户端(桌面程序,web程序)
- 基于Redis的API自行开发客户端【工作中的主要形态】
非常类似于mysql的C语言API和JDBC