一. 背景

視頻業(yè)務(wù)作為B站內(nèi)容生態(tài)的心臟，承載了海量的視頻內(nèi)容和用戶互動(dòng)。它不僅是用戶獲取信息、享受娛樂(lè)的窗口，更是UP主展示創(chuàng)意、分享知識(shí)的舞臺(tái)。在設(shè)計(jì)和實(shí)現(xiàn)視頻系統(tǒng)時(shí)，我們致力于平衡用戶體驗(yàn)、內(nèi)容分發(fā)的效率，同時(shí)確保平臺(tái)的穩(wěn)定性和可擴(kuò)展性。

在這個(gè)過(guò)程中，稿件生產(chǎn)扮演著至關(guān)重要的角色。我們通過(guò)提供強(qiáng)大的視頻上傳、編輯和管理工具，滿足創(chuàng)作者的需求，讓他們能夠輕松地制作和分享內(nèi)容。同時(shí)，我們實(shí)施嚴(yán)格的內(nèi)容審查和版權(quán)管理措施，以保障社區(qū)生態(tài)的健康發(fā)展。我們向創(chuàng)作者提供更好的服務(wù)，向B站內(nèi)容生態(tài)供給更多的內(nèi)容。

二.遇到的問(wèn)題

圖片

• 隨著B(niǎo)站業(yè)務(wù)迅速發(fā)展，平臺(tái)規(guī)模及影響力較大，黑產(chǎn)、菠菜、沖塔用戶、搬運(yùn)號(hào)等問(wèn)題逐步凸顯出來(lái)，嚴(yán)重影響社區(qū)生態(tài)，對(duì)平臺(tái)管控能力提出了挑戰(zhàn)。
• 在審核&機(jī)審團(tuán)隊(duì)不斷迭代審核能力的同時(shí)，我們發(fā)現(xiàn)由于稿件生產(chǎn)過(guò)程中，多個(gè)環(huán)節(jié)間存在并發(fā)場(chǎng)景，引發(fā)"條件競(jìng)爭(zhēng)"問(wèn)題，導(dǎo)致漏審風(fēng)險(xiǎn)。

三.軟件開(kāi)發(fā)中的并發(fā)問(wèn)題

條件競(jìng)爭(zhēng) (Race Condition) 是指一個(gè)系統(tǒng)的運(yùn)行結(jié)果依賴于不受控制的事件的先后順序。當(dāng)這些不受控制的事件并沒(méi)有按照開(kāi)發(fā)者想要的方式運(yùn)行時(shí)，就可能會(huì)出現(xiàn) bug。這個(gè)詞最早被應(yīng)用在電子系統(tǒng)中。

圖片

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

觀察上面的例子，我們發(fā)現(xiàn)不確定的耗時(shí)、和引入了盤子共同導(dǎo)致了出品的不確定性，兩個(gè)人都可以控制盤子、同時(shí)有人改變了盤子的狀態(tài)（裝入了菜品）。在計(jì)算機(jī)領(lǐng)域中，我們?cè)谛〕叨认碌暮臅r(shí)一定是不確定的，那么引入競(jìng)爭(zhēng)的條件則是以下三點(diǎn)：1. 存在并發(fā) 2. 存在共享對(duì)象 3. 會(huì)變更共享對(duì)象的狀態(tài)。

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

常規(guī)的方案通常是通過(guò)引入同步原語(yǔ)來(lái)規(guī)避，包括互斥鎖、原子操作、串行化等方案。

四. 稿件場(chǎng)景下的安全性演講

在審核場(chǎng)景中，我們遇到的是用戶編輯和審核通過(guò)并發(fā)引起的條件競(jìng)爭(zhēng) (Race Condition) ，將問(wèn)題簡(jiǎn)化一下，可以看作是下圖場(chǎng)景。

圖片

前人通過(guò)提交前重新查詢數(shù)據(jù)，比對(duì)mtime，判斷數(shù)據(jù)發(fā)生變動(dòng)時(shí)刷新頁(yè)面，大幅降低了出現(xiàn)概率，這個(gè)方案可能是早期在改造成本和業(yè)務(wù)安全需求之間做出的妥協(xié)選擇，但在今天已經(jīng)無(wú)法滿足平臺(tái)對(duì)內(nèi)容的安全性需求了。我們需要徹底消除因技術(shù)原因?qū)е碌穆徢闆r，這要求我們系統(tǒng)性地解決稿件生產(chǎn)過(guò)程中的所有條件競(jìng)爭(zhēng)問(wèn)題，確保內(nèi)容審核的嚴(yán)密性和可靠性。

稿件生產(chǎn)流程經(jīng)歷了多次改造，但鑒于業(yè)務(wù)本身的高復(fù)雜性，簡(jiǎn)化后仍包含幾十個(gè)子流程，橫跨多個(gè)業(yè)務(wù)域，難以通過(guò)分析代碼、觀察日志的常規(guī)手段發(fā)現(xiàn)條件競(jìng)爭(zhēng)問(wèn)題。需要建設(shè)觀測(cè)手段，輔助對(duì)這類復(fù)雜問(wèn)題的發(fā)現(xiàn)及分析。

基于之前構(gòu)建的《內(nèi)容生產(chǎn)全鏈路業(yè)務(wù)觀測(cè)體系》，進(jìn)一步建設(shè)內(nèi)容安全對(duì)賬，通過(guò)對(duì)稿件生命周期分析，針對(duì)性監(jiān)控漏審數(shù)據(jù)，并通過(guò)旁路手段快速止損；同時(shí)回?fù)茪v史漏審數(shù)據(jù)進(jìn)行分析，將問(wèn)題進(jìn)行歸納分類，整體構(gòu)思解決方案。

一般情況下，可以選擇互斥鎖、樂(lè)觀鎖、串行化管道來(lái)解決并發(fā)問(wèn)題，將并發(fā)場(chǎng)景退化成串行場(chǎng)景。但軟件開(kāi)發(fā)沒(méi)有”銀彈“，我們需要根據(jù)改造成本、存儲(chǔ)成本、用戶體驗(yàn)等多方面要素來(lái)選擇解決方案。

通過(guò)分析當(dāng)下的case，稿件生產(chǎn)流程中雖然遍布競(jìng)爭(zhēng)場(chǎng)景，但涉及安全性的可以只關(guān)注兩部分：用戶編輯會(huì)引入風(fēng)險(xiǎn)，稿件開(kāi)放會(huì)漏出風(fēng)險(xiǎn)。由于當(dāng)前所有稿件開(kāi)放動(dòng)作均為審核側(cè)觸發(fā)，我們僅需關(guān)注用戶編輯與審核提交之間競(jìng)爭(zhēng)。

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

圖片

上圖是我們的審核流程，涉及多個(gè)審核場(chǎng)景。在該場(chǎng)景下，用戶編輯與用戶編輯、用戶編輯與審核提交、多場(chǎng)景審核兩兩之間都會(huì)存在條件競(jìng)爭(zhēng)，我們分開(kāi)考慮。

圖片

審核由審核平臺(tái)保障不會(huì)有數(shù)據(jù)同時(shí)被多審核場(chǎng)景提交，所以暫不考慮該場(chǎng)景。

用戶編輯與用戶編輯之間并發(fā)一般是非常規(guī)場(chǎng)景，針對(duì)該場(chǎng)景我們加入了編輯限頻，同時(shí)規(guī)避并發(fā)問(wèn)題和減少黑灰產(chǎn)編輯，一舉兩得。

審核環(huán)節(jié)和用戶提交的競(jìng)爭(zhēng)比較復(fù)雜。在審核環(huán)節(jié)中，從送審讀取稿件數(shù)據(jù)，到審核提交數(shù)據(jù)，常常會(huì)有數(shù)十分鐘的時(shí)間，顯然這段時(shí)間不讓用戶編輯是不合理的。因此我們采用CAS方式降低報(bào)錯(cuò)概率。

稿件編輯、更新?tīng)顟B(tài)的時(shí)候，會(huì)同時(shí)更新數(shù)據(jù)版本字段；在更新時(shí)會(huì)指定更新的版本，如果指定的版本低于當(dāng)前DB中版本，更新失敗。在審核提交因更新的版本低于當(dāng)前版本報(bào)錯(cuò)時(shí)，會(huì)自動(dòng)觸發(fā)重新送審流程，讓審核同學(xué)審一遍最新版本的稿件。

圖片

引入更新CAS和限頻鎖后，我們的旁路觀測(cè)系統(tǒng)從每周漏審x條成功清零。雖然方案不算很優(yōu)雅，但很好的解決了我們當(dāng)下的問(wèn)題。

五.未來(lái)展望

 1.稿件生產(chǎn)流程并發(fā)競(jìng)爭(zhēng)處理

當(dāng)前階段只解決了眼下最緊急的安全性上的并發(fā)競(jìng)爭(zhēng)問(wèn)題，但稿件生產(chǎn)過(guò)程中處處存在競(jìng)爭(zhēng)問(wèn)題，依然會(huì)出現(xiàn)卡流程、更新錯(cuò)誤、計(jì)算異常等問(wèn)題，亟需系統(tǒng)性治理。因此要將整個(gè)生產(chǎn)流程分為實(shí)時(shí)、近實(shí)時(shí)兩部分，實(shí)時(shí)場(chǎng)景做好樂(lè)觀鎖版本控制，近實(shí)時(shí)消息隊(duì)列部分做好串型化，保障整個(gè)稿件生產(chǎn)流程中數(shù)據(jù)產(chǎn)出符合預(yù)期。

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

為了審核提交CAS，本次在稿件引入了版本號(hào)概念，但當(dāng)前版本號(hào)只是一個(gè)數(shù)字沒(méi)有深入挖掘，后續(xù)可以圍繞版本號(hào)做更深一步的處理，建設(shè)版本更新記錄，使審核、技術(shù)人員可以對(duì)自己上一次變更做負(fù)向操作，減少誤操作造成的損失。

同時(shí)在版本提交沖突時(shí)，可以做簡(jiǎn)易的merge操作，比如提交版本和當(dāng)前版本中的變更不存在需要審核的要素，可以直接應(yīng)用審核結(jié)果，減輕審核同學(xué)重審工作量。

 3.稿件域變更字段管控

當(dāng)下稿件系統(tǒng)中更新數(shù)據(jù)濫用嚴(yán)重，很多場(chǎng)景明明沒(méi)有修改某字段，也用上次讀到的對(duì)應(yīng)數(shù)據(jù)進(jìn)行覆蓋寫(xiě)操作，引入了很多數(shù)據(jù)沖突風(fēng)險(xiǎn)。需要建設(shè)變更權(quán)限能力，嚴(yán)格管控各場(chǎng)景對(duì)數(shù)據(jù)的更新范圍。比如標(biāo)簽服務(wù)只能變更標(biāo)簽，不能更改標(biāo)題或狀態(tài)。這樣能細(xì)化共享數(shù)據(jù)粒度，降低數(shù)據(jù)沖突風(fēng)險(xiǎn)，同時(shí)也能減少相關(guān)業(yè)務(wù)方誤操作或跨業(yè)務(wù)域操作的出現(xiàn)。