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。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。