怎么將Food Feed業(yè)務(wù)從Redis遷移到Cassandra

這篇文章給大家介紹怎么將Food Feed業(yè)務(wù)從Redis遷移到Cassandra，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

下面將介紹Zomato公司的 Food Feed 業(yè)務(wù)是如何從 Redis 遷移到 Cassandra 的。

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

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

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

• Feed 流信息一般只用于讀取而基本上不會(huì)修改。使用 Redis 的時(shí)候，我們可以同時(shí)讀取上百個(gè) keys 而不必?fù)?dān)心讀取延遲，但是對(duì)于Cassandra 而言，連接延遲可能是讀取請(qǐng)求過程中一個(gè)相當(dāng)重要的部分。

• schema 需要足夠靈活，以便將來允許 Feed 中新類型的數(shù)據(jù)。鑒于我們不斷迭代并致力于豐富產(chǎn)品體驗(yàn)，因此在 Feed 中添加元素和功能幾乎是不可避免的。

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

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

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

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

總而言之，通過上面這個(gè)項(xiàng)目，我們學(xué)到了以下幾點(diǎn)：

• 在寫入期間避免數(shù)據(jù)的讀取?！白x取”吞吐量大致保持不變，而“寫入”規(guī)模與節(jié)點(diǎn)數(shù)量成比例；

• 避免數(shù)據(jù)的刪除。刪除意味著壓縮（compaction），當(dāng)它運(yùn)行時(shí)，節(jié)點(diǎn)的資源會(huì)被占用；

• 延遲是一個(gè)問題。與Redis相比，Cassandra的連接延遲很高，大約是 Redis 的10x-15x。

關(guān)于怎么將Food Feed業(yè)務(wù)從Redis遷移到Cassandra就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。