1. Redis 相关背景

Hello , 大家好 , 这个专栏给大家带来的是 Redis 系列 !

本专栏旨在为初学者提供一个全面的 Redis 学习路径，从基础概念到实际应用，帮助读者快速掌握 Redis 的使用和管理技巧。通过本专栏的学习，能够构建坚实的 Redis 知识基础，并能够在实际学习以及工作中灵活运用 Redis 解决问题 .
专栏地址 : https://blog.csdn.net/m0_53117341/category_12768559.html

一 . 初识 Redis

在 Redis 官网中 , 就给我们介绍了 Redis 的用途 :

Redis 官网 : https://redis.io/

我们可以分析一下 :

1. 开源的
2. 在内存中进行数据存储

那在内存中进行数据存储 , 我们定义变量不就可以了 , 为什么还需要引入一个额外的 Redis 呢 ?

因为 Redis 是需要在分布式系统中 , 才能发挥他最大的威力的 .

如果只是单机程序 , 那定义变量存储数据是没问题的 .

如果是分布式系统 , 那由于我们进程之间是存在隔离性的 , 所以通过一个变量存储数据是做不到分布式的 , 但是如果我们进程之间还需要进行通信的话 , 我们就需要采取网络的形式把自己内存中的变量交给别的进程来去使用 , 那就需要 Redis 来进行数据交互 .

3. 可以用于数据库

与 MySQL 相比 , Redis 最大的特点就是快 ! 很多互联网产品中 , 对于性能要求很高 .

但是 Redis 的缺点就是存储空间有限 .

虽然有不少的互联网产品对于性能要求比较高 , 但是也有很多的互联网产品对于性能是要求没有那么高的 , 所以普通情况下大家还是会选择使用 MySQL 来存储数据的 .

4. 可以用于缓存

把 Redis 和 MySQL 结合起来使用 , 将一些热点数据放到 Redis 中 , 这样就实现了又快、占用空间又小的特点 .

但是这样系统的复杂程度大大提升 , 而且如果数据发生修改 , 那就涉及到 Redis 和 MySQL 之间数据的同步问题

5. 可以当做消息队列

Redis 实现的初衷是用来作为一个 “消息中间件” , 想要实现在分布式系统下的生产者-消费者模型 .
但是无心插花柳成荫 , 后来大家觉得 Redis 作为数据库或者缓存会更香 .

二 . 浅谈分布式系统

2.1 单机架构

单机架构 , 表示只有一台服务器 , 这个服务器负责所有的工作

那一台服务器 , 至少会有两个部分 :

1. 应用服务 : 比如 Spring MVC , 就是一个 HTTP 服务器来去支撑业务的
2. 数据库服务 : MySQL …

我们之前也介绍过 , MySQL 是一个客户端-服务器结构的程序 , 他的本体就是 MySQL 服务器 (存储和组织数据的部分) , 那他的客户端就相当于应用服务 (类似 HTTP 服务器)

那在单机程序中 , 能不能把数据库服务去掉 , 就依靠应用服务既负责业务又负责数据

也不是不可以 , 就是实现起来会比较麻烦 , 我们可以将需要保存的数据保存到内存中

那绝大部分公司的产品 , 基本都是单体架构 , 因为现在的计算机硬件性能已经很强了 , 已经足以能够应付我们的基本的业务需求了 .

2.2 分布式

如果业务进一步增长 , 那用户量和数据量都会水涨船高 , 一台主机难以应付的时候 , 就需要引入更多的主机以及硬件资源的 .
那一台主机的硬件资源是有上限的 , 通常都会消耗这几种资源 :

1. CPU
2. 内存
3. 硬盘
4. 网络
5. …

那服务器每收到一个请求 , 就需要消耗上面的资源 .
如果同一时刻处理的请求多了 , 就可能导致某个资源不够用了 , 那就会导致服务器处理请求的时间变长甚至出错
那如果我们真的遇到了服务器资源不够用的情况 , 一般情况下有两种策略 :

1. 开源 : 增加更多的硬件资源 (堆料) . 但是一个主机上面能够增加的硬件资源也是有限的 , 我们就只能引入多台主机 , 那此时咱们的系统就变成了分布式系统
2. 节流 : 从软件上优化 , 需要通过性能测试找到哪个环节出现了性能瓶颈然后进行优化 , 一般来说通过性能优化来找出系统瓶颈并且进行优化是比较难的 , 所以一般都会采取开源策略

2.3 服务分离和负载策略

我们可以在单机架构的基础上 , 将应用服务和数据库服务区分开 , 那这样的话就是一个最简单的分布式

那应用服务器里面可能会包含很多业务逻辑 , 可能会吃 CPU 和内存
那数据库服务器里面可能会存储大量数据 , 那就需要更大的硬盘空间和更快的访问速度 , 所以可以配置更大硬盘的服务器 , 或者可以去使用 SSD 硬盘 (固态硬盘) .
这样针对不同的服务器去配置不同的参数 , 达到最佳的性价比 .

随着请求数进一步增加 , 应用服务器可能会比较吃 CPU 和内存 , 那如果把 CPU 或者内存吃没了 , 此时应用服务器就顶不住了 , 那我们采取的策略就是引用更多的应用服务器节点 , 这就是集群架构

对于负载均衡器来说 , 有很多负载均衡具体的算法 , 其中最简单粗暴的做法就是 : 轮训
如果集群中某个主机挂了 , 其他的主机仍然可以承担服务 , 也就提高了系统的可用性

那我们刚才介绍了 , 负载均衡器分散了多个请求到不同的应用服务器中 , 但是我们思考一个问题 : 负载均衡器看起来承担了所有的请求 , 那他能顶住吗 ?
负载均衡器对于大量请求的承担能力 , 要远超过应用服务器的 , 而且负载均衡器一般只是用来转发请求的 , 他并不会进行数据的处理 , 所以对于负载均衡器来说压力并不算太大 ; 对于数据的处理 , 主要就交给了应用服务器
那也有可能请求量大到负载均衡器也扛不住了 , 那我们只需要引入更多的负载均衡器 (可以理解为引入多个机房) 即可

2.4 数据库读写分离

我们上面的架构 , 只是将应用服务器进行了分布式 , 但是我们的数据库并未进行分布式部署
虽然增加了应用服务器 , 确实能够处理更高的请求量 , 但是数据库对应的压力也增大了 .
那我们的策略依然是 “开源+节流 (门槛高 更复杂)” , 相比之下 , 开源的思路更加简单粗暴 , 我们也是只需要引入多台机器即可

那我们就将存储服务器也分成两种 , 一种主要用作写 , 一种主要用作读
其中我们让主数据库就负责写 , 让从数据库负责读 , 那从数据库会定期的读取主数据库的数据
这样的话读写分离 , 数据库的压力也就降低了 , 一般情况下主服务器一般是一个 , 从服务器可以有多个 (一主多从) , 同时从数据库也会通过负载均衡的方式让应用服务器来进行访问
那其实在实际的应用场景中 , 读的频率是比写要高的 , 所以我们采用一主多从而不是多主一从的策略

2.5 引入缓存

虽然我们将数据库分成主数据库、从数据库 , 主数据库负责写数据 , 从数据库负责读数据 , 并且从数据库定期的会同步主数据库里面的数据 , 但是这里面还是会存在问题 : 数据库的响应速度一般都会很慢 , 在高并发的情况下还是会成为问题 .
那我们解决的策略就是将数据分为冷热两种情况 , 把热点数据放到缓存中 , 那缓存的访问速度会比数据库快很多

那我们从图片里可以看到 : 我们把一小部分热点数据放到缓存中 , 然后其他的数据正常保存到数据库中

这一小部分热点数据依然正常保存到数据库中 , 不是说保存到缓存中就不保存到数据库中了

那因为热点数据会被频繁的访问 , 所以我们就把他从数据库中保存到缓存中一份 , 这样就会大大加快了访问的速度
所以一般情况下 , 我们查询数据 , 会先去缓存中查询数据 , 缓存中没有再去从数据库中查询 , 那这样做的优点是读取的速度快 , 而且数据库的压力也比较小 .
那我们 Redis 一般就作为缓存来去使用的 .

2.6 数据库的分库分表

那我们引入分布式系统 , 不光要能够应对更高的请求量 (并发量) , 同时也要去应对更大的数据量
那就有可能会出现一台服务器已经存不下数据了 , 所以就需要多台主机来存储

那我们本来一个数据库服务器 , 然后这个数据库服务器上有多个数据库 .
现在就可以引入多个数据库服务器 , 那每个数据库服务器只需要存储一部分数据 .

那如果某个数据库中的某个表特别大 , 那我们也可以针对表进行拆分

2.7 引入微服务

我们在实际工作中 , 对于应用服务器还有进一步的拆分 , 比如我们的应用服务器做的工作太复杂了 , 那我们就需要将应用服务器拆分成很多部分 , 每一部分只负责一小部分的工作内容 , 这就是微服务
具体来讲 , 之前的应用服务器中 , 一个服务器程序里面做了很多的业务 , 这就可能会导致这一个服务器的代码变的越来越复杂 . 那为了更方便代码的维护 , 就可以把一个复杂的服务器拆分成更多的、功能更单一的、更小的服务器

那我们最刚开始引入负载均衡 , 是为了解决请求量过高的问题
引入数据库的分库分表是为了解决数据量太大的问题
那我们微服务要解决的问题 , 本质上是在解决 “人的问题” .

当我们的应用服务器变得复杂了 , 就需要更多的人来去维护 , 那也就需要配套的管理把这些人组织好 . 就需要划分组织结构 , 每组分别分配领导进行管理 .

那我们就按照功能 , 拆分成多组微服务 , 优点如下 :

1. 有利于程序组织结构的分配了
2. 有利于复用代码
3. 微服务比较灵活 , 我们还可以给不同的服务进行不同的部署

耗费资源不多的服务 , 那就可以少堆点料

那引入了微服务 , 就肯定会有缺点

1. 系统的性能下降 : 拆出来更多的服务 , 那多个功能之间要依赖网络通信 【解决 : 引入更多的硬件资源】
2. 系统复杂性提高 , 可用性降低

2.8 其他概念

应用 / 系统 : 一般就是一个服务器程序
模块 / 组件 : 针对系统再做细分 , 一个应用里面有很多功能 , 每个独立的功能就是一个模块 / 组件
分布式 : 引入多个主机协同完成一系列工作 , 一般考虑的是物理上的多个主机 (一堆真正的电脑)
集群 : 与分布式类似 , 只不过是逻辑上的概念 (意想的一堆电脑)
主 / 从 : 现在有多个服务器节点 , 其中一个是主节点 , 一个是从节点 , 一般从节点的数据要从主节点中定期同步过来
中间件 : 一个 / 一组和业务无关的服务 (功能更通用的服务) , 比如 : 数据库、缓存、消息队列 …
可用性 : 可用时间 / 总时间 , 数字越高越好 . 可用性可以认为是一个系统中最重要的一点
响应时长 : 衡量服务器的性能 , 越小越好 . 和服务器要做的业务有关
吞吐率 / 并发量 : 衡量系统处理请求的能力

---

小结 : 所谓的分布式系统 , 就是想办法引入更多的硬件资源
单机架构 : 应用程序 + 数据库服务
数据库和应用分离 : 应用程序和数据库服务分别放到不同主机上部署
负载均衡 : 应用服务器变成了一组应用服务器 (集群) , 通过负载均衡器 , 把请求比较均衡的分发给集群中的每个应用服务器
读写分离 : 数据库主从结构 -> 一个数据库节点作为主节点 , 其他 N 个数据库节点作为从节点 , 那主节点负责写数据 , 从节点负责读数据 . 主节点需要将修改过的数据同步给从节点
引入缓存 : 将热点数据放到缓存中 , 进一步的提升了服务器针对请求的处理能力

Redis 在一个分布式系统中 , 通常就扮演着缓存这样的角色

分库分表 : 让数据库能够进一步扩展存储空间
微服务 : 从业务上进一步拆分应用服务器 , 拆分成更多的小功能 , 每个小部分就是微服务

三 . Redis 的特性

我们之前了解到了 , Redis 是一个在内存中存储数据的中间件
他既可以用作数据库 , 也可以用作数据缓存 , 它能够在分布式系统中大放异彩
那官网也列出了许多 Redis 的特性

我们分别来看

在内存中存储数据 , 那 key 都是 string , 而 value 则可以是 strings、hashes、lists、sets、sorted sets、streams 等等

他指的是我们针对 Redis 的操作 , 我们可以直接通过简单的交互式命令进行操作 , 那也可以通过一些脚本的方式 , 批量执行一些操作 (可以带有一些逻辑) .
那其中 Lua 也是一个编程语言

他指的是我们还可以在 Redis 原有的基础上再进行扩展 , 那 Redis 提供了一组 API , 我们就可以通过 C/C++/Rust 这几种编程语言来去编写 Redis 的一些扩展程序 (本质就是一个动态链接库)

Redis 是把数据保存到内存中的 , 但是内存上的数据是易丢失的 (比如进程退出 / 系统重启 … 都会造成数据丢失) , 所以 Redis 也会选择把数据存储在硬盘上 , 以内存为主 , 硬盘为辅 (硬盘就相当于对内存的数据备份了)
如果 Redis 重启了 , 就会在重启时加载硬盘中的备份数据 , 使 Redis 中的内存恢复到重启之前的状态

Redis 作为一个分布式系统中的中间件 , 能够支持集群是非常关键的 . 这个水平扩展就类似分库分表
一个 Redis 能够存储的数据是有限的 , 那引入多个主机部署多个 Redis 节点 , 每个 Redis 只需要存储数据的一部分即可

高可用 , 也叫冗余 / 备份 . 那 Redis 自身也支持主从结构 , 从节点就相当于主节点的备份

那还有一点 , 官网上没有提到 , 这也是他最大的特点 : 快
那他为什么这么快呢 ?

1. Redis 数据存放在内存中 , 就比访问硬盘的数据库要快很多
2. Redis 核心功能都是比较简单的逻辑 , 核心功能都是比较简单的操作内存当中的数据结构
3. 从网络角度上来看 , Redis 使用了 IO 多路复用的方式

IO 多路复用指的是使用一个线程 , 管理很多的 socket

4. Redis 使用的是单线程模型 (虽然更高版本的版本也引入了多线程) , 单线程模型就减少了不必要的线程之间的竞争开销

多线程提高效率的前提是 CPU 密集型的任务和 IO 密集型的任务 , 那使用多个线程确实可以充分的利用 CPU 的多核资源
但是 Redis 的核心任务 , 主要是操作内存的数据结构 , 并不会吃很多 CPU

5. (Redis 是使用 C 语言开发的)

有点牵强 , 因为 MySQL 也是 C 语言写的 , 那 MySQL 也不快 , 所以使用 C 语言个人觉得不是提升速率的原因

四 . Redis 的应用场景

我们分别来看

4.1 Redis 能做的事

我们可以把 Redis 当做数据库 , 对于实时性要求比较高的场景就非常适合使用 Redis

那我们知道 , 使用 MySQL 存储数据是比较慢的 , 那我们把热点数据单独保存到 Redis 缓存中 , 这样访问速度就会快了很多
另外这里面还提到了会话存储 (session storage) , 我们之前的 cookie 和 session 机制是这样的

cookie : 实现用户身份信息的保存 , 只是在浏览器这边存储了一个用户的身份标识 (sessionId)
session : 服务器这里真正存储了用户数据

那我们就存在这样的一个问题 :

Redis 还可以作为消息队列 , 基于 Redis 可以实现一个网络版本的生产者-消费者模型

分布式系统中 , 服务器和服务器之间 , 有时候也需要使用到生产者-消费者模型的 , 它的优点有两点 :

1. 解耦合
2. 削峰填谷

那 Redis 研发出来 , 其实本来想要作为消息队列的 , 但是大家觉得他作为数据库 / 缓存更香一些 , 这也算是无心插柳柳成荫

4.2 Redis 不能做的事

Redis 存在的最大问题是不能存储大规模数据 , 因为 Redis 的数据主要是存放在内存中的 , 而内存的大小也是有限的 , 并且还有许多其他程序来去争抢内存资源