🔎Redis—特性
MySQL 主要是通过 “表” 的方式组织存储数据 → 关系型数据库
Redis 主要是通过 “键值对” 的方式组织存储数据 → 非关系型数据库
In-memory data structures—在内存中存储数据
在内存中存储数据
Redis 通过键值对方式组织存储数据
其中 key 都是 string 类型, value 可以是 strings, hashes, lists, sets, sorted sets, streams…
Programmability—可编程性
可编程性
针对 Redis 的操作
可直接通过简单的交互式命令进行操作
也可以通过一些脚本的方式批量执行一些操作
Extensibility—可扩展性
可扩展性
可以在 Redis 原有的功能基础上进行扩展(通过 C, C++, Rust 进行扩展)
Persistence—持久化
持久化
Redis 为了能够快速访问, 将数据存储至内存中
内存中的数据是易丢失的(进程退出, 系统重启…)
因此 Redis 也会将数据存储至硬盘(硬盘中的数据相当于是对内存的数据进行备份) → 持久化
例如当系统重启, 就会在重启时加载硬盘中的备份数据, 使 Redis 的内存恢复如初
Clustering—集群
集群
一个 Redis 所能存储的数据是有限的(内存空间有限)
集群 → 引入多台主机, 部署多个 Redis 节点, 让每个 Redis 存储一部分数据
High availability—高可用
高可用
你可以将高可用理解为备份
Redis 支持主从结构, 从节点相当于是主节点的备份
🔎Redis 为什么快
Redis 对比 MySQL 为什么快
- Redis 的数据存储在内存中, MySQL 的数据存储在硬盘中
- Redis 的核心功能都是比较简单的操作内存结构
MySQL 中的一些操作较为复杂. 例如插入数据时, 如果存在约束, 需要查看具体的约束状态… - Redis 使用了 IO 多路复用的方式(一个线程管理多个 socket)
- Redis 默认情况下使用单线程处理请求, 避免多线程之间的锁竞争和锁带来的开销(大多数简单的的读写操作, 使用单线程方式更高效)
MySQL 处理复杂查询时采用多线程处理, 导致额外的开销
🔎Redis 的使用场景
- Real-time data store—实时数据存储
- Caching—缓存
- session storage—会话存储
- Streaming&messaging—消息队列
Real-time data store—实时数据存储
实时数据存储, 将 Redis 作为数据库
大多数场景下的数据存储针对的是存储量大
而一些特定场景要求的是存储速度快, Redis 针对的就是这样的情况
将 Redis 作为数据库, 存储的是全部数据, 这里面的数据不能随便丢失
Caching—缓存
根据二八原则, 将热点数据存储至 Redis, MySQL 中依旧存储全部数据
即使 Redis 中的数据丢失, 也可以从 MySQL 中继续加载
session storage—会话存储
cookie → 浏览器存储的用户身份标识
session → 服务器存储的真正的用户数据
只有一台应用服务器时, 会话信息就存储在该应用服务器上
有多台应用服务器之后, 会话信息该如何存储呢?
举个栗子🌰
用户 A 登录一个网站, 输入对应的用户名和密码
只有一台应用服务器时, 无需负载均衡, 会话信息存储在该服务器上
此时 A 再次点击该网站, 该网站已经保存了 A 的会话信息, 无需进行登录操作
当有多台应用服务器时, 如果会话信息分别保存在多台应用服务器, 那么当 A 再次点击该网站, 又需要进行登录操作
万一 A 很不幸, 每次点击该网站, 负载均衡器都将其请求分配到了不同的应用服务器, 那么 A 会一直进行登录操作
对于上述的问题, 解决方式有 2 种🍂
- 通过特定的算法, 让 A 用户的请求每次都指定到同一个应用服务器
- 将会话信息单独保存至一台独立的机器(Redis)
Streaming&messaging—消息队列
有很多比较知名的消息队列, 例如 RabbitMQ, Kafka, RocketMQ…
Redis 也具有消息队列的功能
如果当前场景中, 对于消息队列的功能依赖比较少, 并且不想引入其他依赖的情况下, 可以将 Redis 作为消息队列
生产者可以将消息推送到 Redis 列表中, 然后消费者从列表中获取消息进行处理
🌸🌸🌸完结撒花🌸🌸🌸
