Redis 8 来了——而且是开源的
了解更多
分享Redis 是一个简单但功能强大的内存数据库平台，其用例范围从会话管理、队列和发布/订阅到通用缓存。凭借其 持久性和内存复制功能，Redis Enterprise 也被用作主数据存储。
作为一名自由职业者，我经常使用 Redis 来克服独特的问题。在一个项目中，我们的用例很简单：我想复制文件系统分区的内容，该分区具有固定的、定义明确的结构：在文件系统的根目录下，我们有一组固定的目录，每个目录包含超过一百万个文件。我们之前的解决方案并行运行两个进程，24/7 来识别修改过的文件。第一个进程扫描所有文件内容，并识别自上次复制以来更改的内容。一个作业每 24 小时运行一次，以复制更改的文件。第二个进程索引所有已成功复制的文件。
在我们之前的解决方案中，我们使用 SQL 数据库来存储文件元数据（例如名称、大小、权限、路径等）以及所有与修改文件相关的信息。计划的复制作业查询数据库以提取已修改的文件列表，然后将内容复制到远程服务器。复制后，它更新 SQL 数据库，将文件标记为“已复制”，之后索引过程会拾取标记列表以索引文件内容。
我们之前的设计存在重大缺点：我们必须编写大量代码才能在 SQL 数据库中保存/检索/修改数据，并且随着数据库的增长，我们必须构建一种机制来修剪数据。随着运营开销变得巨大，我们开始寻找摆脱这种架构的方法。
那时我们发现了 Redis。 Redis 立即解决了我们的许多问题。 在我们的新解决方案中，我们使用 Redis 发布/订阅功能来通知我们的各种进程有关新检测的信息。 扫描过程将更改的文件详细信息发布到 Redis 频道。 复制过程订阅该频道，并在收到通知后立即复制该文件。 然后复制过程通知索引过程（通过另一个 Redis 发布/订阅频道）。 该系统无需每天运行一次作业，而是将复制作为正在进行的过程运行。 我们还省去了清理 SQL 数据库的麻烦！
在考虑 Redis 发布/订阅模型之前，我们还考虑了 RabbitMQ、Kafka 等。 每个都很好，但需要在我们这边做很多工作，并需要一些学习曲线。 没有一个像 Redis 那样通用且易于使用。
随着我们采用 Redis，我们发现了它的许多其他优势。 我们开始使用内置的数据结构（例如列表、哈希和集合）来执行分析。 例如，我们想知道文件和目录更改的频率，以及哪些应用程序进行了这些更改。 我们使用 Redis 及其数据结构来收集此信息。 然后，我们将其传递给索引过程，并使用分析数据丰富索引的元数据。
入门 Redis 非常简单。 您可以在以下位置免费注册 Redis Cloud：/redis-enterprise-cloud-free-30-mb-plan
这是 Rahul 的一篇客座文章，Rahul 是一位独立顾问，也是他合同工作中 Redis Enterprise 的用户。
