B 站評論系統架構設計

本期作者

黃振

社區業務技術組高級開發工程師

01 背景

維基百科對「評論」的定義是：評論是人們對出版物、服務或公司的評估，例如電影（電影評論）、電子遊戲（視頻遊戲評論）、音樂製作（對作品錄音作品的音樂評論）、圖書（書評）、硬件，如汽車、家用電器或電子計算機、商業軟件、活動或表演，例如音樂會、戲劇、音樂劇、舞蹈或藝術展覽。除了批判性評論之外，評論的作者還可以對作品進行內容分級以表明其相對價值。

在 B 站，UP 主每天都會發布海量的視頻、動態、專欄等內容，隨之而來的是彈幕和評論區的各種討論。播放器中直接滾動播放的彈幕，如同調味劑，重在提升視頻觀看體驗；而點進評論區，相對而言評論文本更長，內容的觀點、形式都更豐富，更像是飯後甜點。

隨着業務不斷髮展，B 站的評論系統逐漸組件化、平臺化；通過持續演進架構設計，管理不斷上升的系統複雜度，從而更好地滿足各類用戶的需求。

02 基礎功能模塊

評論的基礎功能模塊是相對穩定的。

  1. 發佈評論：支持無限蓋樓回覆。

  2. 讀取評論：按照時間、熱度排序；顯示評論數、樓中樓等。

  3. 刪除評論：用戶刪除、UP 主刪除等。

  4. 評論互動：點贊、點踩、舉報等。

  5. 管理評論：置頂、精選、後臺運營管理（搜索、刪除、審覈等）。

結合 B 站以及其他互聯網平臺的評論產品特點，評論一般還包括一些更高階的基礎功能：

  1. 評論富文本展示：例如表情、@、分享鏈接、廣告等。

  2. 評論標籤：例如 UP 主點贊、UP 主回覆、好友點贊等。

  3. 評論裝扮：一般用於凸顯發評人的身份等。

  4. 熱評管理：結合 AI 和人工，爲用戶營造更好的評論區氛圍。

03 架構設計

評論是主體內容的外延。因此一般會作爲一個獨立系統拆分設計。

** 3.1 架構設計 - 概覽**

圖片

** 3.2 架構設計 - reply-interface**

reply-interface 是評論系統的接入層，主要服務於兩種調用者：一是客戶端的評論組件，二是基於評論系統做二次開發或存在業務關聯的其他業務後端。

面向移動端 / WEB 場景，設計一套基於視圖模型的 API，利用客戶端提供的佈局能力，BFF 層負責組織業務數據模型，並轉換爲視圖模型，編排後下發給客戶端。

面向服務端場景，設計的 API 需要體現清晰的系統邊界，最小可用原則對外提供數據，同時做好安全校驗和流量控制。

圖片

對評論業務來說，業務數據模型是最爲複雜的。B 站評論系統歷史悠久，承載的功能模塊相當之多，其中最核心的是發佈類接口以及列表類接口，一寫一讀，數據字段多、依賴服務多、調用關係複雜，特別是一些依賴的變更，容易造成整個系統的腐化。

因此，我們將整個業務數據模型組裝，分爲兩個步驟，一是服務編排，二是數據組裝。服務編排拆分爲若干個層級，同一層級的可以併發調用，前置依賴較多的可以流水線調用，結構性提升了複雜調用場景下的接口性能下限；針對不同依賴服務所提供的 SLA 不同，設置不同的降級處理、超時控制和服務限流方案，保證少數弱依賴抖動甚至完全不可用情況下評論服務可用。數據組裝在服務編排之後執行，例如在批量查詢評論發佈人的粉絲勳章數據之後，將其轉換、組裝到各個評論卡片之中。

** 3.3 架構設計 - reply-admin**

評論管理服務層，爲多個內部管理後臺提供服務。運營人員的數據查詢具有：

  1. 組合、關聯查詢條件複雜；

  2. 剛需關鍵詞檢索能力；

  3. 寫後讀的可靠性與實時性要求高等特徵。

此類查詢需求，ES 幾乎是不二選擇。但是由於業務數據量較大，需要爲多個不同的查詢場景建立多種索引分片，且數據更新實時性不高。因此，我們基於 ES 做了一層封裝，提供統一化的數據檢索能力，並結合在線數據庫刷新部分實時性要求較高的字段。

圖片

** 3.4 架構設計 - reply-service**

評論基礎服務層，專注於評論功能的原子化實現，例如查詢評論列表、刪除評論等。一般來說，這一層是較少做業務邏輯變更的，但是需要提供極高的可用性與性能吞吐。因此，reply-service 集成了多級緩存、布隆過濾器、熱點探測等性能優化手段。

圖片

** 3.5 架構設計 - reply-job**

評論異步處理層，主要有兩個職責：

  1. 與 reply-service 協同，爲評論基礎功能的原子化實現，做架構上的補充。

爲什麼基礎功能的原子化實現需要架構的補充呢？最典型的案例就是緩存的更新。一般採用 Cache Aside 模式，先讀緩存，再讀 DB；緩存的重建，就是讀請求未命中緩存穿透到 DB，從 DB 讀取到內容之後反寫緩存。這一套流程對外提供了一個原子化的數據讀取功能。但由於部分緩存數據項的重建代價較高，比如評論列表（由於列表是分頁的，重建時會啓用預加載），如果短時間內多個服務節點的大量請求緩存未命中，容易造成 DB 抖動。解決方案是利用消息隊列，實現「單個評論列表，只重建一次緩存」。歸納而言，所謂架構上的補充，即是「用單線程解決分佈式無狀態服務的共性問題」。另一方面，reply-job 還作爲數據庫 binlog 的消費者，執行緩存的更新操作。

圖片

  1. 與 reply-interface 協同，爲一些長耗時 / 高吞吐的調用做異步化 / 削峯處理。

諸如評論發佈等操作，基於安全 / 策略考量，會有非常重的前置調用邏輯。對於用戶來說，這個長耗時幾乎是不可接受的。同時，時事熱點容易造成發評論的瞬間峯值流量。因此，reply-interface 在處理完一些必要校驗邏輯之後，會通過消息隊列送至 reply-job 異步處理，包括送審、寫 DB、發通知等。同時，這裏也利用了消息隊列的「有序」特性，將單個評論區內的發評串行處理，避免了並行處理導致的一些數據錯亂風險。那麼異步處理後用戶體驗是如何保證的呢？首先是 C 端的發評接口會返回展示新評論所需的數據內容，客戶端據此展示新評論，完成一次用戶交互。若用戶重新刷新頁面，因爲發評的異步處理端到端延遲基本在 2s 以內，此時所有數據已準備好，不會影響用戶體驗。

一個有趣的問題是，早年間評論顯示樓層號，樓層號實際是計數器，且在一個評論區範圍內不能出現重複。因此，這個樓層發號操作必須是在一個評論區範圍內串行的（或者用更復雜的鎖實現），否則兩條同時發佈的評論，獲取的樓層號就是重複的。而分佈式部署 + 負載均衡的網關，處理發評論請求是無法實現這種串行的，因此需要放到消息隊列中處理。

04 存儲設計

** 4.1 數據庫設計**

結合評論的產品功能要求，評論需要至少兩張表：首先是評論表，主鍵是評論 id，關鍵索引是評論區 id；其次是評論區表，主鍵是評論區 id，平臺化之後增加一個評論區 type 字段，與評論區 id 組成一個” 聯合主鍵 “。

由於評論內容是大字段，且相對獨立、很少修改，因此獨立設計第 3 張表。主鍵也是評論 id。

評論表和評論區表的字段主要包括 4 種：

  1. 關係類，包括髮布人、父評論等，這些關係型數據是發佈時已經確定的，基本不會修改。

  2. 計數類，包括總評論數、根評論數、子評論數等，一般會在有評論發佈或者刪除時修改。

  3. 狀態類，包括評論 / 評論區狀態、評論 / 評論區屬性等，評論 / 評論區狀態是一個枚舉值，描述的是正常、審覈、刪除等可見性狀態；評論 / 評論區屬性是一個整型的 bitmap，可用於描述評論 / 評論區的一些關鍵屬性，例如 UP 主點贊等。

  4. 其他，包括 meta 等，可用於存儲一些關鍵的附屬信息。

評論回覆的樹形關係，如下圖所示：

圖片

以評論列表的訪問爲例，我們的查詢 SQL 可能是（已簡化）：

  1. 查詢評論區基礎信息：SELECT * FROM subject WHERE obj_id=? AND obj_type=?

  2. 查詢時間序一級評論列表：SELECT id FROM reply_index WHERE obj_id=? AND obj_type=? AND root=0 AND state=0 ORDER BY floor=? LIMIT 0,20

  3. 批量查詢根評論基礎信息：SELECT * FROM reply_index,reply_content WHERE rpid in (?,?,...)

  4. 併發查詢樓中樓評論列表：SELECT id FROM reply_index WHERE obj_id=? AND obj_type=? AND root=? ORDER BY like_count LIMIT 0,3

  5. 批量查詢樓中樓評論基礎信息：SELECT * FROM reply_index,reply_content WHERE rpid in (?,?,...)

產品形態上，單個頁面只有二級列表（更多嵌套層次，對應嵌套多次點擊），且評論計數也只有兩級。若回覆數也要無限套娃，則一條子評論的發佈，需要級聯更新所有的父評論的回覆數，當前的數據庫設計不能滿足該需求。

再者，產品側定義是，若一級評論被刪除，其回覆也等價於全部刪除，若直接刪除，此時也可能出現寫放大。因此結合查詢邏輯，可以不對回覆做更新操作，但是評論區的計數更新操作，需要多減去該一級評論的回覆數。

評論系統對數據庫的選型要求，有兩個基本且重要的特徵：

  1. 必須有事務；

  2. 必須容量大。

一開始，我們採用的是 MySQL 分表來滿足這兩個需求。但隨着 B 站社區破圈起量，原來的 MySQL 分表架構很快到達存儲瓶頸。於是從 2020 年起，我們逐步遷移到 TiDB，從而具備了水平擴容能力。

** 4.2 緩存設計**

我們基於數據庫設計進行緩存設計，選用 redis 作爲主力緩存。主要有 3 項緩存：

  1. subject，對應於「查詢評論區基礎信息」，redis string 類型，value 使用 JSON 序列化方式存入。

  2. reply_index，對應於「查詢 xxx 評論列表」，redis sorted set 類型。member 是評論 id，score 對應於 ORDER BY 的字段，如 floor、like_count 等。

  3. reply_content，對應於「查詢 xxx 評論基礎信息」，存儲內容包括同一個評論 id 對應的 reply_index 表和 reply_content 表的兩部分字段。

reply_index 是一個 sorted set，爲了保證數據完整性，必須要判定 key 存在才能增量追加。由於存在性判定和增量追加不是原子化的，判定存在後、增量追加前可能出現緩存過期，因此選用 redis 的 EXPIRE 命令來執行存在性判定，避免此類極端情況導致的數據缺失。此外，緩存的一致性依賴 binlog 刷新，主要有幾個關鍵細節：

  1. binlog 投遞到消息隊列，分片 key 選擇的是評論區，保證單個評論區和單個評論的更新操作是串行的，消費者順序執行，保證對同一個 member 的 zadd 和 zrem 操作不會順序錯亂。

  2. 數據庫更新後，程序主動寫緩存和 binlog 刷緩存，都採用刪除緩存而非直接更新的方式，避免併發寫操作時，特別是諸如 binlog 延遲、網絡抖動等異常場景下的數據錯亂。那大量寫操作後讀操作緩存命中率低的問題如何解決呢？此時可以利用 singleflight 進行控制，防止緩存擊穿。

05 可用性設計

** 5.1 寫熱點與讀熱點**

2020 年的騰訊的辣椒醬不香了 [1]，引發一場評論區的狂歡。由於上文所述各類「評論區維度的串行」，當時評論發佈的吞吐較低，面對如此大的流量出現了嚴重延遲。

圖片

痛定思痛，我們剖析瓶頸並做了如下優化：

  1. 評論區評論計數的更新，先做內存合併再更新，可以減少熱點場景下的 SQL 執行條數；評論表的插入，改成批量寫入。

  2. 非數據庫寫操作的其他業務邏輯，拆分爲前置和後置兩部分，從數據寫入主線程中剝離，交由其他的線程池併發執行。

改造後，系統的併發處理能力有了極大提升，同時支持配置並行度 / 聚合粒度，在吞吐方面具備更大的彈性，熱點評論區發評論的 TPS 提升了 10 倍以上。

圖片

除了寫熱點，評論的讀熱點也有一些典型的特徵：

  1. 由於大量接口都需要讀取評論區基礎信息，存在讀放大，因此該操作是最先感知到讀熱點存在的。

  2. 由於評論業務的下游依賴較多，且多是批量查詢，對下游來說也是讀放大。此外，很多依賴是體量相對小的業務單元，數據稀疏，難以承載評論的大流量。

  3. 評論的讀熱點集中在評論列表的第一頁，以及熱評的熱評。

  4. 評論列表的業務數據模型也包含部分個性化信息。

因此，我們利用**《直播場景下 高併發的熱點處理實踐》[5]** 一文所使用的 SDK，在讀取評論區基礎信息階段探測熱點，並將熱點標識傳遞至 BFF 層；BFF 層實現了頁面請求級的熱點本地緩存，感知到熱點後即讀取本地緩存，然後再加載個性化信息。

圖片

熱點探測的實現基於單機的滑動窗口 + LFU，那麼如何定義、計算相應的熱點條件閾值呢？

首先，我們進行系統容量設計，列出容量計算的數學公式，主要包括各接口 QPS 的關係、服務集羣總 QPS 與節點數的關係、接口 QPS 與 CPU / 網絡吞吐的關係等；然後，收集系統內部以及相應依賴方的一些的熱點相關統計信息，通過前面列出的公式，計算出探測數據項的單機 QPS 熱點閾值。最後通過熱點壓測，來驗證相應的熱點配置與代碼實現是符合預期的。

** 5.2 冗餘與降級**

上文提到，評論基礎服務層集成了多級緩存，在上一級緩存未命中或者出現網絡錯誤後，可以視具體場景要求降級至下一級緩存。各級緩存可能有功能上的略微差異，但都能保障用戶的基礎體驗。

此外，評論系統是一個同城讀雙活的架構。數據庫與緩存均是雙機房獨立部署的，均支持多副本，具備水平擴容的彈性。針對雙機房架構下特有的副機房數據延遲故障，支持入口層切流 / 跨機房重試 / 應用層補償，儘可能保證極端情況下用戶無感。

在功能層面，我們做了重要級別劃分，把相應的依賴劃分爲強依賴（如審覈）、弱依賴（如粉絲勳章）。對於弱依賴，我們一方面在異常情況下堅決限流熔斷，另一方面也通過超時控制、請求預過濾、優化調用編排甚至技術方案重構等方式持續優化提升非核心功能的可用性，爲業務在評論區獲得更好的曝光展現。

06 安全性設計

評論系統的安全性設計可以分爲「數據安全」與「輿論安全」。

** 6.1 數據安全**

除了數據安全法所要求的以外，評論系統的數據安全還包括「合規性要求」。評論數據合規，一方面是審覈和風控，另一方面對工程側的要求主要是「狀態一致性」。例如，有害評論被刪除後，在客戶端不能展現，也不能通過 API 等對外暴露。這就對數據一致性，包括緩存，提出了較高要求。在設計層面主要有兩方面實踐：

  1. 數據讀寫階段均考慮了一致性風險，嚴格保證時序性。

  2. 對各類數據寫操作，定義了優先級，避免高優先級操作被低優先級操作覆蓋，例如審覈刪除的有害評論，不能被其他普通運營人員 / 自動化策略放出。

  3. 通過冗餘校驗，避免風險數據外泄。例如評論列表的露出，讀取 sorted set 中的 id 列表後，還需要校驗對應評論的狀態，是可見態才允許下發。

** 6.2 輿論安全**

輿論安全問題更爲泛化。接口錯誤導致用戶操作失敗、關閉評論區、評論計數不準，甚至新功能上線、用戶不滿意的評論被頂到熱評前排等問題均可能引發輿情問題。

在系統設計層面，我們主要通過幾方面規避。

  1. **不對用戶暴露用戶無法處理和不值得處理的錯誤。**例如評論點贊點踩、某個數據項讀取失敗這一類的輕量級操作，不值得用戶重試，此時告知用戶操作失敗也沒有意義。系統可以考慮自行重試，甚至直接忽略。

  2. 優化產品功能及其技術實現，例如評論計數、熱評排序等。

這裏重點介紹一下評論計數的優化思路。

**計數不一致的根源，是數據冗餘造成的。**一般出於性能考慮，會在評論列表以外，給這個列表記錄一個長度。也就是用 SELECT count FROM subject，代替 SELECT count(*) FROM reply_index。基於這種冗餘設計，count 字段大部分都是增量更新，即 + 1、-1，是容易出現誤差累積的。

評論計數不準的原因主要有幾方面：

  1. 併發事務導致的「寫傾斜（write skew）」，例如依據評論的狀態來做評論區的計數更新。在 A 事務中讀取的評論狀態，可能在 B 事務中被修改，此時 A 事務計數更新的前提被破壞，也就造成了錯誤的增量更新。此時計數可能偏大或偏小。

  2. 運行時異常、髒數據或者非常規的展示側控制，導致部分數據被過濾。此時計數可能偏大。

  3. 計數冗餘同步至其他系統，例如視頻表的評論數，延遲導致了過程不一致，同步失敗則直接導致最終不一致。

對應併發事務的解決方案，主要有兩種：

  1. 事務加鎖。綜合評估而言，對性能的影響較大，特別是存在 " 鎖放大 “，越需要加鎖的場景，越容易出現” 鎖衝突“。

  2. 串行化。將評論區的所有操作，抽象爲一個排隊的 Domain Events，串行處理，不容易出錯。那爲什麼不能按照評論維度進行拆分，更加不容易出現評論區維度的熱點？因爲上文提到，刪除一級評論時，實際也會從計數上刪除其回覆；刪除二級評論時，也會更新其根評論的計數。多個評論的操作相互影響，因此按照評論維度進行拆分仍然存在併發事務問題。

07 熱評設計

** 7.1 什麼是熱評**

早期的熱評，實際就是按照評論點贊數降序。後來衍生了更爲複雜的熱評：既包括類似「妙評」這種用戶推薦、運營精選且帶 logo 突出展示的產品形態，也包括各類熱評排序算法，且熱評排序算法應用場景也不僅侷限於評論主列表的熱度序，還包括樓中樓（外露子評論）、動態外露評論等。

熱評排序邏輯一般包括點贊數、回覆數、內容相關、負反饋數、“時間衰退因子”、字數加權、用戶等級加權等等。**如何在 B 站評論區脫穎而出？[7]** 一文從內容運營層面，介紹了什麼樣的評論更容易上熱評前排。

咬文嚼字來說，我們對「熱」的理解，大致分爲幾個階段：

  1. 點贊高，就代表熱度高。→ 解決熱評的有無問題

  2. 基於用戶正負樣本投票的，加權平均高，就代表熱度高。→ 解決高贊高踩的負面熱評問題

  3. 短時間內點贊率高，就代表熱度高。→ 解決高贊永遠高讚的馬太效應

  4. 熱評用戶流量大，社區影響也大。要權衡社會價值觀引導、公司戰略導向、商業利益、UP 主與用戶的「情緒」等。→ 追求用戶價值平衡

** 7.2 挑戰與應對**

顯然，我們在不同階段對熱評的理解，在系統設計上也提出了不同層面的要求：

  1. 按照點贊絕對值排序，即要實現 ORDER BY like_count 的分頁排序。點贊數是一個頻繁更新的值，MySQL，特別是 TiDB，由於掃描行數約等於 OFFSET，因此在 OFFSET 較大時查詢性能特別差，很難找到一個完美的優化方案。此外，由於 like_count 的分佈可能出現同一個值堆疊多個元素，比如評論區所有的評論都沒有贊，我們更多依賴 redis 的 sorted set 來執行分頁查詢，這就要求緩存命中率要非常高。

  2. 按照正負樣本加權平均的，即 Reddit：威爾遜排序 [6]，到這個階段，數據庫已經無法實現這樣複雜的 ORDER BY，熱評開始幾乎完全依賴 sorted set 這樣的數據結構，預先計算好排序分數並寫入。於是在架構設計上，新增了 feed-service 和 feed-job 來支撐熱評列表的讀寫。

圖片

  1. 按照點贊率排序，需要實現點贊率的近實時計算。點贊率 = 點贊數 / 曝光數，曝光的數據來源是客戶端上報的展現日誌，量級非常大，可以說是一個寫多讀少的場景：只有重算排序的時候纔會讀取曝光數。

  2. 追求用戶價值平衡，需要處理各種細分場景下的差異化需求。熱評排序與 feed 排序很像，但也有一點根本性差異：feed 排序我們往往都希望是個性化的，每個人看到的都不相同，但評論往往不會如此激進，一般來說會希望大家看到的評論排序都大致相同。由於排序問題的解決方案是探索型的，因此係統設計層面需要提供更多元、更易擴展的工程化能力，包括算法和策略的快速迭代、實驗能力等，並提升整個熱評模塊的可觀測水平，監控完善、數據報表豐富、排序過程可解釋等等。在架構上，新增了 strategy-service 和 strategy-job 來承擔這部分策略探索型業務。

此外，數據量級規模的增加，也對系統的吞吐能力提出了更高要求：不管熱評的算法如何變化，一般來說，熱評列表都需要能夠訪問到全部評論，且基本維持相同的熱評排序邏輯。在評論數過百萬甚至千萬的評論區，熱評排序的挑戰點主要在於：

  1. 大 key 問題：例如單個 sorted set 過大，讀寫性能都受影響（時間複雜度的基數可以認爲都是 O(logN)）；全量更新時，還可能遇到 redis pipeline 的瓶頸。

  2. 實時性放大存儲壓力：多樣化的數據源，對特徵的導入與更新都提出了挑戰，需要支持較豐富的數據結構，和儘可能高的寫吞吐（想象一下曝光數作爲排序特徵的變態要求）；與推薦排序不同，熱評排序是全排序，此時需要讀取全部評論的全部特徵，查詢壓力也會非常大。

這一階段，我們仍然在持續優化，在工程落地層面儘可能還原理想的排序算法設計，保障用戶的熱評瀏覽體驗。目前形成的系統架構總體如下圖所示：

圖片

圖示的「評論策略層」，負責建立一套熱評調控體系化能力，通過召回機制來實現想要的 “balance“。即先通過策略工程，召回一批應該沉底的不良評論或者應該進前排的優秀評論，然後在排序分計算階段根據召回結果實現這樣的效果。

這樣做的好處是，可以保留一套通用的底層排序算法，然後通過迭代細分場景下的召回策略，來實現差異化評論排序的平衡。

召回策略的工程設計，按照分層設計的原則拆分爲 3 個部分：

  1. 因子機。主要職責是維護策略所需的全部「因子」，包括一些已有的在線 / 離線數據，也包括爲了策略迭代而需要新開發的流式的窗口聚合數據。因子機的重難點是需要管理各種數據獲取的拓撲關係，以及通過緩存來保護下游（數據提供方很難也不應該承受熱評業務的巨大流量）。所有的因子可以構成一個有向無環圖，通過梳理依賴關係和推導計算，實現併發提效、減少冗餘。

  2. 規則機。實現了一套聲明式規則語法，可以直接引用因子機預定義的因子，結合各種邏輯算子構成一個規則表達式。規則機執行命中後，會向下遊傳遞預先聲明的召回決策，例如排序提權。

  3. 召回處理中心。這一層的職責就是接收規則機返回的各種決策並執行，需要處理不同決策的優先級 PK、不同規則的決策疊加作用、決策豁免等。

熱評排序涉及的特徵，是多數據源的，數據更新方式、更新頻率、查詢性能也天差萬別。因此我們針對數據源的特點做了多級緩存，通過多級冗餘與跨級合併，提升了特徵讀取的穩定性與性能上限。當然，其中的數據實時性、一致性、可用性，仍然處於一個動態權衡取捨的過程。舉個例子，曝光數使用 redis 計數器維護，受限於成本並未持久化；各類靜態模型分存在 4 到 5 層冗餘。此外，還應用了內部稀疏數據的 bloom-filter 查詢、數據局部性集中與散列相結合、近實時大窗口聚合計數等多種性能優化手段。需要指出的是，召回和排序兩階段都需要查詢因子 / 特徵，得以複用「因子機」，完成各個特徵的差異化實現與維護。

熱評排序最關鍵的計算模塊，首先是引入了自適應的冷卻算法，根據評論區的評論數、活躍程度等，對重算排序的收益進行預估，攔截了大部分低價值重排請求。其次在全量打分排序階段，「排序策略」貫穿上下文，既支持傳統的靜態的經驗算分公式，也支持動態的模型打分，支撐 AI 模型的快速部署快速迭代。通過組合與繼承，支持排序策略的疊加、微調，結合評論網關層的排序策略路由，可實現各類定製化排序，完成熱評排序系統的平臺化。

除了大家點開評論區看到的 “熱評”，在樓中樓、動態外露評論、評論詳情頁等類似場景，我們同樣應用了這套熱評系統，在工程上實現了架構的統一。

** 7.3 願景與規劃**

評論區作爲 B 站社區的重要組成部分，致力於爲中文互聯網提供一個和諧、有趣的交流環境。另一方面，B 站評論區流量巨大，所具備的商業化價值也是需要持續探索的。不管是氛圍還是商業，都具有非常強的頭部效應。因此，熱評，尤其是熱評的頭部，我們會持續優化產品功能，持續探索排序策略，期望能爲用戶帶來更好的體驗：用戶可以在這裏看到自己喜歡的評論內容，有知識、有溫度，也可以看到一些多元化的觀點；可以炫一下自己的裝扮，也可以守護新人 UP 主成長；可以傾訴自己的故事，也可以發一條友善的評論，更可以來一個段子，逗樂每一個在互聯網裏衝浪的有緣人。

參考資料：

[1] https://t.bilibili.com/406920470238773354?spm_id_from=333.999.0.0

[2] 維基百科：評論（https://zh.wikipedia.org/wiki/%E8%A9%95%E8%AB%96）

[3] 百度評論中臺的設計與探索（https://juejin.cn/post/7108973163333025805）

[4] 騰訊老乾媽大瓜背後，B 站竟成爲最大贏家（https://36kr.com/p/783469249310599）

[5] 直播場景下 高併發的熱點處理實踐（https://www.bilibili.com/read/cv15278397?from=search&spm_id_from=333.337.0.0）

[6] Evan Miller: How Not To Sort By Average Rating（https://www.evanmiller.org/how-not-to-sort-by-average-rating.html）

[7] 如何在 B 站評論區脫穎而出？

[8] 如何對文章下面的評論做排序 (2019 年版）（https://zhuanlan.zhihu.com/p/57021517）

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

猜你喜歡