网站seo优化很好徐州百度网络点赞,公司注册的公司,wordpress菜单跳转页面,网易企业邮箱入口 官网文章目录 redis 的特性在内存中存储数据可编程的扩展能力持久化集群高可用快 redis 的应用场景实时数据存储缓存消息队列 redis 的特性
redis 的一些特性#xff08;优点#xff09;成就了它
在内存中存储数据
In-memory data structures
MySQL 主要是通过“表”的方式来… 文章目录 redis 的特性在内存中存储数据可编程的扩展能力持久化集群高可用快 redis 的应用场景实时数据存储缓存消息队列 redis 的特性
redis 的一些特性优点成就了它
在内存中存储数据
In-memory data structures
MySQL 主要是通过“表”的方式来存储组织数据的“关系型数据” Redis 主要是通过“键值对”的方式来存储数据的“非关系型数据库”
key 都是 Stringvalue 则可以是这些数据结构string、hashes、lists、sets、sorted sets、streamsand 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 可以作为一个选择
