轉轉運營系統之商品標簽平臺
1. 背景
轉轉作為國內領先的二手電商平臺，商品品類橫跨數碼3C、家電家居乃至奢品、汽車，用戶群體與需求呈現顯著差異化。例如，學生群體側重性價比，白領階層偏好品質服務。為了實現商品與用戶的精準匹配，就需要精細化的運營策略，然而，精細化的運營卻面臨以下難題：
1.1 精細化運營面臨四大難題
- 二手商品數據復雜性高：二手商品除了商品本身的標品屬性外，還存在成色、機況、質檢報告等大量的非標屬性。這些屬性描述方式多樣，缺乏統一標準，信息分散在商品描述、圖片、質檢報告等不同地方，導致商品數據結構復雜，難以標準化管理。
- 商品管理和篩選效率低下：傳統電商的標準化SPU維度無法有效處理二手商品豐富的非標屬性，平臺難以基于這些關鍵屬性對商品進行精細化管理和篩選。
- 用戶體驗受影響：由于缺乏對非標屬性的有效利用，導致用戶在搜索商品時難以精準定位到符合需求的商品，例如，用戶想要搜索“成色好”的二手手機，傳統篩選系統可能無法有效支持這種基于非標屬性的搜索。
- 運營效率難以提升：由于數據復雜且難以有效管理，平臺難以基于數據進行深入分析，無法精準了解商品銷售情況、用戶偏好等，從而難以制定有效的數據驅動運營策略，限制了運營效率的提升。
1.2 商品標簽平臺旨在解決上述痛點
- 結構化非標屬性數據：將分散、非結構化的非標屬性信息轉化為結構化的標簽，實現數據標準化管理。
- 提高商品管理和篩選效率：基于標簽系統，平臺可以高效地篩選和管理商品，提升運營效率。
- 提升用戶體驗：通過基于標簽系統的精準搜索和推薦，幫助用戶快速找到心儀的商品，提升購物體驗。
- 實現數據驅動運營：利用標簽數據進行深入分析，為平臺運營決策提供數據支持，提升運營效率和競爭力。
2. 系統總覽
整個商品標簽平臺大致上可分為三層：
系統架構圖
應用層：應用層作為系統的入口，負責提供用戶操作界面（后臺配置中心、標簽后臺組件）和RPC 接口，是用戶和外部系統與標簽平臺進行交互的通道。
服務層：服務層是系統的核心業務處理層，負責執行關鍵的商品標簽匹配、標簽生命周期管理、離線數據管理、商品管理和數據互聯互通等核心業務邏輯。
數據層：數據層為服務層提供多樣化的數據存儲能力，包括關系型數據庫（MySQL）、搜索引擎（ES）、本地緩存（Local Cache）和分布式緩存（Redis），以滿足不同類型數據的存儲和高效訪問需求。
3. 系統核心設計之如何保證標簽的實時性
3.1 背景
作為電商平臺，商品的更新和用戶的行為都會時刻發生，商品標簽的實時性會直接影響到用戶的體驗和整體的運營效率。那么在標簽平臺中，是如何設計來保證實時性呢？
實時性設計示意圖
解釋：增量（給變動的商品重新匹配標簽）；存量（給符合標簽規則的商品進行標簽綁定）
3.2 核心設計
- 流量分離：上圖中，雖然執行的都是商品和標簽的匹配操作，但明確區分了實時性要求高的增量打標和非實時性的存量打標。為什么這么做呢？
流量分離示意圖
- 提升實時打標響應速度：增量打標專注于處理商品變更、價格變更等實時事件，通過消息隊列驅動，可以做到事件發生時立即觸發打標流程，大幅降低打標延遲，保證實時性。
- 降低存量打標對實時性的影響：存量打標通常存在不確定性，標簽圈選的商品數量級未知，將存量與增量打標分離，可以避免存量打標任務對實時打標鏈路造成性能沖擊，保證實時打標的穩定性和低延遲。
- 資源隔離，提升系統穩定性：將不同類型的打標任務隔離處理，可以更好地進行資源調配和管理，避免資源爭搶，提升系統的整體穩定性。
- 事件驅動：通過對商品進行監聽，讓系統對商品數據的變更事件立即做出反應，而不是被動等待或輪詢。當商品數據發生變化（例如商品創建、更新、價格變動、屬性變更等）時，系統能夠立即捕獲這些事件，并觸發后續的打標流程。
事件驅動示意圖 - 引入去重 MQ (Deduplication MQ) 機制：在實踐中發現，一個商品的某一塊數據發生了變化，那么其他數據會產生一種聯動效應，一起發生變化，所以在增量通道中新增"ES處理去重MQ"和"增量標簽匹配去重MQ"兩種去重消息隊列，減少因消息重復導致的商品與標簽的重復匹配，提升標簽數據的準確性和可靠性，降低不必要的資源消耗。
MQ去重示意圖
4. 系統核心設計之如何保證數據的一致性
4.1 背景
針對存量打標，是對平臺所有存量商品進行標簽匹配的操作。涉及大量數據的批量處理，數據量巨大，處理時間長，處理環節多，任何環節出現異常都有可能導致數據不一致的發生。為了避免這種情況的發生，平臺建立了一套完整的機制，用于保證數據的一致性。
數據一致性設計流程圖
4.2 機制拆解
- 全局統一入口：定義打標任務統一入口，確保每次打標任務都能夠按照預設的流程執行下去，最終形成任務流的閉環。
- 全局互斥鎖：每個存量打標任務圈選的商品數量是不可預測的，可能存在前一個任務還未執行完成，后一個任務已經啟動的情況，所以采用全局互斥鎖的操作，來保證同一時刻，只有一個任務在執行打標任務，避免多任務并發執行導致任務流執行紊亂。
- 全局異常捕獲：任務即使做了統一入口的操作，但在任務執行過程中，也會出現因為任務內部異常導致執行流中斷的情況，所以就引入全局異常捕獲機制，并記錄異常任務的執行進度，為后續任務恢復提供數據保證。
- 異常任務恢復：每次新任務開始執行之前，默認校驗上次任務是否存在異常，如果存在異常，就根據異常任務的執行進度，開展異常任務斷點續傳的操作，進一步避免由于任務異常中斷而導致數據遺漏問題。
- 數據異步處理：利用MQ的異步化處理能力，提升系統效率的同時，并結合MQ的持久化和消息可靠投遞機制，保障任務的順利向下游執行，降低數據丟失的風險。
為了保證數據的一致性，在任務執行的過程中每個步驟環環相扣，嚴密協作。從任務級別的全局互斥鎖，到流程內部的斷點續傳機制，再到消息隊列的可靠傳輸，以及全局異常監控，每一個步驟都指向了同一個目標：確保存量商品標簽數據更新的完整性、準確性和可靠性，最終實現系統數據的一致性。
5. 系統核心設計之如何消除數據讀取瓶頸
5.1 背景
在整個系統中，特別是進行規則匹配時，往往需要頻繁地根據規則去查找、讀取大量的標簽基礎數據。如果每次都直接從MySQL讀取，在高并發、大數據量的情況下，MySQL很容易成為性能瓶頸，嚴重影響打標整體效率。為了避免這種現象的發生，設計了一套健全的多級緩存結構。
多級緩存設計示意圖
5.2 核心理念
- 多級緩存的數據維護
- 始終以MySQL為權威源，所有上層緩存都遵循隨MySQL數據變而變的基本原則
- 特殊場景主動清理，在“存量打標任務”啟動時，優先主動清理本地緩存和Redis緩存，確保任務基于最新數據進行
- 數據按需加載，緩存數據通常在首次訪問時，從更權威的數據源 (Redis 或 MySQL) 按需加載并緩存
- 多級緩存的數據讀取
性能高度依賴緩存，多級緩存是保證打標效率的重要組件之一，所以在整個標簽系統的匹配流程中，始終遵循緩存優先原則
容錯降級能力設計：在整個緩存數據使用中，即使部分緩存層失效，系統仍能退回到下層緩存或數據庫，以短暫的性能損失來保證整個標簽數據的可用性
多級緩存架構在整個打標系統中至關重要。維護上，以MySQL為權威，緩存失效策略為主，輔以特殊場景清理；讀取上，緩存是性能核心，數據獲取分層依賴，并具備容錯能力。并且這種設計在性能、一致性和可靠性之間取得了平衡，從而支撐起高效穩定的打標流程。
6. 未來構想
標簽平臺作為轉轉運營系統中的重要組成部分之一，未來還有很大的效率提升空間，后續也將從以下幾部分入手，進一步提升效率：
- 商品維度：支撐商品打標數量級由百萬級至千萬級
- 標簽維度：標簽數據的結構化，如對標簽數據樹形化處理，利用樹的特點，提升匹配效率等
7. 總結
轉轉商品標簽平臺的成功實踐，充分證明了結構化非標數據對于二手電商平臺精細化運營的重要性。平臺提供了一種技術驅動的解決方案，巧妙地結合了分層架構、事件驅動、消息隊列、多級緩存、和數據一致性保障機制等技術手段，有效解決了精細化運營的痛點，并提供強大的技術支持。
