【面试】Redis6.0 之前为什么一直不使用多线程？

原创已于 2024-11-04 13:07:53 修改 · 1k 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#面试 #职场和发展 #java #数据库 #后端 #redis #spring boot

于 2024-11-04 12:20:56 首次发布

面试宝典专栏收录该内容

25 篇文章

订阅专栏

一、Redis6.0 之前单线程主要原因

在使用 Redis 的过程中，CPU 不是瓶颈，受制于内存和网络
如果要提高 Redis 的性能，可以使用 Pipeline（命令的批量处理），这时可以轻松处理每秒 100万个请求
单线程 Redis 内部维护成本比较低
如果引入多线程，需要考虑线程的切换、共享数据的安全问题（加锁/释放锁，可能会出现死锁）
惰性的 ReHash（渐进式的 ReHash），防止阻塞，有些命令不能在无锁的情况下执行
根本原因：对于一般的公司，单线程的 Redis 足够使用

Redis 在 6.0 版本之前一直采用单线程架构，这是因为 Redis 主要是内存操作，单线程模型足以应对大部分高性能场景。而单线程模型的优势在于避免了多线程带来的上下文切换和锁的开销，使得 Redis 保持极高的性能和简单性。

题外话：我们现在要仔细的说一说I/O多路复用机制，因为这个说法实在是太通俗了，通俗到一般人都不懂是什么意思。博主打一个比方：小曲在S城开了一家快递店，负责同城快送服务。小曲因为资金限制，雇佣了一批快递员，然后小曲发现资金不够了，只够买一辆车送快递。

经营方式一
客户每送来一份快递，小曲就让一个快递员盯着，然后快递员开车去送快递。慢慢的小曲就发现了这种经营方式存在下述问题

几十个快递员基本上时间都花在了抢车上了，大部分快递员都处在闲置状态，谁抢到了车，谁就能去送快递
随着快递的增多，快递员也越来越多，小曲发现快递店里越来越挤，没办法雇佣新的快递员了
快递员之间的协调很花时间

综合上述缺点，小曲痛定思痛，提出了下面的经营方式
经营方式二
小曲只雇佣一个快递员。然后呢，客户送来的快递，小曲按送达地点标注好，然后依次放在一个地方。最后，那个快递员依次的去取快递，一次拿一个，然后开着车去送快递，送好了就回来拿下一个快递。

对比结果
上述两种经营方式对比，是不是明显觉得第二种，效率更高，更好呢。在上述比喻中:

每个快递员------------------>每个线程
每个快递-------------------->每个socket(I/O流)
快递的送达地点-------------->socket的不同状态
客户送快递请求-------------->来自客户端的请求
小曲的经营方式-------------->服务端运行的代码
一辆车---------------------->CPU的核数

于是我们有如下结论
1、经营方式一就是传统的并发模型，每个I/O流(快递)都有一个新的线程(快递员)管理。
2、经营方式二就是I/O多路复用。只有单个线程(一个快递员)，通过跟踪每个I/O流的状态(每个快递的送达地点)，来管理多个I/O流。

二、Redis 在 6.0 以后

随着 Redis 被广泛应用于更复杂的场景，尤其是在处理网络 I/O 密集型任务时，单线程的局限性逐渐显现。为了更好地应对这些情况，Redis 从 6.0 版本开始引入了多线程支持，但主要用于优化特定操作。具体原因如下：

1. 网络 I/O 和 CPU 密集型任务的分离
Redis 的性能瓶颈通常不是 CPU，而是网络 I/O 的处理。例如，处理大量连接、发送和接收大量数据包时，单线程需要同步处理每个连接的 I/O 操作，这会影响整体的吞吐量。引入多线程后，Redis 可以在多线程中处理 I/O 操作，如接受客户端请求、解析数据和发送响应，而保持数据操作仍然是单线程处理，这避免了复杂的并发控制。

2. 提高网络性能
Redis 6.0 的多线程模式将网络 I/O部分分摊给多个线程执行，这样多个客户端的 I/O 操作可以并行处理，减少了请求排队等待时间，提高了在高并发场景下的响应能力。

3. 保持数据一致性的简单性
尽管 Redis 6.0 引入了多线程，但它仍然保持数据操作（如读写数据）的单线程模型。这样可以避免复杂的多线程并发问题和锁机制带来的性能损耗。通过这种设计，Redis 既能提升 I/O 处理能力，又不会影响核心数据的简单性和一致性。

4. 提升大数据量处理的效率
对于大批量数据的序列化和反序列化操作（如 AOF 日志写入和 RDB 快照生成），多线程可以显著提高效率。这些操作在单线程下可能会拖慢 Redis 的性能，而多线程则可以让这些任务并发执行，减少阻塞。

小结
Redis 6.0 引入多线程是为了优化网络 I/O和批量数据处理的性能，而核心的数据操作依然保持单线程模型，以确保简单性和一致性。这种设计在不引入多线程锁复杂性的情况下，极大提升了高并发场景下的性能。

在引入多线程后，如何解决并发带来的线程安全问题呢
在 Redis 6.0 引入多线程后，为了解决并发带来的线程安全问题，采用了以下几种策略和设计原则：

1. 数据操作仍然是单线程
Redis 的核心数据操作（如读写数据）仍然是在单线程中进行的。这意味着所有对数据的修改（如 SET、GET、DELETE 等操作）依然是串行化处理的。这样可以保证数据的一致性和完整性，避免并发修改导致的数据竞争和不一致问题。
2. I/O 多线程处理
Redis 6.0 中的多线程主要用于处理网络 I/O，而不是数据操作。这意味着多个线程可以并行处理客户端的请求、接收和发送数据，从而提升网络处理能力。I/O 操作和数据操作是分开的，这样在 I/O 线程中发生的操作不会影响到数据的一致性。