Redis面试题——恕我无能只写到了第十个就写不下不去，我相信你们也看不下去了，这会已经一万五千字了，等后续有精力在补全吧

系列文章目录

Redis——面试+思想+应用

---

问题：
Redis为什么是单线程的？
Redis使用的多路I/O复用技术是什么？
Redis是如何实现持久化的？
RDB（Redis数据库）持久化
AOF（Append Only File）持久化
Redis的数据是如何存储在内存中的？
如何保证Redis的数据一致性？
Redis的过期键是如何处理的？
Redis是如何进行内存管理的？
Redis的发布/订阅（pub/sub）模型是怎样的？
Redis支持的数据复制（Replication）机制是什么样的？
Redis的同步和异步复制有何区别？
Redis集群是如何工作的？
分片（Sharding）
一致性哈希（Consistent Hashing）
Redis如何实现高可用性？
哨兵（Sentinel）系统
Redis集群中的主从切换
Redis支持的数据类型及其底层实现是什么？
Redis的网络模型是怎样的？
Redis的阻塞与非阻塞操作有哪些？
Redis对于事务的支持和限制？
Lua脚本在Redis中有什么用途？
如何进行Redis的性能调优？
Redis与其他类型数据库相比，其优缺点是什么？
Redis的客户端连接池是如何管理的？
Redis雪崩、穿透和击穿的问题是什么？
Redis和缓存失效策略（包括LRU缓存淘汰）。
Redis中的事务、流水线（Pipelining）以及它们的使用场景。
Redis的线程模型和对多核处理器的利用。
Redis的安全机制，包括认证和加密。

前言

提示：这里可以添加本文要记录的大概内容：

我只能说任重道远，慢慢学习吧，有些问题真的仅仅是为面试准备的，毕竟用其实用的也仅仅是一部分，再就是Redis是用C语言写的，对于java来讲算是黑盒，一点也不为过，但是呢面试需要，有些知识得学一学。
我真的是不想整理这个，主要是有的我也不是很了解。

时间：2024-02-06 下午四点：我现在分析了第10个问题，我真的不想分析了，我就感觉想吐我得缓缓才分析，实在是太多了，各位要是看请耐下心来，在不直接去看官网吧。
https://redis.io/
http://www.redis.cn/
https://www.redis.net.cn/

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、Redis为什么是单线程的？

Redis单线程的原因：

性能：

Redis将所有数据存储在内存中，访问内存的速度非常快，没有网络延迟。因此，即便在单线程下，它也能以极高的速度进行操作。对于一个内存系统来说，瓶颈通常在于内存的速度，而非CPU的速度。

简化设计：

单线程模型简化了Redis的设计和实现，因为它避免了线程间的同步和锁的问题，极大地降低了复杂性。在多线程环境中，需要考虑数据竞争、锁死、死锁等多线程并发问题。单线程就不存在这些问题，因此Redis可以高效且稳定地运行。

非阻塞I/O：

Redis使用多路复用技术进行非阻塞I/O操作（例如，select、poll或epoll等）。这意味着Redis可以同时处理多个网络连接请求，而无需为每个连接分配独立的线程或进程。

操作原子性：

在Redis中，所有的操作都是原子性的，意味着每个命令在执行期间都不会被其他命令打断。确保了数据的一致性无需通过锁来实现。

优化的事件处理：

Redis采用事件驱动模型，它有一个中央循环负责接收所有客户端的命令请求，然后逐一执行。这种响应方式与Java中的单线程事件监听模型很相似，都是为了简化对同时发生的多个事件的处理。

从Java开发的角度来讲，你可以将Redis的单线程和Java应用中类似的设计概念联系起来。
例如，传统的Servlet中的单线程模型 vs Servlet 3.1+的非阻塞I/O模型，或者Java NIO中的单线程Reactor模式。甚至可以更深入地对比Java虚拟机中的单线程运行环境以及内存管理策略。

总之

即使Redis是单线程的，但由于它的速度极快，通常这个单线程都能够非常有效地使用CPU资源。从Java的角度讲，开发者往往利用利用线程池以及非阻塞I/O来实现类似的高效任务处理模型。在这种背景下，理解Redis单线程模型及其对性能的影响，有助于深入理解并设计高并发、高可用性的Java系统。

Q:Redis是单线程吗？

A：No

通常当人们说“Redis是单线程的”，他们指的是Redis的主事件循环是单线程的，这个循环负责处理所有的客户端请求和数据命令。但是，Redis的其他某些操作并不是单线程的。

以下是一些Redis的非单线程方面：

持久化：

1、Redis在执行快照（RDB持久化）时，会使用fork()系统调用创建一个子进程
来将内存数据写入磁盘，这样主线程在此过程中可以继续处理客户端请求。
2、AOF（Append Only File）重写操作也是在一个单独的子进程中执行，
以减少对主线程的影响。

复制：

Redis的复制功能，如将数据同步到从节点，也是在后台线程中进行的。
主线程不负责网络数据的发送，确保命令处理的性能不受影响。

键过期和内存清理：

Redis引入了惰性删除和定期删除策略来处理键的过期，在这些操作中可能会使用后台任务。
Redis的内存回收，使用了类似于后台线程的机制执行定期的内存清理。

模块系统：

Redis 4.0及其以上版本支持模块系统，这些模块可以按自己的方式使用多线程。
例如，RediSearch就能够利用多线程来提高搜索的效率。

集群消息传播：

在Redis集群中，每个节点同时作为客户端和服务器，用于处理命令请求和消息传递。
这涉及到并行的网络连接处理。

客户端输入缓冲：

在某些情况下，Redis会在后台线程中处理大的I/O操作，如处理大的客户端输入缓冲。

因此

一方面Redis的主要操作模型是基于单线程的高效事件处理机制，另一方面Redis也使用了多进程和后台线程来优化特定任务，提高整体性能和效率。这种设计使Redis在绝大多数情况下效率非常高，同时当需要执行诸如持久化这样的重量级任务时，也不会阻塞主线程的处理。在现代版本的Redis中，也增加了对I/O线程的支持，允许并发执行网络I/O操作，进一步提高性能。
这在配置时可以通过io-threads选项来启用。

二、Redis使用的多路I/O复用技术是什么？

多路I/O复用技术使得单个线程可以监视多个网络连接的I/O事件。
这种机制允许服务器同时处理许多并发连接，而不是为每个连接创建新的线程或进程。
这对于处理大量的同时套接字连接，如Redis服务器所需处理的数目，非常必要。

Redis赖于操作系统提供的I/O复用系统调用，最常见的有以下几种：

1、select:

这是最早的I/O复用技术，由于其可移植性极高，几乎支持所有的操作系统。
它允许应用监视一个文件描述符集合，等待其中一个或多个描述符成为"就绪"状态。
然而，select通常有最大文件描述符数量的限制，并且其性能会随着监视的文件描述符数量增加而线性递减。

2、poll:

poll与select在API上很相似，但是它没有最大文件描述符数量的限制。这提供了对更大数量的并发连接的支持。

3、epoll:

这是Linux特有的I/O复用解决方案，提供了比select和poll更好的性能。
与select和poll需要遍历整个文件描述符集不同，epoll能够告诉应用程序哪些文件描述符刚刚发生了事件，从而减少资源消耗，并能够处理更多的并发连接。

4、kqueue:

类似于epoll，但这是在BSD系统，包括macOS上的I/O复用技术。

Redis根据它所在的操作系统环境选择最适合的I/O复用技术。这些系统调用的核心作用是让Redis能够使用单线程高效地处理数以万计的同时连接，同时避免上下文切换和线程同步带来的开销。

从Java的角度来看，这与Java NIO（New I/O）中的Selector类相似。Selector是Java多路复用I/O的核心，允许单个线程监视多个通道（Channel），并检查它们是否有数据可读、可写或已经准备好进行某些I/O操作。
这一点在编写高性能的网络服务器时非常有用，可以在Java NIO中使用Selector来构建类似Redis这样的高性能网络服务。通过这样的对比，可以展示您对两个领域技术的深入理解以及如何在Java环境中应用这些知识。

补充–通俗描述

想象一下你是一位厨师，在一个开放式厨房里独自工作，而厨房周围有很多顾客在等待你端上美食。每个顾客的订单都是一个需要处理的任务。如果像传统厨房一样，每做一道菜你都要全身心投入，直到完成后才注意到下一个订单，那效率会非常低下，尤其是在所有顾客都很急的情况下。
多路I/O复用就像是你拥有一个神奇的耳朵，能够倾听每个顾客什么时候需要你的关注。这样，你就不需要在每个顾客之间走来走去，询问他们是否准备好了。相反，你只需在一个顾客准备好点菜时立刻得到通知，然后再开始准备菜肴。这样你就能更有效率地处理更多的订单。
在Redis中，这个神奇的耳朵就是操作系统提供的多路复用技术。Redis使用它来监听网络中所有客户端的消息。当任何客户端准备好发送指令时，多路复用技术会告诉Redis，“嘿，这边有活要干了！”然后Redis就可以去处理它，而整个时间内，Redis只需要一个工作线程（就是我们说的“单线程”）。因此，即便是成千上万的客户端同时发送消息，Redis也能一一应对，而且