ToB企服应用市场:ToB评测及商务社交产业平台

标题: 【redis】redis的特性和紧张应用场景 [打印本页]

---

作者: 魏晓东    时间: 2024-9-11 12:08
标题: 【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 是存储在应用服务器上的，但现在变成了分布式体系，引入了负载均衡
  

---

第一次客户端发出哀求，负载均衡器将哀求传到应用服务器 A，举行登录操作。登录成功之后，应用服务器就会天生当前用户的会话
但下次这个用户再次访问的时候，负载均衡器就可能将哀求传到应用服务器 B，而这个应用服务器又没有这个用户前次举行访问产生的相关会话，难倒要再登录一次吗？
怎样办理上述问题？

• 想办法让负载均衡器，把同一个用户的哀求始终打到同一个呆板上（不能轮询了，要通过 userId 之类的方式来分配呆板）
  
• 把会话数据单独拎出来，放到一组独立的呆板上存储
  
  
  

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

消息队列

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

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4