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

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

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 沒有該資料的快取，才去儲存節點拿該資料。

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

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