印度版的「大衆點評」如何將 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。

原文連接
本文爲雲棲社區原創內容，未經容許不得轉載。