“最佳实践”已成为技术的一种比喻。当然，您可以使用给定的工具执行某些操作，但使用这个工具真的是个好主意吗？这个话题一次又一次出现说明了我们使用工具的灵活性。最佳实践非常适合初学者从一开始就学习正确的东西。问题是，有时候，作为软件工程师，我们对这些最佳实践的记忆并不完善。一些时候我们没有阅读文档说明，只是按部就班的把事情做完，而不经意地使用了最困难的方式来做这件事。

因此，让我们采用另一种方法：让我们着眼于最坏的做法，而不是研究最佳做法。我们已经看到客户，开源用户，甚至工具实现方式会引起其他人的反对。当然，我们以前没有聚焦到这种想法，所以让我们从七种 Redis “错误做法”开始。

1.无密码

基于我在网上看到的大量代码示例（甚至可能是几年前我自己的），很多人都不会为自己的 Redis 实例设置密码。这在当前版本的 Redis 中，尽管不是一个好的做法，您必须在 redis.conf 中做很多配置工作，才可以向整个 Internet 开放一个无密码的 Redis 实例。但是，较旧的版本确实允许这种做法。为什么不设置密码不是一个好的做法？没有密码，服务器将会暴露给别人。一旦别人找到你的服务器，就会发生各种各样的问题，从清空数据库到通过运行高复杂度命令阻塞 Redis，一直到更改配置文件（通过CONFIG SET / GET）。

问题：没有密码服务器会被匿名访问。

最佳实践的替代方法：设置密码并使用AUTH命令进行用户验证。

2.keys

奇怪的是，KEYS 是人们在 Redis 中学习的第一个命令之一，即使使用起来很糟糕（在生产环境中）。对于不太了解 KEYS 的人，这条命令会对给定数据库中的所有键（或键模式）进行完整的遍历。当然，这可能很有用，尤其是对于调试而言，如果键的数量很少，那么就没什么大不了的。但是，KEYS 可能会成为服务扩展的隐藏杀手。考虑以下四个事实：

1.Redis 是（出于实用目的）单线程服务

2.Redis 可以容纳 232 个键

3.键（非值）最大为 512MB

4.KEYS 是 O（n）操作。

因此，当您有数十个键时，编写依赖于 KEYS 的应用程序就可以了-但是随着越来越多的键，此操作花费的时间越来越长。在这段时间里，Redis 只会进行数据库中的 KEYS 命令操作。想象一下必须遍历 4,294,967,295 个键，您会理解在这种情况下为什么 redis 不会很快。最后，KEYS 是一个同步命令，因此建立所有这些键的响应（特别是如果它们是大键）将需要一段时间，更不用说通过网络传输所花费的时间了。

问题：Redis 存储的数据变得比您预期的更大，并且 KEYS 可能长时间阻塞您的Redis 服务器。

最佳实践的替代方案：使用 SCAN，它将迭代分散到多次调用中，而不一次占用整个服务器。

3.带编号数据库/ SELECT

Redis 的作者 Salvatore Sanfilippo 曾将编号数据库称为他在 Redis 中犯下的最严重的设计错误。这种设计选择是看起来像做了某件事但实际上却做了另一件事。值得庆幸的是，尽管这种使用方式变得不那么普遍了，但 Redis 仍保有使用 SELECT 命令在不同数据库之间切换的功能。每个数据库都是从键的角度来说是隔离的。因此，数据库 0 上的键foo：bar 可以与数据库 9 上的 foo：bar 完全不同。这听起来很不错，对吧？问题在于这些数据库没有以任何其他方式隔离。在数据库 0 上运行 KEYS 命令仍会阻塞数据库 9 上的操作。实际上，您似乎可以在每个数据库上运行独立的工作负载，但实际上它们并不是完全独立的。

简直是不可理喻，但这不是最糟糕的实践，对吗？嗯，问题在于整个 redis 生态系统中都没有很好地支持带编号数据库。编号数据库第一个也是最重要的缺点是任何 redis 集群系统（开源或 Redis Enterprise 集群）都不支持它们。实际上，您将永远无法离开 Redis 的单个节点去使用带编号数据库。另外，某些 redis 模块也不支持编号数据库。

问题：编号的数据库无法做到您认为的那样，可以提高系统的可扩展性。

最佳实践替代方案：运行 Redis 的隔离实例-它的开销很低，所以为什么不呢？如果您正在运行 Redis Enterprise，则默认情况下数据库是隔离的/多租户的。

4. 不限制返回长度的 HGETALL，LRANGE，SMEMBERS和ZRANGE

这些命令归为一个有趣的类：在大多数情况下是有用的且不会带来任何问题的，但在其他时候却会带来意想不到的问题。Redis 中的哈希数据结构允许您在一个键下设置一系列键 / 值对 -HGETALL 是一个简单的命令，可让您一次检索哈希中的所有内容。很好，因为在大多数情况下，您最多要处理三位数个数的字段。像键一样，每个哈希可以有 232 个键和值。在大多数情况下，您不会使用这么多键值，但是在某些情况下，因为代码本身（或逻辑错误），您可以生成大量的键和值，从而随着时间的推移增加键的数量。然后，您运行 HGETALL 并返回成千上万个键和值，每个字段和值可能高达 512MB，这意味着您实际上遇到了与 KEYS 相同的问题。

LRANGE 的情况可能更糟。LRANGE 从给定范围内的列表中获取对象；要获得LRANGE 0 -1 的所有项就可以了。Redis 中的列表是链表，这意味着必须依次访问每个对象（以获取指向下一个对象的指针）。到目前为止，您可能已经猜到最大为 232 个对象（每个对象最大为 512MB），并且您可以累积非常多的对象。如果您将“列表”用作队列，那么让工作节点离线几分钟会导致列表的大小快速增长。

“有序集合”和“集合”中的问题也大致相同。它们可以存储大量数据，每个数据量可能非常大。当您请求所有这些数据时，这可能会花费一些时间。

问题：Redis 可以存储非常大的数据结构。除非您知道结果的大小，否则最大数为232。

最佳实践的替代方法：运行一个命令来检查数据结构的大小（HLEN（哈希），LLEN（列表），SCARD（集合）和 ZCARD（有序集合））。

5.每个连接一个请求

许多数据库使用 REST 的概念作为主要接口，将 POST HTTP 请求发送到相对应的端口。数据库获取信息，返回对应的状态码，并关闭连接。Redis 应该以不同的方式使用----连接应该是持久的，并且您应该根据需要向长连接提出请求。但是，无恶意的开发人员有时会创建连接，运行命令并关闭连接。从技术上讲，打开和关闭每个命令的连接没有问题，但这远非最佳，而且不必要地降低了 Redis 的整体性能。

使用 OSS 集群 API，客户端可以根据需要维护与节点的连接，因此您可以在任意给定时间向不同节点打开多个连接。使用 Redis Enterprise，连接实际上是到代理节点的，它可以解决集群级别连接的复杂性。

问题：Redis 连接旨在运行多个操作中一直保持开启状态。

最佳实践替代方案：使用同样的连接运行多个命令。

6.热键

Redis 很容易成为保存您的应用程序中的运营数据，有价值且经常访问的信息的核心。但是，如果将访问集中到经常访问的几条数据中，则会创建所谓的热键问题。在 Redis 集群中，键实际上关联数据在集群中存储位置。数据基于键的哈希值而存储在一个单一的位置中。因此，当您一次又一次地访问单个键时，实际上是一次又一次地访问单个节点/分片。让我们换一种说法：如果您有一个 99 个节点的集群，并且您的单个键在一秒钟内可以收到一百万个请求，那么所有这些请求将全部发送到一个节点，而不会分散到其他 98 个节点上。

Redis甚至提供工具来查找您的热键所在的位置。将 redis-cli 与 –hotkeys 参数一起使用，以及需要连接的任何其他参数：

$ redis-cli --hotkeys

问题：请勿创建少量经常访问的键。

最佳实践替代方案：避免这个问题的最佳方法是尽可能避免这种情况发生。将数据写入在不同分片中的多个键将使您可以避免更频繁地访问相同的数据。

7.将无持久化的 Redis 实例作为主数据库运行

Redis 通常用作应用程序的主要存储引擎。与将 Redis 用作缓存不同，将 Redis 用作主数据库需要开启两个额外的功能才能有效。任何主数据库都应该真正具有高可用性。如果缓存出现故障，则通常您的应用程序处于限速状态。如果主数据库出现故障，您的应用程序也会发生故障。同样，如果缓存发生故障而您将其重新启动并清空，则没什么大不了的。但是，对于主数据库而言，这是非常严重的问题。Redis 可以轻松处理这些情况，但是与作为缓存运行相比，它们通常需要不同的配置。

问题：Redis 作为主数据库是一个很好的选择，但是您必须通过启用正确的功能来支持它。

最佳实践的选择：使用 Redis 开源版本的时候，您需要设置 Redis Sentinel 以获得高可用的特性。在 Redis Enterprise 中，它则是一项核心功能，您只需在创建数据库时将其配置打开即可。关于持久性，Redis Enterprise 和开源 Redis 都通过 AOF 或快照（snapshotting）提供持久性支持，因此您的实例会在你不使用的时候开始备份。

在这里我们介绍了 Redis 的七个错误用法。我们是否涵盖了所有错误用法？当然不是。随时关注我们的博客或注册 Redis Watch 时事通讯，以发现更多您绝对不想在使用 Redis 时候做的事情。