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