目录
- Redis 是一个在内存中存储数据的中间件
- 用作为数据库,用作为数据缓存
- 在分布式系统中能够大展拳脚
内存中存储数据
- 奠定了 Redis 在进行 访问 和 存储 时比较快 的基本特点
注意:
- 相较于 单机程序 直接通过 变量 在 内存中存储数据
- Redis 可以实现在 分布式系统 中让 多个服务器共享同一份数据,并且这些数据能够存储在内存中以提高访问速度
实例理解
- 进程之间具有隔离性,每个进程都是被隔离开的,进程 A 无法直接读进程 B 中的数据
- 一个分布式系统往往会涉及到多个进程,且这多个进程均分布在不同的主机
- 当我们想访问其他进程中的变量时,这是具有一定难度的
- 而 Redis 则针对我们上述的需求进行了一个封装
- 网络作为进程间的通信关键介质,Redis 就是基于网络可以把自己内存中的变量给别的进程,甚至别的主机的进程进行使用!
可编程性
- 针对 Redis 的操作,我们可以直接通过简单的交互式命令进行操作,也可以通过一些脚本的方式 批量执行一些操作(可以带有一些逻辑)
- 如 Redis 支持使用 Lua 编写脚本,这些脚本可以在 Redis 服务器端执行
- 通过脚本,可以实现复杂的数据操作和逻辑,比如批量操作、事务、原子性操作等
可扩展性
- Redis 原有的功能基础上通过 C、C++、Rust 这些语言编写 Redis 扩展
- Redis 自身已经提供很多数据结构和命令,可通过扩展让 Redis 支持更多数据结构和命令
持久化
- 在内存中存储数据可能因为进程退出或系统重启导致数据的丢失
- 但 Redis 以内存为主、硬盘为辅,硬盘对数据进行备份
- Redis 重启则会重新加载硬盘中备份数据到内存上,从而保证持久化
支持集群
- Redis 提供了一种分布式架构,允许将数据分布在多个节点上,以实现数据的水平扩展和高可用性
- 一个 Redis 能存储的数据空间是有限的,引入多个主机,部署多个 Redis 节点,对数据进行分散存储,扩大存储空间
高可用性
- Redis 支持 主从结构,从节点相当于主节点的备份,当哪一个节点故障时,Redis 集群可以自动进行故障转移,将一个从节点提升为新的主节点,以保持服务的可用性
- 故障转移过程中,集群会重新分配数据槽,并重新配置主从关系
- Redis 在处理数据请求时具有 高效率 和 快速响应 的优势
分析原因:
- Redis 的数据存储在内存中,相比于访问硬盘的数据库,内存的读写速度要快得多
- Redis 的核心功能主要是操作内存的数据结构,这些操作通常比较简单,因此执行速度快
- Redis 使用了 IO 多路复用的方式(如 epoll),即使用一个线程管理多个 socket,这样可以提高网络通信的效率
- Redis 使用的是单线程模型(虽然更高版本的 Redis 引入了多线程),这样的单线程模型,减少了不必要的线程之间的竞争开销
注意:
- 多线程提高效率的前提是 CPU 密集型的任务,使用多个线程可以充分的利用 CPU多核资源
- 但是 Redis 的核心任务主要就是操作内存的数据结构,不会吃很多 CPU,反而会因为加锁,导致线程竞争,导致性能的效率受到影响
- MySQL 主要是通过 表 的方式来存储组织数据的(关系型数据库)
- Redis 主要通过 键值对 的方式来存储组织数据的(非关系型数据库)
Redis 相较于 MySQL 优势
- Redis 在内存中存储,其访问速度十分快
- 相较于 MySQL 在硬盘中存储,其访问速度要慢得多
- 从而当在一些对性能要求很高的互联网产品中,Redis 也被当作数据库进行使用!
Redis 相较于 MySQL 劣势
- Redis?与 MySQL 相比的最大劣势为存储空间相对有限
- 如果应用对性能要求不高 且 需要存储大量的数据 时,MySQL 应作为首要选择
注意:
- 此处将 Redis 用作数据库,存储的是?全量数据,即这里的数据是不能随便丢弃的
典型场景
- 我们可以将 Redis 和 MySQL 结合起来使用,从而达到存储空间又大且访问速度又快的需求
- ' 二八原则 ',即?20% 的热点数据能满足 80% 的访问需求,利用该点将 Redis 用作缓存
- 我们可以将热点数据放到 Redis 中进行存储,以满足我们大部分的访问需求!
问题:
- 系统的复杂程度大大提高
- 当数据发生修改,还涉及到 Redis 和 MySQL 之间的数据同步问题!
注意:
- 此处 Redis?存的是部分数据,全量数据都是以 MySQL 为主的
哪怕 Redis 的数据没了,还可以从 MySQL 这边再加载回来
- 在 Web 应用程序中,session 用于跟踪和存储用户的会话状态信息!
- Redis 存储 session 信息属于 Redis 缓存 的经典应用场景
实例理解
- 分布式部署应用程序
- 将?session 信息存储在应用程序的内存中
问题:
- 当用户再次发起登录请求时,负载均衡器如何将同一个用户的请求始终分配到同一个机器上
解决方案一:
- 负载均衡器不再使用轮询操作,而是通过 userId 来进行服务器的分配
- 此时有三台应用服务器,只需将 userId 对 3 进行求余操作,每个余数对应一台应用服务器
解决方案二:
- 将所有 session 会话都存储到 Redis 上,让所有服务器从 Redis 中拿去相应的 session 信息
- 由于将会话放到 Redis 中进行存储,所以万一应用程序重启,会话也不会丢失!
初心
- Redis 最初就是用来作为一个“消息中间件”(消息队列)来使用的,即 分布式系统下的生产者消费者模型(网络版生产者消费者模型)
- 但很少会使用 Redis 来作为消息中间件,因为业界有更多专业的消息中间件进行使用!
- 当前 Redis 主要还是被用作数据库和缓存!
消息队列的优势
- 解耦:发送者和接收者之间通过消息队列进行通信,互不直接依赖或了解对方存在,这种解耦使得系统组件能够独立地进行扩展
- 削峰填谷:消息队列能够平衡系统的负载,当消息发送过快,队列可以缓冲消息并按照接收者的处理能力进行消费,从而防止系统过载
Redis 适用于消息队列的场景
- Redis 由于其高性能和支持丰富的数据结构,它也被广泛用于构建?轻量级?的消息队列系统
- 如果当前场景中,对于消息队列的功能依赖的不是很多,并且又不想引入额外的依赖,此时的 Redis 就可以作为一个选择
总结:
- 相对于更高级功能和更复杂的消息处理逻辑,需要用到专门的消息队列中间件,如RabbitMQ、Apache Kafka 等
- 这些中间件提供了更丰富的功能和更强大的扩展性,适用于更复杂的消息处理场景!