前言
分類樹查詢功能，在各個(gè)業(yè)務(wù)系統(tǒng)中可以說(shuō)隨處可見(jiàn)，特別是在電商系統(tǒng)中。
但就是這樣一個(gè)簡(jiǎn)單的分類樹查詢功能，我們卻優(yōu)化了5次。
到底是怎么回事呢？
背景
我們的網(wǎng)站使用了SpringBoot推薦的模板引擎：Thymeleaf，進(jìn)行動(dòng)態(tài)渲染。
它是一個(gè)XML/Xhtml/HTML5模板引擎，可用于Web與非Web環(huán)境中的應(yīng)用開發(fā)。
它提供了一個(gè)用于整合SpringMVC的可選模塊，在應(yīng)用開發(fā)中，我們可以使用Thymeleaf來(lái)完全代替JSP或其他模板引擎，如VelocityFreeMarker等。
前端開發(fā)寫好Thymeleaf的模板文件，調(diào)用后端接口獲取數(shù)據(jù)，進(jìn)行動(dòng)態(tài)綁定，就能把想要的內(nèi)容展示給用戶。
由于當(dāng)時(shí)這個(gè)是從0-1的新項(xiàng)目，為了開快速開發(fā)功能，我們第一版接口，直接從數(shù)據(jù)庫(kù)中查詢分類數(shù)據(jù)，組裝成分類樹，然后返回給前端。
通過(guò)這種方式，簡(jiǎn)化了數(shù)據(jù)流程，快速把整個(gè)頁(yè)面功能調(diào)通了。
第1次優(yōu)化
我們將該接口部署到dev環(huán)境，剛開始沒(méi)啥問(wèn)題。
隨著開發(fā)人員添加的分類越來(lái)越多，很快就暴露出性能瓶頸。
我們不得不做優(yōu)化了。
我們第一個(gè)想到的是：加redis緩存。
流程圖如下：
于是暫時(shí)這樣優(yōu)化了一下：
- 用戶訪問(wèn)接口獲取分類樹時(shí)，先從Redis中查詢數(shù)據(jù)。
- 如果Redis中有數(shù)據(jù)，則直接數(shù)據(jù)。
- 如果Redis中沒(méi)有數(shù)據(jù)，則再?gòu)臄?shù)據(jù)庫(kù)中查詢數(shù)據(jù)，拼接成分類樹返回。
- 將從數(shù)據(jù)庫(kù)中查到的分類樹的數(shù)據(jù)，保存到Redis中，設(shè)置過(guò)期時(shí)間5分鐘。
- 將分類樹返回給用戶。
我們?cè)赗edis中定義一個(gè)了key，value是一個(gè)分類樹的json格式轉(zhuǎn)換成了字符串，使用簡(jiǎn)單的key/value形式保存數(shù)據(jù)。
經(jīng)過(guò)這樣優(yōu)化之后，dev環(huán)境的聯(lián)調(diào)和自測(cè)順利完成了。
第2次優(yōu)化
我們將這個(gè)功能部署到st環(huán)境了。
剛開始測(cè)試同學(xué)沒(méi)有發(fā)現(xiàn)什么問(wèn)題，但隨著后面不斷地深入測(cè)試，隔一段時(shí)間就出現(xiàn)一次首頁(yè)訪問(wèn)很慢的情況。
于是，我們馬上進(jìn)行了第2次優(yōu)化。
我們決定使用Job定期異步更新分類樹到Redis中，在系統(tǒng)上線之前，會(huì)先生成一份數(shù)據(jù)。
當(dāng)然為了保險(xiǎn)起見(jiàn)，防止Redis在哪條突然掛了，之前分類樹同步寫入Redis的邏輯還是保留。
于是，流程圖改成了這樣：
增加了一個(gè)job每隔5分鐘執(zhí)行一次，從數(shù)據(jù)庫(kù)中查詢分類數(shù)據(jù)，封裝成分類樹，更新到Redis緩存中。
其他的流程保持不變。
此外，Redis的過(guò)期時(shí)間之前設(shè)置的5分鐘，現(xiàn)在要改成永久。
通過(guò)這次優(yōu)化之后，st環(huán)境就沒(méi)有再出現(xiàn)過(guò)分類樹查詢的性能問(wèn)題了。
第3次優(yōu)化
測(cè)試了一段時(shí)間之后，整個(gè)網(wǎng)站的功能快要上線了。
為了保險(xiǎn)起見(jiàn)，我們需要對(duì)網(wǎng)站首頁(yè)做一次壓力測(cè)試。
果然測(cè)出問(wèn)題了，網(wǎng)站首頁(yè)最大的qps是100多，最后發(fā)現(xiàn)是每次都從Redis獲取分類樹導(dǎo)致的網(wǎng)站首頁(yè)的性能瓶頸。
我們需要做第3次優(yōu)化。
該怎么優(yōu)化呢？
答：加內(nèi)存緩存。
如果加了內(nèi)存緩存，就需要考慮數(shù)據(jù)一致性問(wèn)題。
內(nèi)存緩存是保存在服務(wù)器節(jié)點(diǎn)上的，不同的服務(wù)器節(jié)點(diǎn)更新的頻率可能有點(diǎn)差異，這樣可能會(huì)導(dǎo)致數(shù)據(jù)的不一致性。
但分類本身是更新頻率比較低的數(shù)據(jù)，對(duì)于用戶來(lái)說(shuō)不太敏感，即使在短時(shí)間內(nèi)，用戶看到的分類樹有些差異，也不會(huì)對(duì)用戶造成太大的影響。
因此，分類樹這種業(yè)務(wù)場(chǎng)景，是可以使用內(nèi)存緩存的。
于是，我們使用了Spring推薦的caffine作為內(nèi)存緩存。
改造后的流程圖如下：
- 用戶訪問(wèn)接口時(shí)改成先從本地緩存分類數(shù)查詢數(shù)據(jù)。
- 如果本地緩存有，則直接返回。
- 如果本地緩存沒(méi)有，則從Redis中查詢數(shù)據(jù)。
- 如果Redis中有數(shù)據(jù)，則將數(shù)據(jù)更新到本地緩存中，然后返回?cái)?shù)據(jù)。
- 如果Redis中也沒(méi)有數(shù)據(jù)（說(shuō)明Redis掛了），則從數(shù)據(jù)庫(kù)中查詢數(shù)據(jù)，更新到Redis中（萬(wàn)一Redis恢復(fù)了呢），然后更新到本地緩存中，返回返回?cái)?shù)據(jù)。
需要注意的是，需要改本地緩存設(shè)置一個(gè)過(guò)期時(shí)間，這里設(shè)置的5分鐘，不然的話，沒(méi)辦法獲取新的數(shù)據(jù)。
這樣優(yōu)化之后，再次做網(wǎng)站首頁(yè)的壓力測(cè)試，qps提升到了500多，滿足上線要求。
第4次優(yōu)化
之后，這個(gè)功能順利上線了。
使用了很長(zhǎng)一段時(shí)間沒(méi)有出現(xiàn)問(wèn)題。
兩年后的某一天，有用戶反饋說(shuō)，網(wǎng)站首頁(yè)有點(diǎn)慢。
我們排查了一下原因發(fā)現(xiàn)，分類樹的數(shù)據(jù)太多了，一次性返回了上萬(wàn)個(gè)分類。
原來(lái)在系統(tǒng)上線的這兩年多的時(shí)間內(nèi)，運(yùn)營(yíng)同學(xué)在系統(tǒng)后臺(tái)增加了很多分類。
我們需要做第4次優(yōu)化。
這時(shí)要如何優(yōu)化呢？
限制分類樹的數(shù)量？
答：也不太現(xiàn)實(shí)，目前這個(gè)業(yè)務(wù)場(chǎng)景就是有這么多分類，不能讓用戶選擇不到他想要的分類吧？
這時(shí)我們想到最快的辦法是開啟Nginx的GZip功能。
讓數(shù)據(jù)在傳輸之前，先壓縮一下，然后進(jìn)行傳輸，在用戶瀏覽器中，自動(dòng)解壓，將真實(shí)的分類樹數(shù)據(jù)展示給用戶。
之前調(diào)用接口返回的分類樹有1MB的大小，優(yōu)化之后，接口返回的分類樹的大小是100Kb，一下子縮小了10倍。
這樣簡(jiǎn)單的優(yōu)化之后，性能提升了一些。
第5次優(yōu)化
經(jīng)過(guò)上面優(yōu)化之后，用戶很長(zhǎng)一段時(shí)間都沒(méi)有反饋性能問(wèn)題。
但有一天公司同事在排查Redis中大key的時(shí)候，揪出了分類樹。之前的分類樹使用key/value的結(jié)構(gòu)保存數(shù)據(jù)的。
我們不得不做第5次優(yōu)化。
為了優(yōu)化在Redis中存儲(chǔ)數(shù)據(jù)的大小，我們首先需要對(duì)數(shù)據(jù)進(jìn)行瘦身。
只保存需要用到的字段。
例如：
@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;
}
像這個(gè)分類對(duì)象中inDate、inUserId和inUserName字段是可以不用保存的。
修改自動(dòng)名稱。
例如：
@AllArgsConstructor
@Data
public class Category {
/**
* 分類編號(hào)
*/
@JsonProperty("i")
private Long id;
/**
* 分類層級(jí)
*/
@JsonProperty("l")
private Integer level;
/**
* 分類名稱
*/
@JsonProperty("n")
private String name;
/**
* 父分類編號(hào)
*/
@JsonProperty("p")
private Long parentId;
/**
* 子分類列表
*/
@JsonProperty("c")
private List<Category> children;
}
由于在一萬(wàn)多條數(shù)據(jù)中，每條數(shù)據(jù)的字段名稱是固定的，他們的重復(fù)率太高了。
由此，可以在json序列化時(shí)，改成一個(gè)簡(jiǎn)短的名稱，以便于返回更少的數(shù)據(jù)大小。
這還不夠，需要對(duì)存儲(chǔ)的數(shù)據(jù)做壓縮。
之前在Redis中保存的key/value，其中的value是json格式的字符串。
其實(shí)RedisTemplate支持，value保存byte數(shù)組。
先將json字符串?dāng)?shù)據(jù)用GZip工具類壓縮成byte數(shù)組，然后保存到Redis中。
再獲取數(shù)據(jù)時(shí)，將byte數(shù)組轉(zhuǎn)換成json字符串，然后再轉(zhuǎn)換成分類樹。
這樣優(yōu)化之后，保存到Redis中的分類樹的數(shù)據(jù)大小，一下子減少了10倍，Redis的大key問(wèn)題被解決了。
