印度版的“大众点评”如何将 Food Feed 业务从 Redis 迁移到 Cassandra

Zomato 是一家食品订购、外卖及餐馆发现平台，被称为印度版的“大众点评”。目前，该公司的业务覆盖全球24个国家（主要是印度，东南亚和中东市场）。本文将介绍该公司的 Food Feed 业务是如何从 Redis 迁移到 Cassandra 的。

Food Feed 是 Zomato 社交场景中不可或缺的一部分，由于它可让咱们的用户参与其中并与朋友的餐厅评论和图片保持同步，甚至能够经过这个获取餐厅提供的优惠和折扣。开始咱们选择 Redis 做为消息 Feed 流的存储引擎，由于在当时的用户场景这是最好的选择。可是随着业务的发展，咱们须要更高的可用性和负载支持，而 Redis 不能很好的知足这个需求。虽然咱们能够经过丢失一些数据来避免系统的中断，但这不是咱们想作的事情。为了确保咱们的系统具备高可用性，咱们不得不放弃 Redis，而选择 Cassandra 做为其替代品。

Cassandra 很是适合这个用例，由于它是分布式的，就有高可用性等。而且 Cassandra 也能够用于存储时间序列数据 - 这实际上就是咱们的Feed 流。在作出这一重大改变以前，咱们确实有一些 Cassandra 的使用经验，但对于像 Feed 这样重要的东西来讲确定是不够的。咱们必须弄清楚如何顺利的从 Redis 过渡到 Cassandra，并像在 Redis 上那样有效地运行 Feed，而且没有停机时间。

咱们开始花时间在 Cassandra 上，在前两周深刻探索其配置并调整它以知足咱们的要求。接下来，在最终肯定 Feed 的架构以前，咱们明确了一下两个状况：

• Feed 流信息通常只用于读取而基本上不会修改。使用 Redis 的时候，咱们能够同时读取上百个 keys 而没必要担忧读取延迟，可是对于Cassandra 而言，链接延迟多是读取请求过程当中一个至关重要的部分。
• schema 须要足够灵活，以便未来容许 Feed 中新类型的数据。鉴于咱们不断迭代并致力于丰富产品体验，所以在 Feed 中添加元素和功能几乎是不可避免的。

咱们花了几天时间用于收集了咱们项目的数据模式以及各类用户案例，而后开始使用2个数据中心，每一个数据中心有3个节点。 咱们从 Redis 中迁移大概 6000万条记录到 Cassandra 中用于测试其性能。因为是测试阶段，咱们只将一部分流量切入到 Cassandra ，并准备了两个版本的代码，分别写入到 Cassandra 和 Redis 。架构图以下：

咱们监控系统的延迟和其余问题，使人惊讶的是，咱们遇到了写入吞吐量的瓶颈问题。 咱们知道 Cassandra 的写入能力很是强，可是咱们没法实现咱们在各类博客文章和文章中阅读的写入吞吐量。 咱们知道出了什么问题，但咱们不知道是什么。咱们从三个节点中得到的最佳结果是每秒1500次写入，这彻底不能知足线上的需求，咱们不得不在几个小时内回滚并从新评估。

通过几天的排查，咱们意识到问题不在于 Cassandra，而在于 Elastic Block Store（EBS）。EBS是安装在每一个EC2实例上的网络驱动器，具备10 Gigabits 的共享带宽和网络流量。当在单个EC2实例上的全部用户之间共享时，该带宽成为咱们的瓶颈。为了知足这一需求，咱们将数据从基于网络的EBS存储移动到同一EC2实例中的磁盘存储。而后咱们在每一个服务器上逐个部署由 Cassandra 提供支持的新 Food Feed，以便咱们控制吞吐量。很高兴的是，此次成功了。

而后咱们开始从咱们的生产 Redis 服务器迁移数据（咱们花了14个小时来迁移全部内容），在迁移过程当中咱们没有任何故障或额外负载。这就是 Redis 和 Cassandra 的强大功能。今天，咱们的 Food Feed 彻底运行在 Cassandra 上，咱们在没有停机的状况下完成了这项工做。新的架构以下：

总而言之，经过上面这个项目，咱们学到了如下几点：

• 在写入期间避免数据的读取。“读取”吞吐量大体保持不变，而“写入”规模与节点数量成比例；
• 避免数据的删除。删除意味着压缩（compaction），当它运行时，节点的资源会被占用；
• 延迟是一个问题。与Redis相比，Cassandra的链接延迟很高，大约是 Redis 的10x-15x。

原文连接
本文为云栖社区原创内容，未经容许不得转载。