一、概念定義
1.什麼是類目
類目簡單來說就是商品的分類，用大家最常用的淘寶來看，就是圖中圈出來的地方。
為什麼會有類目，也是其功能決定的，類目目前已經作為電商網站導航的標配，只是不同網站的類目不同罷了。
如果我們的網站只有幾十個、上百個商品，或許類目對於我們來說不重要，但是如果商品有成千上萬個，甚至更多，那類目對我們來找到具有某些特點的商品就至關重要了。比如現在要找女式牛仔褲，可以通過類目 女裝->牛仔褲 就能找到了；否則那就一頁一頁去搜尋，就算我們平臺商品質量再好，價效比再高，相信使用者也會忍耐不住抓狂了。。
2.前後臺類目
類目分為前臺和後臺類目。
前臺類目的存在主要是面向使用者，搜尋導航欄，這個是易變的，季節、營銷活動都會影響類目導航；
後臺類目是直接和商品關聯的，商品建立的時候選擇好類目，那麼對應的類目幾乎就不會變化了，它是很穩定的。
好處：
比如現在我們平臺新推出一種活動，類目就是12.12，如果沒有前後臺類目分離，那我們需要找到需要做活動的商品把他們類目改為12.12，但明顯這個方式不妥；那重新維護一套和這些商品的關聯關係，這樣搞個新模組那還不如直接用類目來承載呢，這樣我們把前後臺類目做個對映關係就OK了。
關聯關係可以根據需求任意組合。
舉例：現在有批商品，分別有後臺類目A、B、C，我們要對A、B類目的商品做活動導航，則做個對映關係，12.12->(A、B)，將前臺類目12.12和後臺A、B做關聯，這樣就可以通過導航12.12找到所有A、B類目下的商品了。
此外，前臺類目易變而且不和商品直接關聯還有個好處，它可以擴充套件成很多種方式。比如新增活動頻道，通過URL的方式直接跳轉；通過關鍵詞的方式定義，比如類目T恤就是通過關鍵詞T恤進行商品搜尋的功能。
一般來說，不管是前臺類目還是後臺類目都會分為幾級，所以最終都會形成一棵類目樹。
3.屬性和屬性值
每個類目都有屬性，屬性作為該類目下商品都共有的特徵，比如顏色、大小等等。
屬性值則是該屬性具體的值，比如顏色可以有紅色、白色、黑色。
正常來說，前臺類目有關聯後臺類目，則前臺類目的屬性都是從後臺類目的屬性集合中選擇的。
比如12.12->(A、B)這個關係中，對應屬性A(a1,a2)，B(b1,b2),則12.12的屬性應該屬於(a1,a2,b1,b2)集合。
屬性也可分為幾類，我們使用到的大致為：導航屬性、銷售屬性、普通屬性。
導航屬性：作為根據類目進入篩選頁的屬性選項。
銷售屬性：商品詳情頁可供選擇的sku規格屬性，不同屬性價格可能會不同。
普通屬性：商品的其他屬性。
建立商品的時候需要選擇類目，然後根據該類目的屬性來填充商品的屬性值，儲存在商品上就類似於key-value的格式。這樣就可以根據屬性值來篩選商品。
4.子屬性和子屬性值
這個關係一般用不上，設計不了這麼細緻，不過可以預留著。
子屬性是掛在某個屬性值下面的。子屬性值就是該子屬性的取值。例如手機類目下，有個屬性為品牌，存在一個屬性值為iPhone的品牌，則再往下劃分可劃分出iPhone的子屬性型號，對應的子屬性值可以為iPhone8、iPhone X等。
所以這裡就存在一個關係：類目(手機)->屬性(品牌)->屬性值(iPhone)->子屬性(型號)->iPhone8(子屬性值)
子屬性也用屬性模型來承載，只是設計的時候要建立好屬性值和子屬性的關聯關係。
二、技術設計
1.關係圖
其中包含的對應關係有：
前臺類目:後臺類目(多對多);
類目:屬性(1對多);
屬性:屬性值(1對多);
屬性值:子屬性(1對多);
2.類目屬性樹形結構圖
類目和屬性的層級深度根據業務而定，因為是樹形結構，所以本身可擴充套件。
屬性掛在後臺葉子類目下。
3.類目表
`cate_id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
`gmt_create` datetime NOT NULL COMMENT '建立時間',
`gmt_modified` datetime NOT NULL COMMENT '修改時間',
`pid` bigint(20) DEFAULT NULL COMMENT '父id',
`leaf` tinyint(4) NOT NULL COMMENT '是否葉子節點 1：是0：不是',
`level` tinyint(4) NOT NULL COMMENT '層級',
`title` varchar(64) NOT NULL COMMENT 'title',
`cate_type` tinyint(4) NOT NULL COMMENT '前臺後臺類目 1：前臺 2：後臺',
`back_categories` varchar(255) DEFAULT NULL COMMENT '後臺類目id集合 適用於前臺 英文逗號分隔',
`root_cate_id` bigint(20) DEFAULT NULL COMMENT '根類目id',
`order_seq` int(11) NOT NULL COMMENT '排序序列',
`picture_url` varchar(255) DEFAULT NULL COMMENT '圖片url',
`need_audit` tinyint(4) NOT NULL COMMENT '是否需要稽核 1：是0：不是',
`is_delete` tinyint(4) NOT NULL COMMENT '狀態0：正常 1：刪除',
`biz_type` varchar(64) NOT NULL COMMENT '平臺型別',
`language` varchar(64) DEFAULT 'zh' COMMENT '語言',
`country` varchar(64) DEFAULT 'CN' COMMENT '國家',
`extension` mediumtext COMMENT '擴充套件欄位',
`version` int(11) NOT NULL DEFAULT '0' COMMENT ‘版本',複製程式碼其中pid儲存上級類目ID
level表示該類目處於第幾級
4.快取
由於類目作為電商系統的基礎資料，很多模組都會依賴它，隨著電商系統規模的擴大，類目查詢請求、併發量會不斷增加，所以一開始我們就採用快取的方式。
採用類目做快取的幾點考量：
- 類目作為基礎資料，查詢請求巨大；
- 類目資料相比其他基礎資料來說記憶體佔用不高；
- 類目是共享資料；
- 類目變更實時性要求不高，沒有嚴格的資料一致性要求；
快取的兩種方式：分散式快取和分散式本地快取
4.1分散式快取：
使用Redis來儲存類目資料結構。
優點：所有client共享一份資料，沒有資料不一致的問題
缺點：當系統規模很大，qps將不斷增加，快取中心壓力變大。
整體流程如下圖：
- 從DB查詢類目資料
- 構建需要儲存的資料結構，並推到快取
- 接收client查詢請求
- 從構建好的快取中查詢
- 返回資料
重新整理策略：定時更新，1.2兩步通過定時任務執行、執行頻率可根據具體業務可接受程度而定。
該方法的好處是無需在類目更改的所有方法路徑加入快取失效、推送的邏輯。所有邏輯都統一在定時任務裡面處理。
4.2分散式本地快取：
優點：所有client本地記憶體有一份副本，直接從記憶體讀取，速度快。
缺點：所有client需要與server資料同步，關鍵問題是資料不一致很難保證；
需要封裝單獨的client jar包以供使用，當jar包升級時需要同步所有依賴方升級，維護成本大；
整體流程圖如下：
- 1.從DB讀取類目資料
- 2.構建需要快取的類目資料結構。
- 3.通過開發的類目client jar包向伺服器拉取資料。
- 4.返回構建好的資料結構。
這裡有幾點需要注意：
1.可以通過很多種方式來達到client的資料重新整理：
- 將構建好的資料包存放在DB，client統一從DB重新整理；
- 伺服器通過發訊息廣播的方式，client監聽重新整理本地快取；
- 通過jar包實現封裝定時拉取的方式，定時重新整理本地快取。
由於我們系統中對類目的更新實時性要求不高、沒有嚴格一致性要求。所以設計時可採用定時重新整理的方式。jar包的方式對於依賴方是最易用的方式。也正是實時性、一致性要求不高，所以才可使用本地快取。如果系統因為本地快取資料不一致而將導致很嚴重的後果，那還是慎用。
2.類目client是開發後打包給需要使用類目服務的應用引用。該包裡面已封裝好了關於類目的所有操作，包括定時拉取、解析伺服器構建的資料結構、資料校驗、本地快取重新整理等功能，對應用提供的就是類目的基本操作，比如根據ID獲取類目、獲取類目樹等等。
3.伺服器每次構建類目資料結構應維護版本號，這樣client可判斷是否是最新資料，重新拉取等等。通過先判斷版本號，再拉取是一種不錯的選擇。這樣可減少資料未更新而產生的不必要網路傳輸。
4.為什麼通過類目client主動從伺服器拉取的方式，因為如果伺服器主動推送，首先得維護client列表，其次還要維護所有client的推送狀態。如果把這個放在client維護，那就大大減少了複雜性。
通過比較分散式快取和本地快取兩種方式，總結出分散式快取實現簡單，資料一致性易保證。本地快取需要自己實現client包，會出現短暫的不一致，在高併發下優勢更加明顯，但強一致業務慎用。最終我們使用分散式快取即能滿足要求。
結構設計：
類目面向電商前臺頁面，用的最多的就是類目樹的獲取，所以可以這樣來設計。
- rootCategoryIds:儲存根類目ID列表索引
- subCategoryIds + 類目ID:儲存該類目下級類目ID列表索引
- category + 類目ID：儲存該類目具體資料data
通過根類目ID列表和子類目ID列表就能夠索引到類目樹中所有的類目ID，通過ID就能拿到所有資料。
該結構其實可適用於分散式快取和本地快取的資料結構。通過構建該資料結構就能快速拿到類目樹中的任一節點。
三、總結
雖然類目結構不復雜，但因為其使用非常頻繁，所有在電商系統中需要好好設計類目的存取。介紹了一些分散式快取和本地快取，但不詳細，詳細的快取知識可參考網上其他資料。上面講到的本地快取的實現方式也是借鑑了淘寶的類目體系，如果非要使用本地快取也可以參考一下。
更多文章歡迎訪問 http://www.apexyun.com/
聯絡郵箱：public@space-explore.com
(未經同意，請勿轉載)