在 Heroku 上使用 Redis 时需要考虑的六件事

本周早些时候，Flights With Friends 发布了一篇帖子，其中对在 Heroku 上使用 Redis 的替代方案进行了评估。尽管他们没有选择我们作为首选，但我们认为他们做得不错并愿意分享我们认为在为您的 Heroku 应用选择 Redis 插件时需要考虑的最重要事项

1. 真正的可用性：对于这部分，我们指的是即时故障转移 - 如果某个节点发生故障，该数据应该立即通过无缝的方式从替换节点提供服务。 此外，拥有一个自动恢复流程非常重要，如此一来，故障转移不需要人工干预。
2. 无限无缝可扩展性：您的数据集应该能够增长到任何规模（甚至比最大的云实例还要大），并且不受 Redis 命令的限制。升级或降级您的计划时，您无需在云实例之间移动您的数据集 - 这应该是更改您的内存限制设置的一个简单问题。
3. 性能：尽管大部分插件都使用单个 CPU，但是让您的 Redis 数据集在多个 CPU 和最强大的云实例上运行要好得多。确保您的插件使用高级技术来最大化任何数据集规模的基于云的 Redis 性能。
4. 多个数据库：您可能想要创建多个数据库 (DB)，而如今 Heroku 上的大部分 Redis 插件都具有这种能力。但是，这可能会在下一个 Redis 版本中被弃用，因为 Redis 基于单线程架构，因此如果您使用一个 DB，所有其他 DB 都会陷入停顿。确保每个 DB 都在专用的进程中以非阻塞的方式运行。
5. 数据库连接限制：确保您的 Redis 插件不受其允许的连接数的限制。大部分都有此限制！
6. 插件背后的原因是什么？ Redis 非常棒。事实上，根据一家领先的分析公司最近的一项研究，Redis 在实际的 NoSQL 部署方面仅次于 MongoDB（这可能是如此多新供应商如今在 Heroku 上提供它的原因）。然而，Redis 是一个数据库，它可能是您的应用程序架构中最敏感的部分。因此，在您选择 Redis 插件时，我们建议您了解其背后的原因。它背后是什么人？他们的技术能力是什么？他们解决的是现实生活中的问题还是只“打包”标准 Redis？他们是否支持除 Heroku 以外的其他平台？您能否了解他们并将满足您的具体需求而与之共存？

Redis Cloud 由一组在数据库和应用程序加速领域精通的专家开发。我们自 2012 年 1 月开始提供生产数据库服务，其中许多数据库大小超过 100GB。我们已经克服了三次 AWS 故障，并且没有丢失一字节的客户数据。为什么我们仍然处于测试版？围绕标准 Redis 构建我们的新颖动态集群技术耗费了大量时间和精力，这实现了真正的容错、无限和无缝的扩展性，不管数据集大小如何都能获得高性能、多个数据库（每个在专用进程中）以及无限制的数据库连接。在我们去除“测试版”标签之前，我们想确保它能始终如一地正常运行。关于定价问题，我们现在只能保证它极具竞争力，敬请期待！