Zomato 是一家食品訂購、外賣及餐館發(fā)現(xiàn)平臺，被稱為印度版的“大眾點評”。目前，該公司的業(yè)務(wù)覆蓋全球24個國家（主要是印度，東南亞和中東市場）。本文將介紹該公司的 Food Feed 業(yè)務(wù)是如何從 Redis 遷移到 Cassandra 的。

Food Feed 是 Zomato 社交場景中不可或缺的一部分，因為它可以讓我們的用戶參與其中并與朋友的餐廳評論和圖片保持同步，甚至可以通過這個獲取餐廳提供的優(yōu)惠和折扣。開始我們選擇 Redis 作為消息 Feed 流的存儲引擎，因為在當(dāng)時的用戶場景這是最好的選擇。但是隨著業(yè)務(wù)的發(fā)展，我們需要更高的可用性和負載支持，而 Redis 不能很好的滿足這個需求。雖然我們可以通過丟失一些數(shù)據(jù)來避免系統(tǒng)的中斷，但這不是我們想做的事情。為了確保我們的系統(tǒng)具有高可用性，我們不得不放棄 Redis，而選擇 Cassandra 作為其替代品。

Cassandra 非常適合這個用例，因為它是分布式的，就有高可用性等。并且 Cassandra 也可以用于存儲時間序列數(shù)據(jù) - 這實際上就是我們的Feed 流。在做出這一重大改變之前，我們確實有一些 Cassandra 的使用經(jīng)驗，但對于像 Feed 這樣重要的東西來說肯定是不夠的。我們必須弄清楚如何順利的從 Redis 過渡到 Cassandra，并像在 Redis 上那樣有效地運行 Feed，并且沒有停機時間。

我們開始花時間在 Cassandra 上，在前兩周深入探索其配置并調(diào)整它以滿足我們的要求。接下來，在最終確定 Feed 的架構(gòu)之前，我們明確了一下兩個情況：

• Feed 流信息一般只用于讀取而基本上不會修改。使用 Redis 的時候，我們可以同時讀取上百個 keys 而不必擔(dān)心讀取延遲，但是對于Cassandra 而言，連接延遲可能是讀取請求過程中一個相當(dāng)重要的部分。
• schema 需要足夠靈活，以便將來允許 Feed 中新類型的數(shù)據(jù)。鑒于我們不斷迭代并致力于豐富產(chǎn)品體驗，因此在 Feed 中添加元素和功能幾乎是不可避免的。

我們花了幾天時間用于收集了我們項目的數(shù)據(jù)模式以及各種用戶案例，然后開始使用2個數(shù)據(jù)中心，每個數(shù)據(jù)中心有3個節(jié)點。 我們從 Redis 中遷移大概 6000萬條記錄到 Cassandra 中用于測試其性能。由于是測試階段，我們只將一部分流量切入到 Cassandra ，并準(zhǔn)備了兩個版本的代碼，分別寫入到 Cassandra 和 Redis 。架構(gòu)圖如下：

我們監(jiān)控系統(tǒng)的延遲和其他問題，令人驚訝的是，我們遇到了寫入吞吐量的瓶頸問題。 我們知道 Cassandra 的寫入能力非常強，但是我們無法實現(xiàn)我們在各種博客文章和文章中閱讀的寫入吞吐量。 我們知道出了什么問題，但我們不知道是什么。我們從三個節(jié)點中獲得的最佳結(jié)果是每秒1500次寫入，這完全不能滿足線上的需求，我們不得不在幾個小時內(nèi)回滾并重新評估。

經(jīng)過幾天的排查，我們意識到問題不在于 Cassandra，而在于 Elastic Block Store（EBS）。EBS是安裝在每個EC2實例上的網(wǎng)絡(luò)驅(qū)動器，具有10 Gigabits 的共享帶寬和網(wǎng)絡(luò)流量。當(dāng)在單個EC2實例上的所有用戶之間共享時，該帶寬成為我們的瓶頸。為了滿足這一需求，我們將數(shù)據(jù)從基于網(wǎng)絡(luò)的EBS存儲移動到同一EC2實例中的磁盤存儲。然后我們在每個服務(wù)器上逐個部署由 Cassandra 提供支持的新 Food Feed，以便我們控制吞吐量。很高興的是，這次成功了。

然后我們開始從我們的生產(chǎn) Redis 服務(wù)器遷移數(shù)據(jù)（我們花了14個小時來遷移所有內(nèi)容），在遷移過程中我們沒有任何故障或額外負載。這就是 Redis 和 Cassandra 的強大功能。今天，我們的 Food Feed 完全運行在 Cassandra 上，我們在沒有停機的情況下完成了這項工作。新的架構(gòu)如下：

總而言之，通過上面這個項目，我們學(xué)到了以下幾點：

• 在寫入期間避免數(shù)據(jù)的讀取。“讀取”吞吐量大致保持不變，而“寫入”規(guī)模與節(jié)點數(shù)量成比例；
• 避免數(shù)據(jù)的刪除。刪除意味著壓縮（compaction），當(dāng)它運行時，節(jié)點的資源會被占用；
• 延遲是一個問題。與Redis相比，Cassandra的連接延遲很高，大約是 Redis 的10x-15x。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的印度版的“大众点评”如何将 Food Feed 业务从 Redis 迁移到 Cassandra的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。