这应该是最全的Redis解析了

本文深入探讨了 Redis 的应用场景、数据结构及其在 Spring Boot 中的使用,包括分布式缓存、分布式锁、Session 存储、发布/订阅、任务队列等。详细解析了 Redis 的字符串、列表、哈希表、集合和有序集合五种数据类型,并提供了在 Spring Boot 项目中使用 Redis 的配置方法和实例。文章最后讨论了 Redis 实现分布式锁的策略以及面试中常问的 Redis 相关问题。
摘要由CSDN通过智能技术生成

在这篇文章中,我们将彻底了解 Redis 的使用场景、Redis 的五种数据结构,以及如何在
Spring Boot 中使用 Redis,文章的最后还会列举面试过程中经常被问到的关于 Redis
的问题以及其解决方案。

Redis 简介

Redis 是一个开源(BSD
许可)、内存存储的数据结构服务器,可用作数据库,高速缓存和消息队列代理。它支持字符串、哈希表、列表、集合、有序集合等数据类型。内置复制、Lua
脚本、LRU 收回、事务以及不同级别磁盘持久化功能,同时通过 Redis Sentinel
提供高可用,通过 Redis Cluster
提供自动分区。在实际的开发过程中,多多少少都会涉及到缓存,而 Redis
通常来说是我们分布式缓存的最佳选择。Redis 也是我们熟知的
NoSQL(非关系性数据库)之一,虽然其不能完全的替代关系性数据库,但它可作为其良好的补充。

Redis 使用场景

微服务以及分布式被广泛使用后,Redis
的使用场景就越来越多了,这里我罗列了主要的几种场景。

  1. 分布式缓存:在分布式的系统架构中,将缓存存储在内存中显然不当,因为缓存需要与其他机器共享,这时
    Redis 便挺身而出了,缓存也是 Redis 使用最多的场景。
  2. 分布式锁:在高并发的情况下,我们需要一个锁来防止并发带来的脏数据,Java
    自带的锁机制显然对进程间的并发并不好使,此时可以利用 Redis单线程的特性来实现我们的分布式。
  3. Session 存储/共享:Redis 可以将 Session
    持久化到存储中,这样可以避免由于机器宕机而丢失用户会话信息。
  4. 发布/订阅:Redis 还有一个发布/订阅的功能,您可以设定对某一个 key
    值进行消息发布及消息订阅,当一个 key值上进行了消息发布后,所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统。
  5. 任务队列:Redis 的 lpush+brpop
    命令组合即可实现阻塞队列,生产者客户端使用 lrpush从列表左侧插入元素,多个消费者客户端使用 brpop命令阻塞式的"抢"列表尾部的元素,多个客户端保证了消费的负载均衡和高可用性。
  6. 限速,接口访问频率限制:比如发送短信验证码的接口,通常为了防止别人恶意频刷,会限制用户每分钟获取验证码的频率,例如一分钟不能超过
    5 次。

当然 Redis
的使用场景并不仅仅只有这么多,还有很多未列出的场景,如计数、排行榜等,可见 Redis
的强大。不过 Redis
说到底还是一个数据库(非关系型),那么我们还是有必要了解一下它支持存储的数据结构。

Redis 数据类型

前面也提到过,Redis
支持字符串、哈希表、列表、集合、有序集合五种数据类型的存储。了解这五种数据结构非常重要,可以说如果吃透了这五种数据结构,你就掌握了
Redis 应用知识的三分之一,下面我们就来逐一解析。

字符串(string)

string 这种数据结构应该是我们最为常用的。在 Redis 中 string
表示的是一个可变的字节数组,我们初始化字符串的内容、可以拿到字符串的长度,可以获取
string 的子串,可以覆盖 string 的子串内容,可以追加子串。

图 1. Redis 的 string 类型数据结构

这应该是最全的Redis解析了

如上图所示,在 Redis
中我们初始化一个字符串时,会采用预分配冗余空间的方式来减少内存的频繁分配,如图 1
所示,实际分配的空间 capacity 一般要高于实际字符串长度 len。如果您看过 Java 的
ArrayList 的源码相信会对此种模式很熟悉。

列表(list)

在 Redis 中列表 list
采用的存储结构是双向链表,由此可见其随机定位性能较差,比较适合首位插入删除。像
Java 中的数组一样,Redis 中的列表支持通过下标访问,不同的是 Redis
还为列表提供了一种负下标,-1 表示倒数一个元素,-2
表示倒数第二个数,依此类推。综合列表首尾增删性能优异的特点,通常我们使用
rpush/rpop/lpush/lpop 四条指令将列表作为队列来使用。

图 2. List 类型数据结构

这应该是最全的Redis解析了

如上图所示,在列表元素较少的情况下会使用一块连续的内存存储,这个结构是
ziplist,也即是压缩列表。它将所有的元素紧挨着一起存储,分配的是一块连续的内存。当数据量比较多的时候才会改成
quicklist。因为普通的链表需要的附加指针空间太大,会比较浪费空间。比如这个列表里存的只是
int 类型的数据,结构上还需要两个额外的指针 prev 和 next。所以 Redis 将链表和
ziplist 结合起来组成了 quicklist。也就是将多个 ziplist
使用双向指针串起来使用。这样既满足了快速的插入删除性能,又不会出现太大的空间冗余。

哈希表(hash)

hash 与 Java 中的 HashMap
差不多,实现上采用二维结构,第一维是数组,第二维是链表。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值