"已知的东西； 有些事情我们知道我们知道。 我们也知道有未知的事物。 就是说我们知道有些事情我们不知道。 但是，还有未知的未知数-我们不知道的我们不知道的……后一类往往是困难的。"

唐纳德·拉姆斯菲尔德

> Redis Wikipedia Page Logo

我与Redis在一起已经有好几年了，从来没有真正遇到过任何问题。 我已经使用Redis计划和部署了大规模的Web服务，并使用了数十亿条日常读写命令(使用可上下伸缩的主从复制)，并且可以"正常工作"。 从开发人员的角度来看，这导致了我一个错误的假设，即我了解关于Redis所需的全部知识(而且，正如一位伟大的诗人所说，假设是所有问题的源头)。

当然，我不是DevOps工程师，也不知道Redis的所有细节(但我仍然不知道)，但是我觉得使用Redis被"发现"了。 其他服务(例如MySQL)迫使我对它们的概念有扎实的了解，以便编写快速高效的代码(再次，无需像DBA一样掌握MySQL，但至少您需要了解索引或JOIN才能快速编写代码 和高效的查询)。 但是使用Redis，我可以将其"即插即用"到我的代码中。

几周前，我被分配来解决在我们的一项旧服务中从Redis提取数据时的性能问题。 该服务的业务逻辑并不那么重要，但是对该服务的工作方式以及Redis的使用方式的总体概述将有助于我们理解问题所在以及最终如何解决。

我们拥有一个大型系统，可以存储由不同实体产生的数十亿每日事件。 查询实体事件可能很慢，并且在许多情况下是多余的，因为我们不需要所有数据。 这就是我们提供服务的地方-它提供了一个API，可以快速查询最近30天的实体唯一事件。

例如，假设有一个系统监视着带有传感器的空调，该传感器在每次AC状态发生变化(打开/关闭会更改AC状态以及改变温度)时发送事件。 一个AC状态每天可能会更改很多次，并且我们的系统将为每次更改存储一个事件，但是我们的服务仅会为过去30天内所做的每个更改返回一个事件(无论AC被翻转了多少次) ，我们的服务将返回单个"打开"事件)。

Redis快速，支持数据过期(我们只需要最近30天的事件，还记得吗？)，并且具有Set数据结构，是我们服务的理想存储：将同一项目多次添加到Set中将导致只有一个副本 此商品在套装中。 可以将存储在我们系统中的每个实体(AC)的数百万个不同事件转换为几十个唯一项(事件)的小集合。 我们的服务仅需要"侦听"传入的事件，并使用AC ID和日期作为键将它们存储到Redis中，并将到期时间设置为30天。 当查询AC事件时，我们的服务将计算所有此AC密钥并返回存储在这些密钥中的所有事件的并集。

Redis中存储的数据的一览视图如下所示：

: #{on, off, 24°, 28° ...}, expires 2019-10-30
: #{on, off, 25°, 27° ...}, expires 2019-10-29
: #{on, 26°, humidity 32° ...}, expires 2019-10-28
...
...
...
: #{off, humidity 35° ...}, expires 2019-10-01
: #{on, off, 23°, 27° ...}, expires 2019-10-30
: #{on, off, 25°, 28° ...}, expires 2019-10-29
...
...
...
: #{24°, 26°, humidity 42° ...}, expires 2019-10-01
: #{on, off, 23°, 27° ...}, expires 2019-10-30
...
...
...

密钥是具有事件收集日期的实体的ID。 ac1-2019-09-30代表id = ac1的实体，其值是该日期收集的一组事件。 该密钥将于2019–10–30到期。

在Redis内部，我们的服务使用SUNION命令来获取特定实体在不同日期存储的所有事件的联合集：

SUNION
...
...

这个简单的逻辑可以处理99.6％的查询。 但是，有时从Redis获取数据花费的时间很长(在某些情况下可能需要30秒)，这在产品上并不被接受。

我已经开始解决因搜索通用规则而导致的响应缓慢的问题，这并不奇怪，这通常发生在SUNION处理大型Set时(也并非总是如此)。 Redis中存储的大多数Set(基本代表元素数)的基数小于100。 但是对于少量的Set，大小可能会很大。 如您在下表中所见，有85％的组合有0–50个项目，少于0.5％的组合有1,000个或更多项目)

我在阅读服务代码时注意到的另一件事是，为了避免产生较大的响应负载，无论对服务进行编码的是谁，都对API返回的事件数量进行了限制(我们将在后面看到为什么这与 解决方案)。

了解我对Redis的了解后，使用SUNION命令似乎是一个合理的解决方案。 如果我是首先编写此服务的人，那么我可能会做同样的事情。 但是，您不知道的内容有时会造成很多痛苦……谷歌搜索很快发现了两个我对Redis不了解或不完全了解的事实：

· SUNION是一个缓慢的命令，采用两个大集合的交集可能会花费大量时间。 实际上，我在Redis官方文档中阅读它感到很惊讶，因为我一直认为Redis会一直保持快速。

· 从命令执行的角度来看，Redis主要是单线程服务器，这意味着当请求缓慢时，所有其他客户端将等待该请求得到处理。

了解问题是找到正确解决方案的一半。 我意识到SUNION并不是我需要的命令，但是有哪些替代方案？ 好吧，感谢Google和Redis.io文档，我遇到了SSCAN命令。 SSCAN命令(实际上，Redis中有针对不同数据类型的一堆不同的SCAN命令)允许在Set上进行增量迭代，每次调用仅返回少量元素。 可以使用它而不会受到诸如SMEMBERS或SUNION之类的命令的负面影响，这些命令在针对大型集合进行调用时可能会长时间阻塞服务器。

请注意，SSCAN在一个集合上完全迭代的时间复杂度为O(N)，其中N是集合基数。 对于SMEMBERS来说，这也是命令的复杂性，但是如果您还记得，我还说过我们的服务对从其API返回的商品数量有一定的限制。 由于一旦达到此限制就可以中断SSCAN迭代，因此我们的时间复杂度实际上将是O(Min(N，Limit))，这是SUNION的要求，它将始终从Redis(和我们的服务逻辑)中提取数据 将对整个项目集合中返回的项目数设置限制)

到目前为止，一切都很好，但是在SUNION上使用SSCAN可能会有不利的一面吗？ 好吧，可能存在—尽管像SUNION这样的阻塞命令可以保证在给定的时间内提供集合中的所有元素，但是SSCAN命令只能提供有限的保证，因为集合可以在迭代过程中进行更改。 在完整的SSCAN迭代过程中，集合中不存在的元素可能会返回，也可能不会返回：它是未定义的。 但是，考虑到我们不会从Redis中删除项目(只是添加新项目)，因此这并不是我们服务中的真正问题。

确实运行了一些基准测试可以测试SSCAN(仅提取有限数量的项目)与SUNION提取所有数据，并且它们以编程方式仅从中提取第一个有限的项目，这显示出明显的改进。 对于小型Set，时间大致相同，但是对于具有1,000多个项目的大型Set，时间要好得多

繁荣！ 问题解决了。 从这个过程中我得出什么结论？ -可以说我们需要更好地了解我们的知识，但是在现实生活中，我们在日常工作中使用许多不同的服务和程序包(数据库，云服务，开源程序包等)，而这几乎是不可能的 掌握所有这些知识(不仅仅是性能，请考虑其中一些软件包可能存在的安全性问题)。

但是，我们至少应该尝试掌握我们所依赖的服务，这些软件包会对我们的服务产生巨大影响。

(本文翻译自Tzafrir Ben Ami的文章《What I didn't know I didn't know about Redis》，参考：https://medium.com/swlh/what-i-didnt-know-i-didn-t-know-about-redis-6ad3729f29ed)