一、前言

隨著商城業務渠道不斷擴展，促銷玩法不斷增多，原商城v2.0架構已經無法滿足不斷增加的活動玩法，需要進行促銷系統的獨立建設，與商城解耦，提供純粹的商城營銷活動玩法支撐能力。

我們將分系列來介紹vivo商城促銷系統建設的過程中遇到的問題和解決方案，分享架構設計經驗。

二、系統框架

2.1 業務梳理

在介紹業務架構前我們先簡單了解下vivo商城促銷系統業務能力建設歷程，對現促銷能力進行梳理回顧。在商城v2.0中促銷功能存在以下問題：

1. 促銷模型不夠抽象，維護混亂，沒有獨立的活動庫存；

2. 混亂的活動共融互斥關系管理，缺乏統一的促銷計價能力。

商城核心交易鏈路中商詳頁、購物車、下單這三塊關于計價邏輯是分開獨立維護的，沒有統一，如下圖所示。顯然隨著促銷優惠的增加或者玩法的變動，商城側業務重復開發量會顯著加大。

（圖2-1. 促銷計價統一前）

3. 促銷性能無法滿足活動量級，往往會影響商城主站的性能。

因與商城系統耦合，無法提供針對性的性能優化，造成系統無法支撐越來越頻繁的大流量場景下大促活動。

基于這些痛點問題，我們一期完成促銷系統的獨立，與商城解耦，搭建出促銷系統核心能力：

優惠活動管理

對所有優惠活動抽象出統一的優惠模型和配置管理界面，提供活動編輯、修改、查詢及數據統計等功能。并獨立出統一的活動庫存管理，便于活動資源的統一把控。

促銷計價

基于高度靈活、抽象化的計價引擎能力，通過定義分層計價的促銷計價模型，制定統一的優惠疊加規則與計價流程，實現vivo商城促銷計價能力的建設。推動完成vivo商城所有核心鏈路接入促銷計價，實現全鏈路優惠價格計算的統一，如下圖：

（圖2-2. 促銷計價統一后）

隨著一期促銷系統核心能力的完成，極大的滿足了業務需要，各類優惠玩法隨之增多。但伴隨而來的就是各種運營痛點：

• 維護的促銷活動無法提前點檢，檢查活動效果是否符合預期；

• 隨著優惠玩法的增多，一個商品所能享受的優惠越來越多，配置也越來越復雜，極易配置錯誤造成線上事故；

為此我們開始促銷系統二期的能力建設，著重解決以上運營痛點：

• 提供時光穿越功能，實現用戶能夠“穿越”至未來某個時間點，從而實現促銷活動的提前點檢；

• 提供價格監控功能，結合「商城營銷價格能力矩陣」規劃的能力，通過事前/事中/事后多維度監控措施，來“降低出錯概率，出錯能及時止損”。

2.2 促銷與優惠券

促銷的主要目的就是向用戶傳遞商品的各種優惠信息，提供優惠利益，吸引用戶購買，從而起到促活拉新、提高銷量的目的。從這種角度來看，優惠券也屬于促銷的一部分。

但因一些原因vivo商城促銷系統獨立過程中，并沒有與促銷系統放一塊：

• 首先，優惠券系統在商城v2.0時就已獨立，已經對接很多上游業務，已經是成熟的中臺系統；

• 再者，就是優惠券也有相較與其它促銷優惠的業務特殊性，如有發券、領券能力。

在考慮設計改造成本就未將優惠券包括在促銷系統能力范疇，但優惠券畢竟也是商品價格優惠的一部分，因此促銷計價需要依賴優惠券系統提供券優惠的能力。

2.3 業務架構&流程

至此我們也就梳理出整個促銷系統的大概能力矩陣，整體架構設計如下：

（圖2-3. 促銷系統架構）

而隨著促銷系統獨立，整個商城購物流程與促銷系統的關系如下：

（圖2-4. 最新商城購物流程）

三、技術挑戰

作為中臺能力系統，促銷系統面臨的技術挑戰包括以下幾方面：

• 面對復雜多變的促銷玩法、優惠疊加規則，如何讓系統具備可擴展性，滿足日益多變的優惠需求，提升開發與運營效率。

• 面對新品發布、雙11大為客戶等大流量場景，如何滿足高并發場景下的高性能要求。

• 面對來自上游業務方的不可信調用，以及下游依賴方的不可靠服務等復雜系統環境，如何提升系統整體的穩定性，保障系統的高可用。

我們結合自身業務特點，梳理出一些技術解決方案。

3.1 可擴展性

擴展性提升主要體現在兩塊：

• 優惠模型的定義，對所有優惠活動抽象出統一的優惠模型和配置管理界面；

• 促銷計價引擎的建立，計價模型的統一。

相關的詳細設計內容，會有后續文章進行說明。

3.2 高并發/高性能

緩存

緩存幾乎就是解決性能問題的“銀彈”，在促銷系統中也大量使用緩存進行性能提升，包括使用redis緩存與本地緩存。而使用緩存就需要關注數據一致性問題，redis緩存還好解決，但本地緩存不就好處理了。因此本地緩存的使用要看業務場景，盡量是數據不經常變更且業務上能接受一定不一致的場景。

批量化

促銷系統的業務場景屬于典型的讀多寫少場景，而讀的過程中對性能影響最大的就是IO操作，包括db、redis以及第三方遠程調用。而對這些IO操作進行批量化改造，以空間換時間，減少IO交互次數也是性能優化的一大方案。

精簡化/異步化

簡化功能實現，將非核心任務進行異步化改造。如活動編輯后的緩存處理、資源預占后的消息同步、拼團狀態流轉的消息通知等等。

冷熱分離

對于讀多寫少場景對性能影響最大的除了IO操作，還有就是數據量，在促銷系統中也存在一些用戶態數據，如優惠資源預占記錄、用戶拼團信息等。這些數據都具備時間屬性，存在熱尾效應，大部分情況下需要的都是最近的數據。針對這類場景對數據進行冷熱分離是最佳選擇。

3.3 系統穩定性

限流降級

基于公司的限流組件，對非核心的服務功能進行流量限制與服務降級，高并發場景下全力保障整體系統的核心服務

冪等性

所有接口均具備冪等性，避免業務方的網絡超時重試造成的系統異常

熔斷

使用Hystrix組件對外部系統的調用添加熔斷保護，防止外部系統的故障造成整個促銷系統的服務崩潰

監控和告警

通過配置日志平臺的錯誤日志報警、調用鏈的服務分析告警，再加上公司各中間件和基礎組件的監控告警功能，讓我們能夠第一時間發現系統異常

四、踩過的坑

4.1 Redis SCAN命令使用

在Redis緩存數據清除的處理過程中，存在部分緩存key是通過模糊匹配的方式進行查找并清除操作，底層依賴Redis SCAN命令。

SCAN命令是一個基于游標的迭代器，每次被調用之后都會向用戶返回一個新的游標， 用戶在下次迭代時需要使用這個新游標作為 SCAN 命令的游標參數， 以此來延續之前的迭代過程。

對于使用KEYS命令，SCAN命令并不是一次性返回所有匹配結果，減少命令操作對Redis系統的阻塞風險。但并不是說SCAN命令就可以隨便用，其實在大數據量場景下SCAN存在與KEYS命令一樣的風險問題，極易造成Redis負載升高，響應變慢，進而影響整個系統的穩定性。

（圖4-1 Redis負載升高）

(圖4-2 Redis響應出現尖刺)

而解決方案就是：

• 優化Redis key設計，減少不必要的緩存key；

• 移除SCAN命令使用，通過精確匹配查找進行清除操作。

4.2 熱點key問題

在促銷系統中普遍使用redis緩存進行性能提升，緩存數據很多都是SKU商品維度。在新品發布、特定類型手機大促等業務場景下極容易產生熱點Key問題。

熱點Key具有聚集效應，會導致Redis集群內節點負載出現不均衡，進而造成整個系統不穩定。該問題是普通的機器擴容無法解決的。如下圖某次線上摸排壓測時redis負載情況：

常用的解決方案有兩種：

• 散列方案：對Redis Key進行散列，平均分散到RedisCluster Nodes中，解決熱點Key的聚集效應。

• 多級緩存方案：對熱點Key增加使用本地緩存，最大限度加速訪問性能，降低Redis節點負載。

我們是采用多級緩存方案，參照優秀的開源熱點緩存框架，定制化擴展出一整套熱點解決方案，支持熱點探測 、本地緩存 、集群廣播以及熱點預熱功能，做到準實時熱點探測并將熱點Key通知實例集群進行本地緩存，極大限度避免大量重復調用沖擊分布式緩存，提升系統運行效率。

五、總結

本篇屬于vivo商城促銷系統概覽介紹篇，簡單回顧了vivo商城促銷系統業務能力建設歷程及系統架構，并分享遇到的技術問題與解決方案。后續我們會對促銷系統的核心功能模塊（優惠活動管理、促銷計價、價格監控和時光穿越）的設計實踐進行逐個分享，敬請期待。

作者：vivo互聯網官方商城開發團

總結

以上是生活随笔為你收集整理的vivo商城促销系统架构设计与实践-概览篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。