未来速度的到来，将在您所在的城市举行一场活动。
加入我们在 Redis 发布会
公司：Plivo
行业：电信、CPaaS
Plivo 是一个现代化的全球电信平台，每月在 190 多个国家/地区处理超过 10 亿个 API 请求。该公司成立于 2011 年，为依赖语音和消息传递与客户更有效地互动，并提供企业级可靠性的企业提供服务。
Plivo 的流式微服务架构支持大量的小型高频数据写入。如果 Amazon ElastiCache 区域发生故障，它将无法跟上数据量并保持跨区域的数据一致性。Plivo 的工程师需要构建一个自定义故障转移。
Plivo 在测试表明 Redis 云能够满足其语音 API 平台的要求后，选择了 Redis 云。由于他们正在从开源 Redis 背后的公司迁移到一个托管解决方案，因此几乎不需要进行代码更改。初始迁移在几分钟内成功，完整的迁移在一个月内完成。
数据完整性立即得到改善。此外，Plivo 的工程师能够发现额外的优势，以优化跨区域的服务。Active-Active 是 Redis Enterprise 的一项独家功能，它允许他们最大程度地利用其跨所有区域的基础设施，从而最大化在整个架构中所做的投资。
并非所有数据库都能满足每个用例的性能要求。对于 Plivo，这是一个领先的基于云的通信平台 (CPaaS)，它帮助企业与客户互动和交流，低延迟读写对于其语音 API 平台至关重要。
“Postgres 和其他关系数据库模型在处理高频数据写入方面做得不好，”Plivo 语音平台软件开发工程师兼架构师 Manish Chand Kaushik 表示。“我们将所有缓存用例迁移到 Redis，因为关系数据库已被证明对我们的应用程序来说不是最佳选择。”
Plivo 的语音 API 团队转向 Redis，寻求其低延迟性能，尤其是在数据写入方面。Plivo 的用例包括在给定时间段内限制呼叫速率、排队呼叫状态（响铃、执行、挂断等）以及按区域维护呼叫队列（延迟仅为 1-2 毫秒）。数据存储为哈希和键，排序集用于限制速率。
由于 Plivo 尝试尽可能利用托管服务，因此他们最初部署了 Amazon ElastiCache，在他们的系统中需要低延迟性能。事实证明，对于 Plivo 来说，这并不是理想的托管 Redis 服务，因为 ElastiCache 在区域发生故障时不提供开箱即用的回退功能。
API 工程总监 Rajat Dwivedi 表示：“我们希望确保我们可以通过 Active-Active Redis 满足正常运行时间和可扩展性要求。我们尝试使用 Amazon ElastiCache 模拟这些功能，但意识到我们不想自己解决这个问题。我们选择了 Redis 云，它在全托管解决方案中提供了此功能。”
由于 Plivo 迁移的初始数据是 24 小时前的，因此迁移设置使用 Amazon ElastiCache 作为主系统，Redis 云作为辅助系统，所有写入都同时写入两个系统。如果出现任何问题，该过程可以回滚到主系统并重新启动。Plivo 在计划的维护窗口内进行了迁移，并指出在此窗口内可能会错过写入，因此如果过程中出现错误，他们可以轻松地启动回滚。
这种有条不紊的规划最终被证明是预兆，因为发生了一个小问题，导致一组旧数据被忽略并导致数据流断开。Plivo 的工程师发现了这个问题，清理了系统，并在 8 分钟内回滚以重新启动该过程。
最终迁移到 Redis 云大约在一个月内完成。
“Active-Active Redis 帮助我们保护跨区域的延迟，但我们发现它在优化系统基础设施方面具有附加价值。我们永远不会浪费资源，也不会低估利用我们的资产，”Kaushik 说。
Plivo 工程师试图充分利用所有系统资源和组件。使用 Active-Active Redis，即使具有非凡的线性可扩展性，不仅所有内容都能正常运行，而且整个环境也以最高效率运行。
Active-Active Redis 的部署几乎是司空见惯。Redis 的解决方案架构师在初始阶段帮助了 Plivo 工程师，并提供了清晰、编写良好的文档。优势几乎立即显现。
部署后不久，整个区域都遭受了通信中断。没有发出重大警报，因为系统以智能的方式重新分配了资源，因此 Plivo 的客户几乎没有感受到任何影响。在该区域停机整整一个小时内，没有出现重大性能问题。
Kaushik 指出，这次中断的显著之处在于，“Active-Active Redis 只是在工作。我们的系统保持运行，客户几乎没有注意到任何连接问题，我们不必进行任何损害控制。整个 60 分钟的事件几乎没有引起任何注意。”
Redis 云的首次实际测试证明了其价值，并让 Plivo 安心，因为他们的许多数据需要在分布式架构中同步，以支持复杂的用例。
Dwivedi 指出，Plivo 系统进一步迁移到 Redis 云的路线图已经规划好，其中一个已经开始用于财务数据系统。全年的评估将用于迁移大多数的缓存和低延迟用例，“因为我们可以自信地使用 Active-Active Redis。”
