本周早些时候，《Flights With Friends》写了这篇文章，评估了在 Heroku 上使用 Redis 的替代方案。尽管我们没有被选为他们的首选，但我们认为他们做得相当好，并希望分享我们认为在为您的 Heroku 应用程序选择 Redis 附加组件时应考虑的最重要事项。
- 真正的高可用性：我们指的是即时故障转移——如果一个节点出现故障，数据应立即从替换节点无缝地提供服务。此外，拥有自动化恢复流程也很重要，这样故障转移无需人工干预。
- 无限无缝扩展：您的数据集应该能够增长到任意大小（甚至超出最大的云实例），而不受限于 Redis 命令。升级或降级计划时，您无需在云实例之间移动数据集——只需简单地更改内存限制设置即可。
- 性能：尽管大多数附加组件使用单个 CPU，但让您的 Redis 数据集运行在多个 CPU 和最强大的云实例上要好得多。确保您的附加组件使用先进技术，以最大限度地提高基于云的 Redis 在任何数据集大小下的性能。
- 多个数据库：您可能需要创建多个数据库 (DBs)，目前 Heroku 上的大多数 Redis 附加组件都具备此功能。然而，这在下一个 Redis 版本中可能会被弃用，因为 Redis 基于单线程架构，如果您使用一个 DB，所有其他 DB 都会停滞。确保每个 DB 在专用进程中以非阻塞方式运行。
- 数据库连接数限制：确保您的 Redis 附加组件没有连接数限制。大多数都有！
- 谁是附加组件的幕后推手？：Redis 非常棒。事实上，根据一家领先分析公司最近的一项研究，Redis 在实际的 NoSQL 部署方面仅次于 MongoDB（这可能是现在有这么多新供应商在 Heroku 上提供它的原因）。然而，Redis 是一个数据库，这可能是您的应用程序架构中最敏感的部分。因此，当您选择 Redis 附加组件时，我们建议您调查其幕后推手。他们是什么样的人？他们的技术能力如何？他们是否解决现实问题，还是仅仅“包装”标准的 Redis？他们是否支持 Heroku 以外的平台？您能否与他们共同成长，知道他们会解决您的特定需求？
Redis Cloud 是由一群在数据库和应用加速领域专家开发。自 2012 年 1 月以来，我们一直为生产数据库提供服务，其中许多数据库大小超过 100GB。我们已经克服了三次 AWS 中断，没有丢失客户数据的任何一个字节。那么，为什么我们仍然处于 Beta 阶段？我们花费了时间和巨大的努力来围绕标准 Redis 构建我们新颖的动态集群技术，这使得真正的高可用性、无限无缝扩展、任何数据集大小下的高性能、多个数据库（每个都在专用进程中）以及无限制的数据库连接等能力成为可能。我们想绝对确保它随着时间的推移正常运行，然后再移除“Beta”标签。关于定价问题，目前我们只能承诺它将非常有竞争力，敬请期待！
Redis 8 已发布——且它是开源的
分享
