LinkedIn 如何提升資料庫讀取規模,同時降低成本

2024年3月31日

💎 加入 E+ 成長計畫 與超過 300+ 位軟體工程師一同在社群中成長,並且獲得更多的軟體工程學習資源

本篇最早收錄於《ExplainThis 全端雙週報》第 6 期

image
圖片來源:Upscaling LinkedIn's Profile Datastore While Reducing Costs

LinkedIn 是全球最大的職涯社群網站,在尖峰時期每秒鐘要處理將近五百萬個使用者的頁面請求。在《Upscaling LinkedIn's Profile Datastore While Reducing Costs》一文當中,LinkedIn 的工程團隊分享了他們如何導入 Couchbase 資料庫作為快取層,有效提升響應速度,以及降低成本。

初期 - Espresso 資料庫

在引入到 Couchbase 之前,LinkedIn 的使用者頁面是純透過開源的 Espresso 資料庫來做儲存。該資料庫的規模化很簡單,就是增加新的節點 (增加更多硬體)。但是隨著使用者人數提高,LinkedIn 團隊發現純增加節點的方式不堪負荷,需要投入大量資源改造,才可能持續擴張。因此決定找新的解決方案。

引入 Couchbase

對於 LinkedIn 這種社群網站的應用,在系統設計上有個關鍵點,就是讀 (read) 的比例會遠大於寫 (write),比例上是 99 比 1,因此 LinkedIn 團隊選中 Couchbase 作為快取 (cache) 層,來處理大量的讀的請求,這樣當大量讀的請求進來時,不用一直增加 Espresso 的節點。

設計快取三個重點

在設計快取的解決方案時,LinkedIn 團隊考量三個重點:

  • 第一個是韌性 (resilience),意即當快取出問題時不會影響到系統中的其他元件
  • 第二個是快取資料要隨時可用,LinkedIn 團隊的作法是把使用者頁面的資料快取在每個資料中心 (因為資料量不大,所以這可行)
  • 第三則是要避免資料分歧,LinkedIn 團隊的作法是透過在有資料被更新時,去比較時間戳記,選最新的那個去更新到所有同鍵的快取

Espresso 與 Couchbase 混合快取

雖說引入 Couchbase,LinkedIn 團隊沒有只用 Couchbase 作為單獨快取,而是採用 Espresso 與 Couchbase 混合快取的策略。從架構上來看 (下圖),當使用者頁面的服務發送請求後,會先被判斷要索取的資料是可被快取的,然後判斷 Espresso 路由器有沒有快取,以及快取是否太舊,假如沒有或太舊,就去 Couchbase 拿。如果 Couchbase 沒有該資料的快取,才去儲存節點拿該資料。

image
圖片來源:Upscaling LinkedIn's Profile Datastore While Reducing Costs

當有寫的請求 (使用者頁面的資料被更新時),會確保快取有跟資料庫的資料是一致的。LinkedIn 團隊實作了快取更新機制,是採用最終一致性 (eventual consistency) 來更新。如前面有提到,當有多個寫入,會用時間戳記的方式來比較,藉此確保所有快取都是更新到最新的更動。

透過整合 Couchbase 作為快取,LinkedIn 的使用者頁面團隊,最終能夠更有效處理更大量的讀的請求,加快響應速度超過 60%,同時每年降低將近 10% 的運算成本。

🧵 如果你想收到最即時的內容更新,可以在 FacebookInstagram 上追蹤我們