B站評論系統架構設計

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

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

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

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

1. 釋出評論：支援無限蓋樓回覆。

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

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

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

5. 管理評論：置頂、精選、後臺運營管理（搜尋、刪除、稽核等）。

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

1. 評論富文字展示：例如表情、@、分享連結、廣告等。

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

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

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

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

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

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

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

對評論業務來說，業務資料模型是最為複雜的。B站評論系統歷史悠久，承載的功能模組相當之多，其中最核心的是釋出類介面以及列表類介面，一寫一讀，資料欄位多、依賴服務多、呼叫關係複雜，特別是一些依賴的變更，容易造成整個系統的腐化。

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

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

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

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

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

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

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

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

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

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

2. 與reply-interface協同，為一些長耗時/高吞吐的呼叫做非同步化/削峰處理。

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

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

結合評論的產品功能要求，評論需要至少兩張表：首先是評論表，主鍵是評論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，從而具備了水平擴容能力。

我們基於資料庫設計進行快取設計，選用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進行控制，防止快取擊穿。

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

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

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

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

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

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

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

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

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

4. 評論列表的業務資料模型也包含部分個性化資訊。

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

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

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

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

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

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

評論系統的安全性設計可以分為「資料安全」與「輿論安全」。

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

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

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

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

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

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

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，序列處理，不容易出錯。那為什麼不能按照評論維度進行拆分，更加不容易出現評論區維度的熱點？因為上文提到，刪除一級評論時，實際也會從計數上刪除其回覆；刪除二級評論時，也會更新其根評論的計數。多個評論的操作相互影響，因此按照評論維度進行拆分仍然存在併發事務問題。

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

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

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

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

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

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

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

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

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來支撐熱評列表的讀寫。

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

4. 追求使用者價值平衡，需要處理各種細分場景下的差異化需求。熱評排序與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模型的快速部署快速迭代。透過組合與繼承，支援排序策略的疊加、微調，結合評論閘道器層的排序策略路由，可實現各類定製化排序，完成熱評排序系統的平臺化。

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

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

參考資料：

[1]

[2] 維基百科：評論（%E8%A9%95%E8%AB%96）

[3] 百度評論中臺的設計與探索（）

[4] 騰訊老乾媽大瓜背後，B站竟成為最大贏家（）

[5] 直播場景下 高併發的熱點處理實踐（）

[6] Evan Miller: How Not To Sort By Average Rating（）

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

[8] 如何對文章下面的評論做排序(2019年版）（）