C2B 模式下優惠券架構演進

• 業務介紹

• 名詞解釋

• 演進過程

• 感悟 & 總結

• 作者介紹

業務介紹

轉轉 C2B 回收業務，一句話概括就是從用戶手中回收 3C 數碼產品。

用戶選擇想要估價商品進行估價，如用戶認爲合理則可以將商品郵寄至平臺，平臺收貨後進行質量檢測，同時向用戶提供確切的報價，用戶權衡覺得合理後，可以點擊確認回收，平臺將給用戶進行打款。

那麼如何有效提升用戶下單量呢？報價合理的基礎上，我們還需要給予用戶一定的現金補貼，買家端稱之爲 “滿減券”, 而賣家端則是 “滿加券”， 後續都統稱爲 “加價券”，賣家用戶滿足一定售出金額的時候平臺會給用戶額外進行一定比例或者固定金額的價格補貼。

接下來我們將詳細講一下加價券業務的演進歷程。

名詞解釋

權益配置：存儲的是加價券的配置信息

券關係表：存儲的是加價券與用戶的綁定關係

演進過程

1.0 試驗階段

關鍵字：探索、不確定性

在項目初期，對於加價券的數據模型並沒有明確定義，產品也不確定什麼樣的玩法會對用戶產生比較有效的激勵， 所以加價券的數據結構會頻繁發生改變。

所以我們將加價券的配置寫入到阿波羅配置中心，好處是可以快速上線進行實驗，方便隨時修改加價券的數據結構，雖然配置中心的缺點也很明顯（沒有強校驗規則，產品配置成本高，易錯），但是早期並沒有過多的券配置，技術協助 review 即可。

券關係表即用戶與加價券關聯關係數據，由於項目初期對數據量以及增長沒有明確的指標，所以沒有進行分庫分表，只是使用了一張表進行存儲，在增長量逐漸明確後再進行數據的拆分以及遷移。

2.0 平臺化建設

關鍵字：規範化

經過一段時間的試驗階段， 產品明確了加價券的玩法以及數據模型。加價券已經不再僅僅服務於線上回收業務，例如上門回收、線下門店回收、端外回收等業務也逐漸接入加價券，配置中心的弊端逐漸暴露了出來。

第一階段也提到使用阿波羅的不便之處：

• 缺少校驗規則, 容易出現配置錯誤, 引發線上問題

• 產品需要對 json 操作熟練，配置成本較高

• 沒有可視化工具不便於維護

爲了讓他們減少操作成本，處理更規範化，以及提供一些便利的運營工具給他們使用，所以 2.0 建設廢除了阿波羅配置中心，搭建了一套營銷後臺。

3.0 大表拆分成小表

隨着業務發展用戶綁定券的數量越來越多，單表已經接近上億的量級，預估到五年後數據量過大造成系統性能問題，所以在本階段建設過程中對券關係表進行分庫分表處理。

首先我們知道，分庫分表方案有兩種：

1. 基於 JDBC 進行一層代理，該方案只需要後端參與即可

2. 基於數據庫進行一層代理，該方案需要 DBA 或者運維的介入，維護起來不方便。

爲了降低人力成本，我們選擇了 JDBC 代理，框架選用的市面上使用比較多的 sharding-jdbc，這個框架社區比較活躍方便後面快速定位、解決問題。

根據當前的數據量以及增長效率簡單得出一個增長模型，大概估算出未來五年券關係總量，計算出了對應的庫表數量, 這裏將單表拆分成 8 庫 8 表即可。

加價券的場景都是由與某個用戶強相關，例如加價券列表或用戶篩選最合適的加價券進行覈銷，所以我們使用用戶的 uid 進行 hash 運算來進行分表。

那麼我們如何篩選合適的券給用戶呢？

用戶進行券覈銷的時候需要根據分類、品牌、機型等信息進行篩選, 篩選條件過多。由於數據量過多，直接進行表關聯並不合適，爲了加快上線節奏，本次也沒有考慮使用第三方的中間件進行檢索。

考慮到加價券在這個階段配置數量不會過多，解決方案是將券配置信息緩存到本地，運營在後臺新增或者修改券的時候通過 MQ 廣播通知各個機器進行更新。爲了保證數據準確，還有一個定時任務定時去進行兜底更新，這樣在篩選加價券的時候會先去內存中過濾出符合用戶要求的券配置 id，再通過這些配置 id 去數據庫直接獲取相應的加價券即可。

4.0 智能化建設

智能化指的是，通過用戶的一些行爲（下單，評價，瀏覽商品等）進行分析並給用戶發一些適合的券，不再是通過一些活動發放固定類型的加價券。

流程如下：

所謂術業有專攻，智能化發券我們通過算法推薦組的相關同事協助進行大數據分析。實現過程爲通過 kafka 獲取到用戶的相關行爲的埋點日誌，再使用 Flink 接收到 kafka 消息進行信息規則過濾，過濾出想要的信息，上報給搜索推薦服務, 當用戶進入活動頁的時候, 查詢推薦服務獲取到用戶最合適的券發給用戶。

5.0 引入 ElasticSearch 中間件

當數據庫中的數據多到一定規模時，數據庫就不適用於複雜的查詢了，往往只能滿足普通查詢的場景。對於全文檢索、可變數據結構等場景，數據庫天生不適用。因此需要針對特定的場景，引入合適的解決方案。

經過 4.0 的建設之後，隨着產品需求越來越多，產品需要大量建券進行黑盒實驗，來給用戶進行定製化發券，券配置放到本地可能會有內存 OOM 的風險，系統穩定性存在嚴重的問題，所以需要找到另一種合適的方案進行數據檢索，目前比較適合的方案就是 ElasticSearch, 通過介入 Es 來簡化加價券的檢索。

當然，引入更多組件同時會提高系統的複雜度，不同的組件保存的數據需要同步，需要考慮一致性的問題，需要有更多的運維手段來管理這些組件等, 不過對於當前加價券場景對於強一致性沒有那麼強的需求，秒級延遲完全可以接受，只需要保證最終一致性即可。

附一些 ES 集羣優化手段：

• 壓縮數據傳輸大小，ES 索引只建立需要檢索的字段，查詢的時候只獲取主鍵 id，提升網絡傳輸效率。

• 減少檢索範圍，因爲加價券查詢場景都是跟用戶掛鉤，所以根據 uid 進行分片，檢索的時候依據 uid 進行路由，可極大減少檢索數量。

• 限制數據總量，對於已過期的加價券，沒有必要長期保留，可定期進行歸檔，mysql 數據可歸檔在 TiDB， es 數據無需保留，保證數據庫以及 es 集羣數據總量達到可控的範圍。

• 選取合適的字段, 例如在 5.x 版本下如果對於數字類型進行精確查找，不會進行範圍查找，建議使用 keyword 字段, 例如品類、機型信息。

6.0 引入 NoSql、從庫等提升穩定性

隨着業務方越來越多，查詢請求量級越來越大，高峯會達到 1W+qps, 對服務端以及數據庫的穩定性都形成了極大的考驗

對於服務的穩定性，進行了以下優化：

• 讀寫分離, 大部分是讀多寫少場景, 高併發場景, 例如秒殺場景, 讀寫分離可以保證寫入的穩定性, 而加價券場景對於從庫的延遲也可以容忍。

• 緩存覆蓋, 對於常用接口進行 redis 緩存處理，減少數據庫查詢負擔。

• 熔斷降級，當 Es 集羣或服務端不可避免出現抖動導致超時的時候，及時進行熔斷處理，觸發兜底策略，保證系統能夠穩定運行。

感悟 & 總結

1. 不需要過度設計

2. 協調合適的人幫忙做合適的事

3. 多跟同事交流技術心得，可以便於快速解決問題，也可以幫助我們在工作中得到啓發

4. 有沒有一些架構設計的原則？

• 回滾設計。確保系統可以向前兼容，在系統升級時應能有辦法回滾版本；

• 禁用設計。應該提供控制具體功能是否可用的配置，在系統出現故障時能夠快速下線功能；

• 監控設計。在設計階段就要考慮監控的手段；

• 採用成熟的技術。剛開發的或開源的技術往往存在很多隱藏的 bug，出了問題沒有商業支持可能會是一個災難；

• 資源隔離設計。應避免單一業務佔用全部資源；

• 架構應能水平擴展。系統只有做到能水平擴展，纔能有效避免瓶頸問題；

• 快速迭代。系統應該快速開發小功能模塊，儘快上線進行驗證，早日發現問題大大降低系統交付的風險；

作者介紹

王銳剛，幫賣創新技術部後端開發，負責線上回收業務。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ddPFwOzK29brU_Sfq0FjPA