一. 背景

視頻業務作為B站內容生態的心臟，承載了海量的視頻內容和用戶互動。它不僅是用戶獲取信息、享受娛樂的窗口，更是UP主展示創意、分享知識的舞臺。在設計和實現視頻系統時，我們致力于平衡用戶體驗、內容分發的效率，同時確保平臺的穩定性和可擴展性。

在這個過程中，稿件生產扮演著至關重要的角色。我們通過提供強大的視頻上傳、編輯和管理工具，滿足創作者的需求，讓他們能夠輕松地制作和分享內容。同時，我們實施嚴格的內容審查和版權管理措施，以保障社區生態的健康發展。我們向創作者提供更好的服務，向B站內容生態供給更多的內容。

二.遇到的問題

圖片

• 隨著B站業務迅速發展，平臺規模及影響力較大，黑產、菠菜、沖塔用戶、搬運號等問題逐步凸顯出來，嚴重影響社區生態，對平臺管控能力提出了挑戰。
• 在審核&機審團隊不斷迭代審核能力的同時，我們發現由于稿件生產過程中，多個環節間存在并發場景，引發"條件競爭"問題，導致漏審風險。

三.軟件開發中的并發問題

條件競爭 (Race Condition) 是指一個系統的運行結果依賴于不受控制的事件的先后順序。當這些不受控制的事件并沒有按照開發者想要的方式運行時，就可能會出現 bug。這個詞最早被應用在電子系統中。

圖片

• 在邏輯電路中，模塊可能會因為源信號的不同，或邏輯元件的傳播延遲差距，產生不符合預期的輸出。在計算機領域中，為了提升運行效率、有效利用資源，會采取多線程、多進程、協程、分布式系統等眾多手段來同時執行更多任務，但這些形式都可以歸為并發模型。
• 在執行復雜任務的時候，我們一般會將任務拆分成多個小任務去執行，比如我們想做番茄雞蛋蓋飯時，可以把任務拆分成切番茄、打雞蛋、煮飯、炒番茄雞蛋、裝盤等多個環節；按順序執行的話會花費很多時間，所以在生活中我們總是在煮飯的同時處理其他事情，這就是并發的應用。
• 在軟件中，我們會把任務抽象成執行流，而并發則是描述同時執行多個執行流；那么并發為什么會導致條件競爭呢？讓我們繼續前面的例子，在我們做番茄雞蛋蓋飯的時候，炒番茄雞蛋的用時，和煮飯的用時總會有細微的變化，有時是飯先煮好、有時是番茄雞蛋先炒好；那么如果煮飯的和炒菜的不是同一個人，他們接到的指令都是飯/菜做好后直接裝到盤子里，那么飯先煮好裝盤，最后做好的是番茄雞蛋蓋飯；菜先炒好，菜品就變成了飯蓋番茄雞蛋了。

觀察上面的例子，我們發現不確定的耗時、和引入了盤子共同導致了出品的不確定性，兩個人都可以控制盤子、同時有人改變了盤子的狀態（裝入了菜品）。在計算機領域中，我們在小尺度下的耗時一定是不確定的，那么引入競爭的條件則是以下三點：1. 存在并發 2. 存在共享對象 3. 會變更共享對象的狀態。

根據引入競爭的條件，我們可以很清晰地得出，要消除條件競爭，要么破壞并發條件，要么不使用共享對象。那是不是用了共享對象的，就不能并發了呢？顯然不是，我們只要找到訪問競爭對象的窗口，在競爭窗口（race windows）中保持同步處理，就可以規避掉條件競爭問題。

常規的方案通常是通過引入同步原語來規避，包括互斥鎖、原子操作、串行化等方案。

四. 稿件場景下的安全性演講

在審核場景中，我們遇到的是用戶編輯和審核通過并發引起的條件競爭 (Race Condition) ，將問題簡化一下，可以看作是下圖場景。

圖片

前人通過提交前重新查詢數據，比對mtime，判斷數據發生變動時刷新頁面，大幅降低了出現概率，這個方案可能是早期在改造成本和業務安全需求之間做出的妥協選擇，但在今天已經無法滿足平臺對內容的安全性需求了。我們需要徹底消除因技術原因導致的漏審情況，這要求我們系統性地解決稿件生產過程中的所有條件競爭問題，確保內容審核的嚴密性和可靠性。

稿件生產流程經歷了多次改造，但鑒于業務本身的高復雜性，簡化后仍包含幾十個子流程，橫跨多個業務域，難以通過分析代碼、觀察日志的常規手段發現條件競爭問題。需要建設觀測手段，輔助對這類復雜問題的發現及分析。

基于之前構建的《內容生產全鏈路業務觀測體系》，進一步建設內容安全對賬，通過對稿件生命周期分析，針對性監控漏審數據，并通過旁路手段快速止損；同時回撈歷史漏審數據進行分析，將問題進行歸納分類，整體構思解決方案。

一般情況下，可以選擇互斥鎖、樂觀鎖、串行化管道來解決并發問題，將并發場景退化成串行場景。但軟件開發沒有”銀彈“，我們需要根據改造成本、存儲成本、用戶體驗等多方面要素來選擇解決方案。

通過分析當下的case，稿件生產流程中雖然遍布競爭場景，但涉及安全性的可以只關注兩部分：用戶編輯會引入風險，稿件開放會漏出風險。由于當前所有稿件開放動作均為審核側觸發，我們僅需關注用戶編輯與審核提交之間競爭。

用戶編輯與審核提交均為同步接口觸發，是需要實時反饋是否更新完成的，使用消息隊列做串性化處理顯然會劣化體驗，只能考慮引入鎖破壞競爭條件。為了用戶及審核人員的體驗，鎖的觸發概率和影響時長都要盡可能的小，同時用戶編輯的可用性要求會高于審核人員。

圖片

上圖是我們的審核流程，涉及多個審核場景。在該場景下，用戶編輯與用戶編輯、用戶編輯與審核提交、多場景審核兩兩之間都會存在條件競爭，我們分開考慮。

圖片

審核由審核平臺保障不會有數據同時被多審核場景提交，所以暫不考慮該場景。

用戶編輯與用戶編輯之間并發一般是非常規場景，針對該場景我們加入了編輯限頻，同時規避并發問題和減少黑灰產編輯，一舉兩得。

審核環節和用戶提交的競爭比較復雜。在審核環節中，從送審讀取稿件數據，到審核提交數據，常常會有數十分鐘的時間，顯然這段時間不讓用戶編輯是不合理的。因此我們采用CAS方式降低報錯概率。

稿件編輯、更新狀態的時候，會同時更新數據版本字段；在更新時會指定更新的版本，如果指定的版本低于當前DB中版本，更新失敗。在審核提交因更新的版本低于當前版本報錯時，會自動觸發重新送審流程，讓審核同學審一遍最新版本的稿件。

圖片

引入更新CAS和限頻鎖后，我們的旁路觀測系統從每周漏審x條成功清零。雖然方案不算很優雅，但很好的解決了我們當下的問題。

五.未來展望

 1.稿件生產流程并發競爭處理

當前階段只解決了眼下最緊急的安全性上的并發競爭問題，但稿件生產過程中處處存在競爭問題，依然會出現卡流程、更新錯誤、計算異常等問題，亟需系統性治理。因此要將整個生產流程分為實時、近實時兩部分，實時場景做好樂觀鎖版本控制，近實時消息隊列部分做好串型化，保障整個稿件生產流程中數據產出符合預期。

 2.稿件版本追溯&版本合并

為了審核提交CAS，本次在稿件引入了版本號概念，但當前版本號只是一個數字沒有深入挖掘，后續可以圍繞版本號做更深一步的處理，建設版本更新記錄，使審核、技術人員可以對自己上一次變更做負向操作，減少誤操作造成的損失。

同時在版本提交沖突時，可以做簡易的merge操作，比如提交版本和當前版本中的變更不存在需要審核的要素，可以直接應用審核結果，減輕審核同學重審工作量。

 3.稿件域變更字段管控

當下稿件系統中更新數據濫用嚴重，很多場景明明沒有修改某字段，也用上次讀到的對應數據進行覆蓋寫操作，引入了很多數據沖突風險。需要建設變更權限能力，嚴格管控各場景對數據的更新范圍。比如標簽服務只能變更標簽，不能更改標題或狀態。這樣能細化共享數據粒度，降低數據沖突風險，同時也能減少相關業務方誤操作或跨業務域操作的出現。