视频

了解更多
下载《九项基本数据库能力》,确保您的数据库具备满足所有需求的能力
使用 Redis 开发应用程序非常有趣,但与任何技术一样,在设计基于 Redis 或 Redis 命名空间的应用程序时,您应该牢记一些要点。 您可能已经熟悉关系数据库开发,但虽然许多相同的实践都适用,但请记住 Redis 是一个内存数据库,并且(主要)是单线程的。 请继续阅读以探索 Redis 密钥的最佳实践。
因此,使用 Redis 时,您应该注意几个特点
数据库存储数据,但是任何开发人员都可能忽略放入 Redis 中的某些数据。 这很自然,因为您的应用程序的需求发生变化或者您更改了存储数据的方式。 也许您忽略了 EXPIRE 某些键,或者应用程序的某个模块已停用。
无论如何,您的 Redis 数据库中的某些数据可能不再使用,并且无目的地占用空间。 Redis 的无模式性质使得除非您为键使用可靠的命名法,否则极难理解数据集的内容。 使用适当的命名方法以及 Redis 命名空间作为键可以使数据库的内务管理更加容易。 当您按应用程序或服务命名键时 – 约定是使用冒号(‘:’)字符来分隔键名称的各个部分 – 这是 Redis 命名空间的最佳实践。 这样,您就可以在数据迁移、转换、删除或移动期间轻松识别它们。 Redis 命名空间和 Redis 命名空间键有助于这种识别。
除了 Redis 命名空间之外,Redis 的另一个常见用例是作为“热”数据项的二级数据存储,而大多数数据都保存在另一个数据库中(例如 PostgreSQL、MongoDB)。 在这种情况下,开发人员经常忘记在从主数据存储中删除数据时从 Redis 中删除数据。 这种跨数据存储依赖性需要级联删除,可以通过将给定数据项的所有标识符保存在 Redis 集合中来实现。 这确保了在从主数据存储中删除后调用的清理程序只需要迭代该集合的内容,才能删除所有相关的副本和相关信息(包括完成后的集合本身)。
这似乎与上面关于 Redis 命名空间的内容相矛盾,但由于键名也会占用内存,因此您应该努力使它们保持简短。 显然,这对于包含数百万或数十亿个键的数据集来说是一个问题,但事实是,长键在任何哈希表中都有代价。
例如:考虑存储 1,000,000 个带有 Redis 命名空间的键,每个键都设置为 32 个字符的值,当使用 6 个字符的键名时,将消耗大约 96MB,而使用 12 个字符的键名时,将消耗 111MB(在 32 位 Redis 服务器上)。 随着键的数量的增加,超过 15% 的这种开销变得非常显着。 使用 Redis 删除具有前缀的键也是可能的。
无论是出于内存使用还是性能的原因,有时一种数据结构比另一种数据结构更适合您的数据集。 以下是一些需要牢记的最佳实践
不要将数据存储在数千个(或数百万个)独立的字符串值中,而应考虑使用哈希数据结构对相关数据进行分组。 哈希非常高效,可以减少内存使用(此外,它们还提供了一些抽象细节并使代码更具可读性的附加值)。 有关更多信息,请查看此文章。
如果适用,请使用列表而不是集合。 如果您不需要集合的属性来确保唯一性或检查成员资格,则列表将消耗更少的内存并更快地执行插入。
就内存消耗和基本操作复杂性而言(例如 ZADDing 新成员),排序集是最昂贵的数据结构。 如果您只需要一种查找分数的方法并且顺序并不重要,请考虑改用哈希。
Redis 中经常被忽略的一个功能是位图或位集(自 v2.2 起可用)。 位集允许您对 Redis 值执行多个位级操作,这意味着可以有效地存储大量数据。 例如,这可以用于一些轻量级分析。
SCAN命令从 Redis v2.8 开始可用,使您可以使用游标检索键空间中的键。 此行为与 (hiss) KEYS 命令不同,后者一次返回所有匹配的元素,但在生产中被认为是危险的,因为它可能会阻塞您的 Redis 服务器甚至耗尽其 RAM 资源。 另一方面,SCAN 可以在不冒阻塞服务器的风险或不必依赖从属服务器的情况下检查数据。
请注意,SCAN 要求您读取一个游标值,该游标值会传递给对 SCAN 的后续调用。 SCAN 还接受键名模式和一个可选的计数参数。 SCAN 和 KEYS 之间的另一个区别是,使用 SCAN 可能会多次获得相同的键名。
SCAN 附带 SSCAN、HSCAN 和 ZSCAN,它们允许您迭代集合、哈希和排序集的内容(分别)。
作为一名开发人员,一旦您接受 Redis 运行 Lua 脚本的能力,您将进入熟悉的领域。 Lua 是一种最容易学习的语言之一,它使您能够通过在 Redis 服务器本身内部运行的代码来表达您的创造力。 如果应用正确,Lua 脚本可以在性能和资源消耗方面发挥重要作用。 脚本允许您在数据附近执行逻辑,而不是将数据带到(应用程序的)CPU,这减少了网络延迟和数据的冗余传输。
Lua 的显着影响的一个经典例子是,当您从 Redis 中获取大量数据只是为了在应用程序中对其进行过滤或聚合时。 通过将处理工作流程封装在脚本中,您只需要调用它即可在很短的时间内和资源消耗下获得显着更小的答案。
专家提示: Lua 很棒,但是一旦您将工作流程转移到它,您可能会发现错误报告和处理更加困难(毕竟,您是在 Redis 服务器内部运行)。 解决这个问题的一种聪明方法是使用 Redis 的 Pub/Sub,让您的脚本将其“日志”消息发布到专用频道。 然后,设置一个订阅者进程来获取这些消息并相应地处理它们。
在您的 Redis 冒险之旅中,您可能会获得许多其他重要提示,但此列表应有助于您开始使用一些最重要的提示。 如果您有其他想要分享的建议、反馈或问题 – 请随时吼叫在我,我随时待命🙂