如果 Redis 是单线程的，怎么会这么快？答案

【问题标题】：If Redis is single Threaded, how can it be so fast?如果 Redis 是单线程的，怎么会这么快？
【发布时间】：2018-06-10 15:56:42
【问题描述】：

我目前正在尝试了解 Redis 的一些基本实现。我知道redis是单线程的，我已经偶然发现了以下问题：Redis is single-threaded, then how does it do concurrent I/O?

但我仍然认为我没有正确理解它。 Afaik Redis 使用一个单线程的反应器模式。因此，如果我理解这一点，就会有一个观察者（处理 FD/传入/传出连接）将要完成的工作委托给它的已注册事件处理程序。他们做实际的工作并设置例如。他们的响应作为事件发送给观察者，观察者将响应传回给客户端。但是，如果客户端的请求 (R1) 需要大约 1 分钟会发生什么。另一个客户端创建另一个（快速）请求（R2）。然后 - 由于 redis 是单线程的 - 在 R1 完成之前，不能将 R2 委托给正确的处理程序，对吗？在多线程环境中，您可以只在单个线程中启动每个处理程序，因此“主”线程只是接受和响应 io 连接，所有其他工作都在自己的线程中执行。

如果它真的只是对 io 处理和处理程序逻辑进行排队，它永远不会这么快。我在这里错过了什么？

【问题讨论】：

标签： multithreading redis reactor single-threaded

【解决方案1】：

除了 Redis 中的大多数操作在不到 ~ 毫秒 ~ 几微秒内完成这一事实之外，您并没有错过任何东西。长时间运行的操作在执行期间确实会阻塞服务器。

【讨论】：

有点吹毛求疵，我尊敬的同事 - 大多数 redis 操作的内部运行时间都在几微秒内完成，毫秒包括网络往返，其中 CPU 的影响为零。
感谢您的回答！因此，例如，如果我只使用数百万个客户端同时请求的一个 redis 实例（无复制，无主从），最后一个客户端必须等到所有其他请求完成，对吗？我知道redis很容易复制，但只是为了我的理解。
"last" 是一个模糊的概念，但基本上是的 - 一个操作在任何给定的（微）瞬间执行，所有其他操作都处于待处理状态。
太好了，谢谢！我知道这是一个非常模糊的概念，但它帮助我理解我走在正确的道路上；）

【解决方案2】：

假设有 10,000 个用户在 hmget 上以 10 秒的时间进行实时数据拉取，而另一方面，服务器正在使用 hmset 进行广播，redis 只能在最后一个可用队列发出集合。

Redis 仅适用于排队和处理有限的处理，例如插入延迟上次登录信息，但不适用于实时信息广播，在这种情况下，memcached 将是正确的选择。 Redis 是单线程的，类似于 FIFO。

【讨论】：