关于Redis知识的理解

小民有话说

已于 2024-07-04 10:04:51 修改

阅读量931

点赞数 23

分类专栏： Java 文章标签： redis 数据库缓存

于 2024-06-21 09:27:56 首次发布

本文链接：https://blog.csdn.net/u013367040/article/details/139533696

版权

Java 专栏收录该内容

30 篇文章 0 订阅

订阅专栏

系列文章
关于时间复杂度o(1), o(n), o(logn), o(nlogn)的理解

关于HashMap的哈希碰撞、拉链法和key的哈希函数设计

Redis的由来

Redis的作者，叫Salvatore Sanfilippo，来自意大利的西西里岛，居住在卡塔尼亚。目前供职于Pivotal公司。他使用的网名是antirez。为了解决网站的负载问题而在 2009 年发明了 Redis，并在社区的帮助下将其发展成为一种流行的开源数据库和缓存解决方案。

一、Redis数据类型的发展历程及使用命令？

Redis支持的数据类型是其核心功能之一，随着时间的推移，它不断扩展和改进。以下是Redis支持的主要数据类型的发展历程以及它们的常见使用命令：

1.字符串（String）

发展历程：字符串是Redis最基本的数据类型之一，从一开始就被支持。
常见命令：SET、GET、DEL、INCR、DECR等。

2.哈希表（Hash）

发展历程：Redis 2.0 引入了哈希表数据类型。
常见命令：HSET、HGET、HDEL、HGETALL、HINCRBY等。

3.列表（List）

发展历程：Redis 1.0 引入了列表数据类型。
常见命令：LPUSH、RPUSH、LPOP、RPOP、LRANGE等。

4.集合（Set）

发展历程：Redis 2.0 引入了集合数据类型。
常见命令：SADD、SREM、SMEMBERS、SINTER、SUNION等。

5.有序集合（Sorted Set）

发展历程：Redis 1.2 引入了有序集合数据类型。
常见命令：ZADD、ZRANGE、ZREM、ZSCORE、ZINTERSTORE等。

6.位图（Bitmap）

发展历程：Redis 2.6 引入了位图数据类型。
常见命令：SETBIT、GETBIT、BITCOUNT、BITOP等。

7.HyperLogLog

发展历程：Redis 2.8 引入了HyperLogLog数据类型。
常见命令：PFADD、PFCOUNT、PFMERGE等。

8.地理空间索引（Geo）

发展历程：Redis 3.2 引入了地理空间索引数据类型。
常见命令：GEOADD、GEODIST、GEORADIUS、GEORADIUSBYMEMBER等。

9.流（Stream）

发展历程：Redis 5.0 引入了流数据类型。
常见命令：XADD、XREAD、XTRIM、XLEN等。

二、Redis是单线程还是多线程？为什么查询效率高？

1.单线程模型

Redis一直以来都是单线程的，这是其设计和实现的核心特性之一。在Redis 6.0版本，为了改进Redis的性能和扩展性，引入了多线程 I/O（I/O threading）。但它仍然保持了单线程模型。也就是说，Redis在执行命令和数据处理时仍然是单线程的，多线程仅用于处理输入/输出操作，例如网络请求和磁盘操作。

2.查询效率高

查询效率高，主要是由于以下几个原因：

内存数据存储

Redis主要将数据存储在内存中，而不是磁盘上。由于内存的读写速度比磁盘快得多，因此Redis能够以极快的速度响应查询请求。此外，Redis还支持持久化机制，可以将内存中的数据定期或在特定条件下持久化到磁盘上，以防止数据丢失。

单线程优势

虽然Redis是单线程的，但是它通过高效利用CPU和内存以及非阻塞I/O模型，能够在单线程的情况下处理大量的并发请求。与多线程相比，单线程模型避免了线程切换和同步开销，简化了并发控制，从而提高了系统的整体性能。

非阻塞I/O模型

Redis使用了非阻塞的I/O多路复用模型（例如epoll、kqueue等），这使得单个线程可以同时处理多个客户端连接的请求。当一个客户端的请求需要等待磁盘I/O或网络I/O时，Redis可以继续处理其他客户端的请求，而不会被阻塞。

高效的数据结构和算法

Redis内部使用了高效的数据结构和算法来实现不同的数据类型和操作，例如使用哈希表来实现键值对存储、使用跳跃表来实现有序集合等。这些数据结构和算法的选择使得Redis在处理数据时具有高效性能。

三、Redis的部署模式有哪些？

Redis可以以多种方式进行部署，取决于应用的需求、规模和可用资源。以下是几种常见的Redis部署模式：

单机模式

在单机模式中，Redis运行在单个服务器上，作为一个独立的实例。这种部署模式适用于小型应用或者开发环境，具有简单、快速部署的优点。

主从模式

在主从模式中，Redis包含一个主节点和一个或多个从节点。主节点负责接收写操作并将数据同步到从节点，而从节点则负责复制主节点的数据，并且可以处理读请求。这种部署模式提高了系统的可用性和容错性，并且可以实现读写分离，提高读取性能。

哨兵模式

在哨兵模式中，通过使用Redis Sentinel来监控和管理多个Redis实例，实现自动故障转移和故障检测。Sentinel部署模式可以提高系统的可用性和容错性，适用于需要高可用性的生产环境。

集群模式

在 Redis 集群中，通过主从复制（Replication）、故障转移（Failover）和数据分片（Sharding）等机制来确保系统的稳定性和数据的持久性。下面是 Redis 集群高可用性的主要原理：

1. 数据分片

Redis 集群通过数据分片将键空间分割成多个槽（Slot），默认有 16384 个槽。每个键根据其哈希值映射到一个特定的槽上，从而将数据均匀地分布在不同的节点上。这种设计可以避免单点故障，即使某个节点发生故障，其他节点仍然可以继续提供服务。

2. 主从复制

在 Redis 集群中，每个主节点都有一个或多个从节点。从节点通过复制主节点的数据保持数据的一致性。这样，在主节点发生故障时，可以从节点中选择一个提升为主节点，以保证服务的连续性。

3. 故障转移

Redis 集群具有自动故障转移的能力。当一个主节点无法接收写操作时，集群会检测到该节点的故障，并自动从该主节点的从节点中选举出一个新的主节点，从而恢复集群的完整性和服务的可用性。这个过程是由集群中的其他节点通过 gossiper 协议（一种分布式系统中用于传播信息的协议）协作完成的。

四、Redis 两种持久化机制

RDB (Redis Database Backup) 和 AOF (Append Only File) 是 Redis 提供的两种持久化机制，RDB 是默认采用的机制。它们各自有着不同的特性和适用场景。以下是 RDB 和 AOF 的详细比较：

RDB 快照

优点：
恢复速度快： 由于 RDB 文件是一个数据集的快照，所以在 Redis 重启时，可以快速加载整个数据集，恢复速度较快。
占用资源少： RDB 在生成快照时，Redis 主进程会 fork() 一个子进程来处理快照的保存工作，这不会阻塞主线程，对在线服务的影响较小。
存储空间效率高： RDB 文件只包含快照时刻的数据集，没有历史操作记录，因此相比 AOF 文件，RDB 文件通常更小。
缺点：
数据安全性较低： 如果 Redis 在两次 RDB 快照之间发生故障，那么最后一次快照之后的数据将会丢失。
快照生成时机： RDB 快照的生成时机依赖于配置文件中的 save 规则，如果规则设置不当，可能会影响性能或数据安全性。

AOF 日志

优点：
数据安全性高： AOF 会记录每一次写操作，即使 Redis 在故障后重启，也可以通过重放 AOF 文件中的命令来恢复数据，理论上可以做到不丢失任何数据（取决于 fsync 设置）。
可配置的持久化级别： AOF 的 fsync 参数可以灵活设置，以权衡数据安全性和性能。例如，fsync 设置为 everysec 可以在保证较高数据安全性的同时，保持较好的写性能。
文件可读性强： AOF 文件内容是可读的 Redis 命令，便于人工检查和调试。
缺点：
文件体积大： AOF 文件会记录所有的写命令，因此它的文件体积通常比 RDB 文件大得多，这可能导致启动时的恢复时间较长。
恢复速度慢： 与 RDB 相比，AOF 在 Redis 启动时需要重放所有写命令，因此恢复速度较慢。
资源消耗： AOF 需要频繁写入磁盘，这可能会增加 I/O 负担，影响写性能。