4.1 業務場景：如何將十幾秒的查詢請求優化成毫秒級

這次項目針對的系統是一個電商系統。每個電商系統都有個商品詳情頁。一開始這個頁面很簡單，只包括商品的圖片、介紹、規格、評價等。

剛開始，這個頁面打開很快，系統運行平穩可靠。

后來，頁面中加了商品推薦，即在商品詳情頁后面顯示一些推薦商品的列表。

再后來，頁面中加入了最近成交情況，即顯示一下某人在什么時候下單了。

接著，頁面中又加入了優惠活動，即顯示這個商品都可以參加哪些優惠活動。

……

當時這個系統里面有5萬多條商品數據，數據量并不大，但是每次用戶瀏覽商品詳情頁時都需要幾十條SQL語句，經常出現十幾秒才能打開詳情頁的情況。

這樣的用戶體驗當然不好。公司有個第三方監控工具，從國內各地監控系統幾個關鍵路徑的性能。其中一個關鍵路徑是從首頁到搜索再到商品詳情頁的時長，這個平均時長從剛開始的3.61秒逐漸變成后來的15.53秒，監控工具成為“擺設”，實際不再使用。

之前也有人提過商品詳情頁需要優化，不過另一個人說，打開App進入首頁前廣告都要播放10秒，用戶還在乎這個商品詳情頁打開慢嗎？當然，沒有馬上優化的原因，是后面不斷有其他業務需求。

后來這個優化項目提上了日程，項目組開始考慮要怎么優化。重構數據庫基本不可能，最好不要改動表結構。大家想到的方案也很通用，就是把大部分商品的詳情數據緩存起來，少部分的數據通過異步加載。比如，最近的成交數據通過異步加載，即用戶打開商品詳情頁以后，再在后臺加載最近的成交數據，并顯示給用戶。不過這一章主要講緩存，所以異步加載的方案就不在此展開了。

關于緩存，最簡單的實現方法就是使用本地緩存，即把商品詳情數據放在JVM里面。在Google Guava中有一個內存緩存模塊，它把所有商品的ID與商品詳情信息一對一緩存至JVM內存中，用戶獲取商品詳情數據時，系統會根據商品ID直接從緩存中讀取數據，能大大提升用戶頁面的訪問速度。

不過，通過簡單換算后發現這個方法明顯不合理。先來舉個例子。

一條商品數據中往往包含品牌、分類、參數、規格、服務、描述等字段，僅存儲這些商品數據就要占用500KB左右的內存，再將這些數據緩存到本地的話，就要占用500KB×50000≈25GB內存。此時，假設商品服務有30個服務器節點，僅緩存商品數據就需要額外準備750GB的內存空間，這種方法顯然不可取。

為此，項目組決定使用另外一個解決辦法——分布式緩存，先將所有的緩存數據集中存儲在同一個地方，而非重復保存到各個服務器節點中，然后所有的服務器節點都從這個地方讀取數據，如圖4-1所示。

那么這個統一存儲緩存數據的地方需要使用什么技術呢？這就涉及接下來要講的緩存中間件技術選型問題了。