4.7 小結

以上方案可以順利解決讀數據請求壓垮數據庫的問題，目前互聯網架構也基本是采取這個方案。

分布式緩存系統上線后，商品詳情頁的大部分數據存到了Redis中，并且一些數據的讀取改為異步請求，優化效果非常明顯：打開詳情頁基本只需要1秒；而后臺監控這個詳情頁的API（從緩存中取數據的那個API），平均響應時長變為10毫秒以內；監控數據中，從首頁到搜索再到詳情頁的平均時長變成了4秒左右，這個改善幅度還是很大的。

IT部門在當時一次例會中討論最近的工作亮點，有人問道：“咱們要不要提一下這個緩存方案？它對業務的幫助很大?！绷硪粋€同事就說：“可是緩存這個技術很普通，萬一被問到，這個方案有什么創新的地方，我們要怎么回答？”然后大家都沉默了。

但是后來還是把這個方案放到了部門匯報內容里，只寫了一句話：“利用緩存技術和異步加載技術將商品詳情頁的平均響應時間從十幾秒縮短到1秒?！边@在會議上并沒有引起什么反響，只是后來有一次聚餐時，CEO也在場，他說過這樣的話：“其實我們不要老是追求新技術，能幫到業務的技術就是好技術?！盋TO就接話說：“比如上次你們把商品詳情頁的打開時間大幅度縮短了，這就是好事，這種好事以后多做?！?/p>

接下來說說不足吧。

這個方案主要針對讀數據請求量大的情況，或者讀數據響應時間很長的情況，而不能應對寫數據請求量大的場景。也就是說寫請求多時，數據庫還是會支撐不住。針對這個問題，下一章會給出對應的解決方案。