当前位置：首页 > article >正文

Redis初识

article 2025/2/22 23:49:31

关于Redis

分布式系统

Redis特性

Redis应用场景

Redis环境搭建

redis客户端介绍

关于Redis

Redis 是在分布式系统中，才能发挥威力的，如果只是单机程序，直接通过变量存储数据的方式是比使用 Redis 更优的选择

Redis 其实就是基于网络，可以把自己内存中的变量给别的进程，甚至别的主机的进程进行使用

Redis 官方网站的介绍是：
Redis 使用非常广泛，已经被数以百万的开发者，用来当 数据库、缓存、流式引擎、消息中间件

数据库
首先对于数据库来说，比较熟悉的就是 MySQL了，MySQL 最大的问题在于访问速度比较慢，所以相比于 MySQL，Redis 作为数据库使用，是比 MySQL 速度快很多的数据库
因为 Redis 是在内存中存储的，而 MySQL 是在硬盘上存储的
但是 Redis 和 MySQL 相比，最大的劣势就是 Redis 存储空间是有限的

缓存
上面说到 Redis 作为数据库更快，MySQL作为数据库空间更大，那么能不能又快又大呢
典型的方案，可以把 Redis 和 MySQL 结合起来使用，将少量且常用的热点数据放入 Redis 中，大量的数据则依旧存在 MySQL 中，这样既能满足大多数情况下访问热点数据时使用的 Redis，可以满足速度快，而大量的数据是存在 MySQL 中的，满足容量大
此时 Redis 起到的角色就是缓存

这种方案系统的复杂程度大大提升了，而且如果数据发生修改，还涉及到 Redis 和 MySQL 之间的数据同步问题

消息中间件
Redis 的初心，最初就是用来作为一个消息中间件的(消息队列)，也就是分布式系统下的生产者消费者模型
但是有心栽花花不开，无心插柳柳成荫，后来人们发现 Redis 作为数据库或是缓存优势更大，反而使用消息中间件的非常少
当前很少会直接使用 Redis 作为消息中间件，因为业界有更多更专业的消息中间件使用

分布式系统

单机架构

单机架构也就是只有一台服务器，这个服务器负责所有的工作，应用服务和数据库服务在一台主机上，绝大部分的公司的产品，都是这种单机架构

现在计算机硬件，发展速度非常之快，哪怕只有一台主机，这一台主机的性能也是很高的
是可以支持非常高的并发和非常大的数据存储

如果业务进一步增长，用户量和数据量都水涨船高，一台主机难以应付的时候，就需要引入更多的主机，引入更多的硬件资源

之所以一台服务器难以应对，原因如下：
服务器每次收到一个请求，都是需要消耗上述的一些资源的
如果同一时刻处理的请求多了，此时就可能会导致某个硬件资源不够用了(CPU/内存/硬盘...)
无论是哪个方面不够用了，都可能会导致服务器处理请求的时间变长甚至于处理出错

引入分布式系统

当出现一台主机难以应对的场景时，在单机架构的基础上，解决问题的方式有两种：
一是简单粗暴的增加更多的硬件资源
二是在软件上优化，需要通过性能测试，找到是哪个环节出现了瓶颈，再去对症下药，这对程序员要求比较高

但是一个主机上面能增加的硬件资源也是有限的，取决于主板的扩展能力

所以当一台主机扩展到极限了，但是还不够时，就只能引入多台主机了，一旦引入多台主机了，咱们的系统就可以称为是 "分布式系统”

引入分布式这是万不得已的，系统的复杂程度会大大提高，所以出现 bug 的概率越高，所以引入分布式系统，是万不得已的，能在一台主机上完成，就尽量在一台主机上进行开发

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

此时将应用服务和数据库服务分离，就有两个服务器分别负责各自的服务：

这时就可以针对不同服务器的特点，给它配置不同的主机，能够达到一个更高的性价比：

应用服务器,里面可能会包含很多的业务逻辑, 可能会吃 CPU 和内存
数据库服务器,需要更大的硬盘空间,更快的数据访问速度可以配置更大硬盘的服务器,甚至还可以上 SSD 硬盘(固态硬盘)

引入更多的应用服务器

应用服务器可能会比较吃 CPU 和内存，如果把 CPU 或者内存吃没了，此时应用服务器就顶不住了，引入更多的应用服务器，就可以有效解决上述问题

上图上只列举了2个应用服务器，实际上可能是多个

用户的请求，先到达负载均衡器/网关服务器(也是一个单独的服务器)

假设有 1w 个用户请求，有 2个应用服务器，此时按照负载均衡的方式，就可以让每个应用服务器承担 5k 的访问量

数据库读写分离

如上面所说，增加应用服务器，确实能够处理更高的请求量，但是随之而来的问题就是，存储服务器要承担的请求量也就更多了

此时就需要引入更多的机器了，其中最典型的方案叫做 数据库的读写分离

主数据库只负责写，从数据库只负责读，当主数据库更新数据时，还需要数据同步到从数据库上

实际的应用场景中，读的频率是比写要高的
所以主服务器一般是一个，从服务器可以有多个(一主多从)
同时从数据库通过负载均衡的方式，让应用服务器进行访问，保证每一个从数据库承担的压力也没有特别高

引入缓存

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

和上面的分布式系统相比较而言，多了一个缓存服务器，在这个缓存服务器中，只放一小部分热点数据(会频繁被访问到的数据)

存储服务器中存储的依旧是完整的全量数据，缓存服务器只放一小部分热点数据
二八原则：20%的数据，能够支持80%的访问量

而缓存要想快，就要付出代价，也就是内存比较小，我们将学习的 Redis 就是处于这个缓存服务器的位置

所以在用户发起请求时，先在缓存服务器中查找数据，如果没有找到再读数据库服务器
此时, 缓存服务器就帮助数据库服务器负重前行

数据库分库分表

引入分布式系统，不光要能够去应对更高的请求量(并发量)，同时也要能应对更大的数据量
当然也可能会出现，一台服务器已经存不下数据的情况，例如短视频平台，一条视频所需占用的内存是非常大的
虽然一个服务器，存储的数据量可以达到几十个 TB，即使如此也可能会存不下，一台主机存不下，就需要多台主机来存储

如上图所示，针对数据库进行进一步的拆分分库分表
本来一个数据库服务器上有多个数据库(指的是逻辑上的数据集合，即 create database 创建的数据库)
现在就可以引入多个数据库服务器，每个数据库服务器存储一个或者一部分数据库

如果某个表特别大，大到一台主机存不下，也可以针对表进行拆分

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

微服务架构

之前的应用服务器，一个服务器程序里面做了很多的业务，这就可能会导致这一个服务器的代码变的越来越复杂为了更方便于代码的维护，就可以把这样的一个复杂的服务器，拆分成更多的、功能更单一，但是更小的服务器(微服务) 此时服务器的种类和数量就增加了

注意：
微服务本质上是在解决"人"的问题
当应用服务器复杂了，势必就需要更多的人来维护了，当人多了，就需要配套的管理，以便把这些人组织好
此时就需要划分组织结构，分成多个组，每个组分别配备领导进行管理，而分成多个组，就需要进行分工

按照功能，拆分成多组微服务，就可以有利于上述人员的组织结构的分配了

引入微服务，缺点有：
①系统的性能下降(要想保证性能不下降太多,只能引入更多的机器,更多的硬件资源 => 充钱)
拆出来更多的服务，多个功能之间要更依赖网络通信，网络通信的速度很可能是比硬盘还慢的
幸运的是，硬件技术的发展，网卡现在有万兆网卡，读写速度已经能过超过硬盘读写了，但是比较贵
②系统复杂程度提高, 可用性收到影响
服务器更多了，出现问题的概率就更大了，这就需要一系列的手段，来保证系统的可用性
(更丰富的监控报警，以及配套的运维员)

引入微服务，优点有：
①解决了人的问题
②使用微服务,可以更方便于功能的复用
③可以给不同的服务进行不同的部署

相关概念

应用 / 系统
一个应用，就是一个 / 一组服务器程序
模块 / 组件
一个应用里面有很多个功能，每个独立的功能，就可以称为是一个模块 / 组件
分布式
引入多个主机/服务器,协同配合完成一系列的工作，是物理上的多个主机
集群
引入多个主机/服务器,协同配合完成一系列的工作，是逻辑上的多个主机
当集群中的某个主机挂了，其他的主机仍然可以承担服务，提高了整个系统的可用性
主(Master) / 从(Slave)
分布式系统中一种比较典型的结构
多个服务器节点，其中一个是主，另外的是从，从节点的数据要从主节点这里同步过来
中间件
也就是和业务无关的服务(功能更通用的服务)
例如：数据库、缓存、消息队列等等
可用性
系统整体可用的时间 / 总的时间，是一个系统的第一要务
响应时长
衡量服务器的性能，越小越好，是和具体服务器要做的业务密切相关的
吞吐 vs 并发
衡量系统的处理请求的能力，衡量性能的一种方式

Redis特性

Redis 是一个在内存中存储数据的中间件，用于作为数据库，用于作为数据缓存，在分布式系统中能够大展拳脚

下面是 Redis 官方文档上介绍的特性：

In-memory data structures：在内存中存储数据
MySQL 主要是通过"表”的方式来存储组织数据的 -> "关系型数据库"
Redis 主要是通过"键值对"的方式来存储组织数据的 -> "非关系型数据库”
Programmability：可编程的
针对 Redis 的操作，可以直接通过简单的交互式命令进行操作，也可以通过一些脚本的方式，批量执行一些操作(可以带有一些逻辑)
Extensibility：可扩展性
可以在 Redis 原有的功能基础上再进行扩展，Redis 提供了一组 API
可以通过 C/C++/Rust 这几个语言编写 Redis 扩展(本质上就是一个动态链接库，相当于windows 上的 dll，可以让 exe 去调用，里面包含很多代码)
我们可以自己去扩展 Redis 的功能，比如Redis 自身已经提供了很多的数据结构和命令，通过扩展，让 Redis 支持更多的数据结构以及支持更多的命令
Persistence：持久化
Redis 把数据存储在内存上的，而内存的数据是"易失"的，在进程退出/系统重启时会丢失
所以 Redis 会把数据存储在硬盘上，内存为主，硬盘为辅(硬盘相当于对内存的数据的备份)
如果 Redis 重启了，就会在重启时加载硬盘中的备份数据，使 Redis 的内存恢复到重启前的状态
Clustering：集群
Redis 作为一个分布式系统中的中间件，能够支持集群是很关键的，这个水平扩展类似于分库分表
一个 Redis 能存储的数据是有限的(内存空间有限)，引入多个主机，部署多个 Redis 节点，每个 Redis 存储数据的一部分，就能够解决内存有限的问题
High availability：高可用性
高可用性也代表着冗余 / 备份
Redis 自身也是支持 "主从"结构的，从节点就相当于主节点的备份了

Redis 之所以使用如此之广泛，最重要的原因就是快！那么为什么 Redis 速度这么快呢？

Redis 数据在内存中，就比访问硬盘的数据库要快很多
Redis 核心功能都是比较简单的逻辑，核心功能都是比较简单的操作内存的数据结构
从网络角度上,Redis 使用了 10 多路复用的方式(epoll)，即使用一个线程,管理很多个 socket
Redis 使用的是单线程模型(虽然更高版本的 Redis 引入了多线程) 这样的单线程模型，减少了不必要的线程之间的竞争开销

Redis应用场景

在 Redis 官方文档上列举了三个常用的应用场景：

Real-time data store：实时数据存储

对于实时性要求比较高，需要更低的延迟和更高的吞吐量的场景

大多数情况下考虑到数据存储，优先考虑的是"大"，但是仍然有一些场景考虑的是"快”
例如：搜索引擎(广告搜索 / 商业搜索)，对性能要求是比较高的，所以不会使用像 MySQL 这样的数据库，而是把所有需要检索的数据都存储在内存中，使用的是类似于 Redis 这样的内存数据库来完成的

这里的 Redis 存的是全量数据，这里的数据是不能随便丟的

Caching & session storage：缓存/会话存储

关于缓存

使用 MySQL 存数据，缺点是大和慢
又因为大多数场景都符合二八原则，所以可以把热点数据拎出来，存储在redis 中
Redis 存的是部分数据，全量数据都是以 MySQL 为主的，哪怕 Redis 的数据没了，还可以从 mysql 这边再加载回来

关于会话存储

session 是在学习 HTTP协议时，从 cookies 那里引入的概念，cookies 实现用户身份信息的保存，是需要 session 配合的
cookies 只是在浏览器这边存储了一个用户的身份标识(sessionID)，session 是在服务器上真正存储了用户数据

之前学习的 session 是存储在应用服务器上的，用户在客户端进行登录操作时，登录成功后，负载均衡器选择一台应用服务器生成会话，那么下次用户再登录时，可能负载均衡器会选择另一台主机，里面没有存储上次登录的会话，这时就需要用户再次登录，这样的情况显然不是我们所期望的

想要解决上述问题，有两种思路：
①想办法让负载均衡器，把同一个用户的请求始终打到同一个机器上 (不能轮询，而是要通过 userld 之类的方式来分配机器)
②把会话数据单独拎出来，放到一组独立的机器上存储(也就是放到 Redis 中存储)

自然会选择第二种更加科学的思路，会话存储到 Redis 上后，后续每一个应用服务器在读取会话或是写入会话时，都去访问 Redis，这时不管用户的请求被负载均衡器分配到哪一台服务器上，始终都是从 Redis 中拿取 session 的，这样就自然能够保证用户信息能够被顺利获取到，并且万一应用程序重启了，会话是不会丢失的
还有一点，会话这种数据即使丢失了，用户再重新登录一次即可，问题是不大的，所以这就是会话存储应用广泛的原因

Streaming & messaging：消息队列

消息队列(服务器)，此处说到的消息队列，不是 Linux 进程间通信的那个消息队列
基于这个消息队列,可以实现一个网络版本的生产者消费者模型
对于分布式系统来说，服务器和服务器之间，有时候也需要使用到生产者消费者模型的，生产者消费者模型的优势就是：解耦合、削峰填谷

消息队列是创建 Redis 的初心了，但是这个应用场景是比较少的，因为业界也有很多知名的消息队列，例如：RabbitMQ、Kafka、 RocketMQ等等
Redis 也是提供了消息队列的功能的，如果当前场景中，对于消息队列的功能依赖的不是很多，并且又不想引入额外的依赖了，Redis 可以作为一个选择

Redis环境搭建

我们接下来安装的是 Redis 5 系列，因为公司大多数都用的 Redis 5，Redis 最新的 7系列相比于 5系列也并没有新增很多功能，并且比 5系列安装更麻烦一些

Redis 是在 Linux 下进行安装的，Redis 官方是不支持 Windows 版本的，微软维护了一个 Windows 版本的 Redis 分支

开始学习的时候，先在本机上安装，后面学到 Redis 的集群相关的功能的时候，再使用 Docker

在Ubuntu上安装Redis

由于 Centos 官方不再更新了，所以下面是使用的 Ubuntu 下安装 Redis的

先切换到 root 用户
su 命令切换到 root
使用 apt 命令来搜索 redis 相关的软件包
apt search redis
使用 apt 命令安装
redisapt install redis
需要手动修改配置文件,把 ip 改了(为了能够跨主机访问)
很多软件都是有配置文件的，一个大的软件，里面包含很多的功能，有很多可以定制化的操作，就可以通过配置文件选择开启/关闭/设定某些功能
cd /etc/redis，里面的 redis.conf 就是 Redis 的配置文件
找到下面这个地方，将 127.0.0.1 改为 0.0.0.0
改为：
将保护模式由 yes 改为 no
改为：
重新启动服务器
service redis-server restart
执行 service redis-server status 可以查看是否启动成功：
使用 redis 自带的客户端来连接服务器
redis-cli
连接后，发送 ping，如果返回的是 PONG 就说明连接成功了(ctrl + d 退出连接)