客户

Plivo 是一个现代化的全球电信平台,每月在 190 多个国家(地区)为超过 10 亿个 API 请求提供服务。该公司成立于 2011 年,为依赖语音和消息传递以更有效地与客户互动的企业提供企业级可靠性。

挑战

Plivo 的流式微服务架构支持大量小型高频数据写入。如果某个 Amazon ElastiCache 区域发生故障,它就无法跟上容量并保持跨区域的数据一致性。Plivo 的工程师需要构建自定义故障转移。

解决方案

Plivo 在测试表明它可以处理其语音 API 平台的要求后选择了 Redis Enterprise Cloud。因为他们正在从开源 Redis 背后的公司迁移到托管解决方案,所以几乎不需要更改代码。最初的迁移在几分钟内就成功了,而完整的迁移则在一个月内完成。

为什么选择Redis

数据完整性立即得到改善。此外,Plivo 的工程师能够发现额外的好处,以优化跨地区的服务。Active-Active 是 Redis Enterprise 独有的功能,使他们能够在所有地区最有效地利用其基础架构,从而最大限度地提高整个架构的投资。

“我们希望确保通过 Active-Active Redis 满足正常运行时间和可扩展性要求。我们尝试使用 Amazon ElastiCache 模拟这些功能,但意识到这是我们不想自己解决的问题。我们选择了 Redis Enterprise Cloud,它在完全托管的解决方案中提供了此功能。”

                                                                                                                                                   Rajat Dwivedi|Plivo API 工程总监

并非所有数据库都能满足每个用例的性能要求。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 Enterprise Cloud,它在完全托管的解决方案中提供了此功能。”

由于 Plivo 迁移的初始数据是 24 小时前的,因此迁移设置为 Amazon ElastiCache 作为主系统,Redis Enterprise Cloud 作为辅助系统,所有写入都在两个系统中进行。如果出现任何问题,进程可以回滚到主进程并重新启动。Plivo 在计划内的维护窗口内采取了行动,并指出在此窗口中可能会丢失写入,因此如果过程中出现错误,他们可以轻松启动回滚。

当一个小问题发生时,这种有条不紊的计划最终变得具有预见性,即忽略了一组旧数据并导致数据流断开连接。Plivo 的工程师发现了问题,清除了系统,并在 8 分钟内回滚以重新启动该过程。 

最终,在大约一个月内完成了到 Redis Enterprise Cloud 的迁移。

跨区域优化和容错

 

“Active-Active Redis 帮助我们保护跨区域的延迟,但我们发现它优化系统基础设施的方式具有附加价值。我们从来没有浪费资源的情况,我们也从来没有充分利用我们的资产,”考希克说。

Plivo 工程师试图充分利用所有系统资源和组件。使用 Active-Active Redis,即使具有非凡的线性可扩展性,不仅一切正常,而且整个环境也在以最高效率运行。

Active-Active Redis 的部署几乎是平凡的。Redis 的解决方案架构师借助清晰、编写良好的文档在初始阶段帮助了 Plivo 工程师。

部署后不久,整个地区的通信中断。系统没有发出重大警报,因为系统只是以智能方式重新分配资源,因此 Plivo 的客户几乎看不到任何影响。在该地区出现故障的整个小时内,没有出现重大性能问题。

Kaushik 指出了中断的显着之处,“Active-Active Redis 可以正常工作。我们的系统一直在工作,客户几乎没有注意到任何连接问题,而且我们无需采取任何措施来控制损坏。整个 60 分钟的插曲几乎是平淡无奇的。”

 

无需管理数据平台即可安心

 

Redis 企业云的第一次真正测试证明了它的价值,并让 Plivo 高枕无忧,因为他们的大量数据需要在其分布式架构中针对复杂的用例进行同步。

Dwivedi 指出,计划将 Plivo 系统进一步迁移到 Redis Enterprise Cloud 的路线图,其中一个财务数据系统已经在进行中。将进行全年评估以迁移他们的大部分缓存和低延迟用例,“因为我们可以放心地使用 Active-Active Redis。”