vivo 瀏覽器為應對多場景金幣激勵需求及舊架構流量、IO等痛點，升級福利中心架構。服務層面拆分流量與業務，打造金幣集散中心；數據層面分庫分表、拆解大表并優化流水設計；通過仲裁系統和軟事務保障數據一致性。改造后，系統可支撐千萬級DAU，性能穩定提升，物理存儲成本降低，解決了流量與存儲壓力，成為高可用可復制架構，且將持續迭代保持競爭力。

作者：vivo 互聯網服務器團隊 - Zhang Xian、Zhang Baolin

vivo 瀏覽器為應對多場景金幣激勵需求及舊架構流量、IO等痛點，升級福利中心架構。服務層面拆分流量與業務，打造金幣集散中心；數據層面分庫分表、拆解大表并優化流水設計；通過仲裁系統和軟事務保障數據一致性。改造后，系統可支撐千萬級DAU，性能穩定提升，物理存儲成本降低，解決了流量與存儲壓力，成為高可用可復制架構，且將持續迭代保持競爭力。

 

1分鐘看圖掌握核心觀點??

一、業務背景

在數字化產品的運營策略中，金幣激勵體系作為一種行之有效的用戶激勵手段，正被廣泛應用于各類平臺，尤其是在內容消費類為主導的資訊，短視頻、小說、短劇等賽道的APP中，金幣激勵能夠讓用戶更好地體驗到產品帶來的價值和服務。它通過虛擬金幣的發放與回收，改變用戶行為，提升用戶參與度、活躍度和忠誠度，為平臺創造價值。

 

vivo瀏覽器作為vivo互聯網生態中的內容媒體，早在2021年就已經引入金幣激勵體系，在瀏覽器小說渠道做產品運營與金幣用戶培育。在2024年初，由于在內容賽道與非內容賽道（如美團，拼多多等），均已上線金幣激勵體系。vivo瀏覽器的產品生態急需升級，經過多方面考量，決定在視頻tab場景嘗試接入金幣激勵體系。所以業務需求應運而生，而老舊的架構體系，無法滿足vivo瀏覽器的大規模用戶帶來的流量沖擊，故技術團隊開始著手瀏覽器福利架構的升級工作。

 

二、技術痛點

早期的架構單純支撐vivo瀏覽器小說用戶，設計相對原始，宗旨是滿足當前業務即可，基本架構圖如下：

 

初期的架構設計比較簡單，數據庫沒有做分庫，僅針對用戶做hash分表，對金幣流水做按月分表，定期創建，定期刪除。

 

初期業務流量較小，基本沒什么問題。隨著業務的不斷發展，金幣玩法愈發多樣化，這套設計無法滿足以下業務場景：

• 任務玩法多：金幣玩法越來越多，定制化邏輯越來越復雜，單服務既要完成任務流轉，也要完成金幣流轉，功能劃分不夠清晰，代碼復雜度增高。

• 服務壓力：vivo瀏覽器帶來的大規模用戶流量，從百萬級DAU預計增長至千萬級DAU，當前架構無法通過擴容等手段來解決問題。

• IO瓶頸：由于是單庫設計，偶爾出現數據庫性能問題。

• 金幣泄露：對賬邏輯較為樸素，無嚴格的數據一致性校驗。

• 安全漏洞：風控策略存在遺漏，容易成為黑灰產的攻擊對象。

 

鑒于以上問題，技術團隊開始著手對現有架構做改造和升級，以支撐日漸增長的業務訴求。

 

三、架構升級

針對以上痛點，結合當前業務需求和未來的業務發展動向，我們架構設計需要考慮支持幾點：

• 支持多形態任務玩法：通過細化服務功能，抽象任務狀態機流轉模型，快速支持各種形態的激勵任務。

• 支撐大流量：結合瀏覽器流量特點，設計出一套滿足高并發高性能的服務群架構。

• IO無壓力：通過集成分布式數據庫，緩解大流量帶來的數據庫壓力。

• 數據安全：需要滿足金幣數據的高精度準確性，確保用戶資產安全。

• 風控嚴格：通過完善的風控機制，精準定位黑灰產，降低業務運營成本。

 

此外，新架構設計還考慮到以下兩點：

1. 支持業務動態擴展：

   架構清晰簡單，每一個服務中的模塊分工明確，低耦合，方便水平擴展，支持業務快速迭代。

2. 低成本可復制

   注重底層數據邏輯的可重用性，為以后多套代幣業務提供服務模版，提高開發效率，降低時間和人力成本。

 

綜上，我們需要打造一整套完整的福利中心架構體系，圍繞金幣激勵解決直接關聯的問題，以及相關衍生的問題。

我們的目標是圍繞用戶時長增長和商業化變現能力提升，打造出一整套由配置管理，任務流轉，金幣集散，安全風控和基礎能力組合而成的福利中心能力矩陣，締造一個支持多場景增強的可復制架構。

 

四、改造方案

針對當前問題，結合物理資源的限制，技術團隊從以下幾個方面著手，對系統進行改造升級。整體架構設計圖如下：

 

4.1 服務層面

4.1.1 流量隔離

按照流量入口，拆分服務，將瀏覽器小說業務，瀏覽器信息流業務，瀏覽器通用業務，拆分開。域名統一，通過path定向分發到各自服務。

 

服務拆分

根據同一代幣同一系統原則，拆分瀏覽器金幣業務和趣閱金幣業務。二者獨立迭代，獨立發展，風控策略獨立，仲裁系統按照業務維度區分數據，但能力公用。兩套服務群功能可借鑒，服務可復制。

 

4.1.2 金幣互通

收口金幣管理相關功能，打造全新的金幣集散中心，管理各渠道的金幣增減行為。金幣互通模塊的基本功能架構拆解如下：

 

4.2 數據層面

針對原有單庫的性能瓶頸，對數據庫進行如下改造：

 

4.2.1 分庫分表

分庫按照用戶維度一次hash，分表按照用戶維度進行二次hash。根據瀏覽器全網用戶存量，分為N個庫，每個庫M張用戶表。

 

4.2.2 大表拆解

拆分原有的用戶大表，將訂閱，抽獎等信息獨立建表，用戶表只存放最關鍵的金幣總額信息。訂閱，抽獎等表項，只為push等業務運營場景使用，極大降低因全表掃描導致的數據庫性能瓶頸。

 

4.2.3 結余設計

重新設計金幣流水信息表，增加用戶金幣月余表項，改造金幣消費扣減的邏輯，避免因為扣減導致的一次查詢多張表項，提升性能。

 

在原有系統中，金幣流水記錄表設計中，是按月分表，表項里面有兩個重要信息，一個是當前流水金幣凈得數量，另一個是當前流水金幣剩余數量。金幣扣減時，需要循環遍歷用戶的每一條金幣流水記錄，逐一扣減，同時需要記錄每一個用戶扣減到哪一條流水記錄。對于中低活用戶，一次扣減可能需要遍歷查詢12張金幣流水表，逐一扣減。如下圖所示：

 

用戶1扣減時，按照時間由遠及近，逐一扣減每一條流水記錄，若當月表不夠扣減總額，則繼續找下一張表即系重復此操作。因此，在極端情況下，性能較差。平均情況下，由于每次的操作記錄數量不可控，所以性能波動較大，接口RT不可控。

 

鑒于此問題，新系統對金幣流水表按照用戶分表，同時根據業務需求，金幣流水只存儲最近N個月的流水明細，方便用戶查看明細。超過N個月之前的流水自動歸檔到月余表中，刪除N個月之前的金幣流水。并且完整流水記錄按月離線備份到hive中。歸檔公式如下：

 

每次用戶扣減金幣時候，只需要將月余信息拿出來，由遠及近直接扣減即可，單表一次性操作，性能得到了極大提升，同時不會因為低活用戶而遍歷多張表，所以性能非常穩定。另外，這樣極大地壓縮了數據庫存儲空間。

 

4.3 數據一致性

4.3.1 仲裁系統

舊的架構沒有考慮對金幣的數據準確性做強一致性的校驗，所以會收到客訴，對口碑造成一定負面影響。

 

新架構集成了仲裁系統，包含對賬，復核，平賬，補償等功能。多種條件會觸發用戶金幣的對賬，確保金幣數據的一致性，同時配合審計復核，實現精準對賬。

 

對于復核失敗的用戶，新的架構新增離線數據任務系統，集成即時通知，實時查詢歷史數據等功能，方便運營和開發人員及時處理，降低FAQ頻次，提升口碑。

 

4.3.2 軟事務

福利中心金幣領取、提現、權益兌換部分場景涉及到跨服務調用的情況。由此帶來分布式事務數據一致性的問題，我們采用了軟事務來處理這些一致性問題。

 

金幣增減通過單庫事務實現，跨系統或者跨庫由輕事務負責，用來減少編碼難度，避免TCC的侵入。

 

金幣領取場景，使用訂單id對每筆金幣領取進行綁定，以便追蹤金幣領取狀態。接口網絡異常時快速通過訂單id確認訂單狀態，記錄未成功的訂單，進行離線補償。以確保金幣領取最終一致性。

 

4.3.4 小結

經過以上幾方面的改造和升級，我們將一個以金幣驅動單場景樸素邏輯結構，改造升級成為一個場景增強型的高可用可復制架構，以支撐業務的發展需求。

 

五、結束語

vivo瀏覽器福利中心，結合業務需求，針對原有架構痛點進行改造和升級，成功解決了原有系統的流量壓力和存儲壓力，月余設計巧妙地結合業務，極致壓縮了物理存儲成本的同時，改進了金幣扣減邏輯，使性能得到穩定提升，成為支持千萬級DAU無風險運行的一套服務群。架構升級過程中，還有許多細節點，由于篇幅限制，不再一一贅述。

 

架構升級不是終點，而是新征程的起點。我們在業務不斷迭代的過程中，一直在不斷嘗試使用新思路，持續打磨架構，讓其在動態變化中保持行業領先的競爭力。