前言

最近我們的商城系統出現了一個線上問題，用戶訪問商城首頁的時候要差不多20秒，才返回數據，可以說卡爆了。

到底怎么回事呢？

1.案發現場

上周四晚上，我們有一個正常的迭代版本按照預期的時候上線。

本次迭代，我所涉及的功能，很快上線，并且測試通過了。

但沒法下班，因為項目組其他同事，還有線上問題在緊急處理。

我過去了解了一下情況，用戶訪問商城首頁的時候響應太慢了，要20秒才返回，有用戶投訴過來了。

進一步了解之后發現，造成這個問題的根本原因是redis服務器掛了。

為什么會掛呢？

是因為一次性往redis中存儲的數據太多了，導致內存不足。

這個商城系統部署到了阿里云上，當時購買了1G的內存空間。

但由于這次上線，有個新功能，需要在商城首頁上，按不同的地區，推薦不同的商品。商品還要按不同的分類做區分。

原本商品只有幾十萬其實不多，但是按地區和分類做區分之后，保存的數據量乘以了幾百倍，一下子占用了大量的內存。

redis掛了為什么會導致首頁慢呢？

答：因為代碼中有業務邏輯，如果從redis中沒有獲取到數據，或者訪問redis失敗了，會從數據庫中獲取。雖說當時是晚上，用戶并發量不大，但是直接訪問數據庫，響應時間一下子下降了很多。

圖片

2.如何快速解決問題？

目前的這套方案，先從redis中獲取數據，如果失敗了，再從數據庫中獲取。

現在的問題是：redis內存不足，臨時解決問題，只能加內存資源了。

因為加內存是最快的，直接加到了4G。如果要改代碼，這個功能今天晚上可能沒法上線，之前購買的1G的資源確實有點小。

在阿里云上redis加了內存之后，這個問題很快解決了，首頁訪問速度一下子提升。

但這不是問題的本質。

3.復盤

第二天，我們開始復盤問題。

發現之前的方案有點問題：

1. 這次新增的推薦商品功能，保存到redis的數據量太大了，把有些為null值的字段，或者前端用不到的字段也保存到redis中了，數據結構設計不合理。
2. redis出現問題之后的兜底方案有點問題，如果redis掛了，就直接訪問了數據庫，導致了用戶訪問慢的問題。如果是白天用戶并發量上來，可能會直接導致數據庫掛掉。

那么，如何優化呢？

4.如何優化？

數據結構不合理的問題，可以通過調整數據結構解決，非常容易。

但如果redis掛了該如何處理呢？

4.1 頁面靜態化

其實對于商城首頁，最好的方案是做頁面靜態化處理。

但由于目前商城的用戶并發量，還不算很大，而且如果改成頁面靜態化，前后端的改動都太大了。

因此，這個方案最先被我們否定了。

4.2 加本地緩存

為了防止后面再次出現商城首頁訪問慢的問題，可以在應用服務增加本地緩存。

這樣不管redis以后能否正常運行，都不影響商城首頁的功能。

但需要考慮一個事情：應用服務的內存是否夠用？

顯然如果將所有推薦的商品數據，都保存到應用服務的本地內存中，同樣可能會導致應用服務的內存不足的問題。

因此，直接加本地內存是不行的。

4.3 改成MongoDB

使用MongoDB替代Redis保存數據。

Redis：數據全部存在內存，定期寫入磁盤，當內存不夠時，可以選擇指定的 LRU 算法刪除數據。

MongoDB：數據存在內存，由 linux系統 mmap 實現，當內存不夠時，只將熱點數據放入內存，其他數據存在磁盤。

顯然MongoDB更適合保存大批量的結構化的文檔數據。

由于我們之前在做其他功能時，使用過MongoDB，它的性能也是挺不錯的。

但如果直接改成從MongoDB中獲取數據，商城首頁的訪問速度可能會有所下降。

4.4 本地緩存 + MongoDB

上面說到過的加本地緩存，和使用MongoDB都有各自的優缺點。

為什么不把兩種方案結合一下呢？

在本地緩存中保存熱點數據，每隔5分鐘更新一次。

圖片

用戶的請求過來，先從本地緩存中獲取推薦商品數據，如果有則直接返回。

如果沒有，則從MongoDB獲取數據。

這樣可以解決性能的問題，也可以解決保存大量的數據。

5.兜底方案

上面的說的本地緩存 + MongoDB，基本可以解決redis掛了的問題。

但如果MongoDB掛了該怎么辦呢？

這就需要有一套更好的兜底方案。

5.1 使用Apollo配置

如果MongoDB掛了，則直接返回Apollo配置中默認數據，默認是北京市東城區的推薦商品數據。

該配置由于在Apollo中，我們可以根據實際情況動態調整。

我們都知道Apollo可以配置成集群模式，是高可用的，一般不容易掛掉。

但它有一個硬傷，就是如果數據并更了，需要人手動調整數據。

沒法保證數據的實時性。

5.2 再從數據庫訪問數據

如果從MongoDB中獲取數據失敗了，則直接從數據庫中獲取數據。

該方案從業務的角度來說，確實沒有問題。

但萬一真的出現這種情況，同樣會出現商城首頁訪問很慢的問題。

5.3 再從redis訪問數據

如果從MongoDB中獲取數據失敗了，則直接從redis中獲取數據。

Redis中只保留熱點商品數據。

這也是一種方案，不過要維護兩份數據：MongoDB一份，Redis一份。

可能會存在數據不一致的問題。

5.4 再加一個本地緩存

在從數據庫獲取數據之后，再加一個本地緩存，保存默認的數據，即：北京市東城區的推薦商品數據。

這個本地緩存，只有在第一次訪問數據庫時寫入，并且有效期是24小時。

相當于在MongoDB和數據庫之間，再加了一層默認的本地緩存。

這樣就能解決數據庫訪問慢的問題。

6.最終方案

經過激烈討論之后，我們最終選擇的方案是：本地緩存+MongoDB+本地默認緩存+數據庫。

圖片

有時候選擇的某一個技術方案，是根據當前的業務發展，或者公司現狀，資金，資源，人手，技術能力等多方面考慮的。

很多技術問題都沒有最完美的解決方案，只有最適合的方案。