魏晓东 发表于 2024-9-11 12:08:55

【redis】redis的特性和紧张应用场景

redis 的特性

redis 的一些特性(长处)成就了它
在内存中存储数据



[*]In-memory data structures
MySQL 紧张是通过“表”的方式来存储组织数据的“关系型数据”
Redis 紧张是通过“键值对”的方式来存储数据的“非关系型数据库”


[*]key 都是 String
[*]value 则可以是这些数据结构(string、hashes、lists、sets、sorted sets、streams,and more)
可编程的



[*]Programmability
针对 Redis 的操作,可以直接通过简单的交互式命令举行操作,也可以通过一些脚本的方式,批量实验一些操作(可以带有一些逻辑)
[*]紧张是使用 Lua 语言
扩展能力



[*]Extensibility
可以在 Redis 原有的功能基础上,再举行扩展。Redis 提供了一组 API,可以通过 C、C++、Rust 这几个语言编写 Redis 扩展(本质上就是第一个动态链接库)
[*]Windows 上的 .dll(动态链接库),里面包含很多的函数和代码,去给 exe 调用
[*]LInux 上的动态库是 .so,固然和 dll 格式不同,但本质是一样的
这个特性可以让我们自己去扩展 Redis 的功能。好比,Redis 自身已经提供了很多的数据结构和命名,通过扩展,让 Redis 支持更多的数据结构以及支持更多的命令
持久化



[*]Persistence
Redis 是把数据存储在内存上的,为了能更快速地访问。但内存上的数据是“易失的“(当进程退出/体系重启,数据就会丢失)
Redis 会把数据存储在硬盘上,内存为主,硬盘为辅(硬盘相当于对内存的数据备份了一下)。如果 Redis 重启了,就会在重启的时候加载硬盘中的备份数据,使 Redis 的内存回复到启动前的状态
集群



[*]Clustering
Redis 作为一个分布式体系的中间件,可以或许支持集群是很关键的
一个 Redis 能存储的数据是有限的(内存空间有限)。如果要存储更多的数据,就可以引入多个主机,摆设多个 Redis 节点,每个 Redis 存储数据的一部分
高可用



[*]High availability
核心就是“冗余/备份”
Redis 自身也使支持“主从”结构,从节点就相当于主节点的备份,当主节点挂了,从节点就能顶上去,代替主节点。这样就能包管体系可用性是很高的。当主节点挂了用户也感知不到,因为在这挂的一刹时,从节点就顶上去了


天下武功,唯快不破!但为什么 Redis 快?

[*] Redis 数据在内存中,就比访问硬盘的数据库速度要快很多
[*] Redis 核心功能都是比力简单的逻辑,功能都是比力简单的操作内存的数据结构
[*] 从网络角度上,Redis 使用了 IO多路复用 的方式(epoll)
IO多路复用 就是使用一个线程,管理多个 Socket。这样就可以在体系资源开销比力小的环境下,可以比力高效的处理比力高的并发量
[*] Redis 使用的是单线程模子(固然更高版本的 Redis 引入了多线程)
这样的单线程模子,减少了不必要的线程之间的竞争开销
多线程进步效率的条件是:这是一个 CPU 密集型的任务,使用多个线程可以充实的使用多核资源。但是对于 Redis 来说,它的紧张核心任务紧张就是操作内存的数据结构,不会吃很多 CPU
redis 的应用场景

实时数据存储



[*]Real-time data store
把 Redis 当做了数据库,按照键值对存储数据。(低延迟、高吞吐环境)存的是全量数据,这里的数据不能随便丢
大多数环境下,思量到数据存储,优先思量的是“大”,但是仍然有一些场景,思量的是“快”
缓存



[*]Caching
使用 MySQL 来存储数据,大、慢。使用二八原则,把热点数据拎出来,存储在 redis 中,把其他数据还是放在 MySQL 中
redis 里面存的是部分数据,全量数据都是以 MySQL 为主的,哪怕 redis 里面的数据没有了,还可以从 MySQL 中再加载回来


[*]session storage
cookie 实现用户身份信息的生存,需要 session 配合
[*]session 在服务器这里真正的存储了用户数据
[*]cookie 只是在欣赏器里存储了一个用户的身份标识(sessionId)
之前 session 是存储在应用服务器上的,但现在变成了分布式体系,引入了负载均衡
https://img-blog.csdnimg.cn/img_convert/6b3415f81566daf8f39bea25067796b4.png
第一次客户端发出哀求,负载均衡器将哀求传到应用服务器 A,举行登录操作。登录成功之后,应用服务器就会天生当前用户的会话
但下次这个用户再次访问的时候,负载均衡器就可能将哀求传到应用服务器 B,而这个应用服务器又没有这个用户前次举行访问产生的相关会话,难倒要再登录一次吗?
怎样办理上述问题?

[*] 想办法让负载均衡器,把同一个用户的哀求始终打到同一个呆板上(不能轮询了,要通过 userId 之类的方式来分配呆板)
[*] 把会话数据单独拎出来,放到一组独立的呆板上存储https://img-blog.csdnimg.cn/img_convert/370f0e69ead40c439535649b4a399802.png


[*]可以让应用服务器存到 redis 中,之后每一个应用服务器在读取会话大概写入会话的时候,都去访问这个 redis
[*]之后不管用户的哀求打到那个应用服务器上,始终我们都是从 redis 中拿到会话,这样就能包管无论访问到哪台应用服务器上,会话数据都能被完整的拿到。
[*]万一应用步伐重启了,会话也不会丢失
消息队列



[*]Streaming & messaging
此处说到的消息队列,是一个消息队列服务器。它是一个单独的服务器,起到消息队列的功能。基于这个服务器,我们就能实现一个网络版本的“生产者-消费者模子”
对分布式体系来说,服务器和服务器之间,偶然候也需要使用到生产者消费者模子,因为有优势:

[*]解耦合
[*]削峰填谷
业界也有很多着名的消息队列,RabbitMQ、Kafka、RocketMQ… redis 也是提供了消息队列的功能的,但一样平常不怎么使用。如果当前场景中,对于消息队列的功能依赖的不是很多,并且又不想引入额外的依赖,redis 可以作为一个选择

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
页: [1]
查看完整版本: 【redis】redis的特性和紧张应用场景