Redis系列 | 分類樹查詢功能如何從2s優化到0.1s

大家好,今天我們繼續來分享一個在項目開發過程中遇到的實際問題,這裏也來梳理並總結一下我們是如何對它進行持續優化的,希望能對大家有所幫助。

分類樹查詢功能,在各個業務系統中可以說隨處可見,特別是在一些電商系統中。

但就是這樣一個看似簡單的分類樹查詢功能,我們卻優化了數次。這其中到底經歷了什麼呢?

背 景

我們的一個老項目使用了SpringBoot推薦的模板引擎:Thymeleaf,進行動態渲染。它是一個XML/XHTML/HTML5模板引擎,可用於Web與非Web環境中的應用開發。它提供了一個用於整合SpringMVC的可選模塊,在應用開發中,我們可以使用Thymeleaf來完全代替JSP或其他模板引擎,如Velocity\FreeMarker等。前端開發寫好Thymeleaf的模板文件,調用後端接口獲取數據,進行動態綁定,就能把想要的內容展示給用戶。由於當時很早這也個是從0-1的新項目,爲了開快速開發功能,第一版接口是直接從數據庫中查詢分類數據,組裝成分類樹,然後返回給前端。通過這種方式,簡化了數據流程,快速把整個頁面功能調通了。

第1次優化

我們將該接口部署到dev環境,剛開始沒啥問題。隨着開發人員添加的分類越來越多,很快就暴露出性能瓶頸。我們不得不做優化了。我們第一個想到的是:加Redis緩存流程圖如下:

 

於是暫時這樣優化了一下:

  1. 用戶訪問接口獲取分類樹時,先從Redis中查詢數據。
  2. 如果Redis中有數據,則直接數據。
  3. 如果Redis中沒有數據,則再從數據庫中查詢數據,拼接成分類樹返回。
  4. 將從數據庫中查到的分類樹的數據,保存到Redis中,設置過期時間5分鐘。
  5. 將分類樹返回給用戶。

我們在Redis中定義一個了key,value是一個分類樹的json格式轉換成了字符串,使用簡單的key/value形式保存數據。經過這樣優化之後,dev環境的聯調和自測順利完成了。

第2次優化

我們將這個功能部署到st環境了。剛開始測試同學沒有發現什麼問題,但隨着後面不斷地深入測試,隔一段時間就出現一次首頁訪問很慢的情況。於是,我們馬上進行了第2次優化。我們決定使用Job定期異步更新分類樹到Redis中,在系統上線之前,會先生成一份數據。當然爲了保險起見,防止Redis在哪條突然掛了,之前分類樹同步寫入Redis的邏輯還是保留。於是,流程圖改成了這樣:

 

增加了一個job每隔5分鐘執行一次,從數據庫中查詢分類數據,封裝成分類樹,更新到Redis緩存中。其他的流程保持不變。此外,Redis的過期時間之前設置的5分鐘,現在要改成永久。通過這次優化之後,st環境就沒有再出現過分類樹查詢的性能問題了。

第3次優化

測試了一段時間之後,整個網站的功能快要上線了。爲了保險起見,我們需要對網站首頁做一次壓力測試。果然測出問題了,網站首頁最大的qps是100多,最後發現是每次都從Redis獲取分類樹導致的網站首頁的性能瓶頸。我們需要做第3次優化。該怎麼優化呢?答:加內存緩存。

如果加了內存緩存,就需要考慮數據一致性問題。內存緩存是保存在服務器節點上的,不同的服務器節點更新的頻率可能有點差異,這樣可能會導致數據的不一致性。但分類本身是更新頻率比較低的數據,對於用戶來說不太敏感,即使在短時間內,用戶看到的分類樹有些差異,也不會對用戶造成太大的影響。因此,分類樹這種業務場景,是可以使用內存緩存的。於是,我們使用了Spring推薦的caffine作爲內存緩存。改造後的流程圖如下:

 

  1. 用戶訪問接口時改成先從本地緩存分類數查詢數據。
  2. 如果本地緩存有,則直接返回。
  3. 如果本地緩存沒有,則從Redis中查詢數據。
  4. 如果Redis中有數據,則將數據更新到本地緩存中,然後返回數據。
  5. 如果Redis中也沒有數據(說明Redis掛了),則從數據庫中查詢數據,更新到Redis中(萬一Redis恢復了呢),然後更新到本地緩存中,返回返回數據。

需要注意的是,需要改本地緩存設置一個過期時間,這裏設置的5分鐘,不然的話,沒辦法獲取新的數據。

這樣優化之後,再次做網站首頁的壓力測試,qps提升到了500多,滿足上線要求。

第4次優化

之後,這個功能順利上線了。使用了很長一段時間沒有出現問題。兩年後的某一天,有用戶反饋說,網站首頁有點慢。

我們排查了一下原因發現,分類樹的數據太多了,一次性返回了上萬個分類。原來在系統上線的這兩年多的時間內,運營同學在系統後臺增加了很多分類。我們需要做第4次優化。這時要如何優化呢?限制分類樹的數量?

答:也不太現實,目前這個業務場景就是有這麼多分類,不能讓用戶選擇不到他想要的分類吧?

這時我們想到最快的辦法是開啓nginxGZip功能。讓數據在傳輸之前,先壓縮一下,然後進行傳輸,在用戶瀏覽器中,自動解壓,將真實的分類樹數據展示給用戶。之前調用接口返回的分類樹有1MB的大小,優化之後,接口返回的分類樹的大小是100Kb,一下子縮小了10倍。這樣簡單的優化之後,性能提升了一些。

第5次優化

經過上面優化之後,用戶很長一段時間都沒有反饋性能問題。但有一天公司同事在排查Redis中大key的時候,揪出了分類樹。之前的分類樹使用key/value的結構保存數據的。我們不得不做第5次優化。爲了優化在Redis中存儲數據的大小,我們首先需要對數據進行瘦身。只保存需要用到的字段。

例如:

@AllArgsConstructor
@Data
public class Category {

    private Long id;
    private String name;
    private Long parentId;
    private Date inDate;
    private Long inUserId;
    private String inUserName;
    private List<Category> children;
}

像這個分類對象中inDate、inUserId和inUserName字段是可以不用保存的。修改自動名稱。

例如:

@AllArgsConstructor
@Data
public class Category {
    /**
     * 分類編號
     */
    @JsonProperty("i")
    private Long id;

    /**
     * 分類層級
     */
    @JsonProperty("l")
    private Integer level;

    /**
     * 分類名稱
     */
    @JsonProperty("n")
    private String name;

    /**
     * 父分類編號
     */
    @JsonProperty("p")
    private Long parentId;

    /**
     * 子分類列表
     */
    @JsonProperty("c")
    private List<Category> children;
}

由於在一萬多條數據中,每條數據的字段名稱是固定的,他們的重複率太高了。由此,可以在json序列化時,改成一個簡短的名稱,以便於返回更少的數據大小。這還不夠,需要對存儲的數據做壓縮。之前在Redis中保存的key/value,其中的value是json格式的字符串。其實RedisTemplate支持,value保存byte數組先將json字符串數據用GZip工具類壓縮成byte數組,然後保存到Redis中。再獲取數據時,將byte數組轉換成json字符串,然後再轉換成分類樹。這樣優化之後,保存到Redis中的分類樹的數據大小,一下子減少了10倍,Redis的大key問題被解決了。

小 結

所以回過頭來看,這樣一個看似並不複雜的功能需求,但是要想把它做到穩定、高效、可用,一路下來還是需要考慮不少問題的。而這其中遇到的任何一個問題,一旦解決並覆盤了,它也就匯聚成我們的經驗了,希望這篇文章的梳理能對大家有所幫助。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章