稿件消费业务并发竞争场景下的安保性保证

一. 背景

视频业务作为B站内容生态的心脏，承载了海量的视频内容和用户互动。它不只是用户失掉信息、享用文娱的窗口，更是UP主展现创意、分享常识的舞台。在设计和成功视频系统时，咱们努力于平衡用户体验、内容散发的效率，同时确保平台的稳固性和可裁减性。

在这个环节中，稿件消费表演着至关关键的角色。咱们经过提供弱小的视频上行、编辑和控制工具，满足创作者的需求，让他们能够轻松地制造和分享内容。同时，咱们实施严厉的内容审查和版权控制措施，以保证社区生态的肥壮开展。咱们向创作者提供更好的服务，向B站内容生态供应更多的内容。

二.遇到的疑问

三.软件开发中的并发疑问

条件竞争 (Race Condition) 是指一个系统的运转结果依赖于不受控制的事情的先后顺序。当这些不受控制的事情并没有依照开发者想要的方式运转时，就或许会出现 bug。这个词最早被运行在电子系统中。

观察下面的例子，咱们发现不确定的耗时、和引入了盘子独特造成了出品的不确定性，两团体都可以控制盘子、同时有人扭转了盘子的形态（装入了菜品）。在计算机畛域中，咱们在小尺度下的耗时肯定是不确定的，那么引入竞争的条件则是以下三点：1. 存在并发 2. 存在共享对象 3. 会变卦共享对象的形态。

依据引入竞争的条件，咱们可以很明晰地得出，要消弭条件竞争，要么破坏并发条件，要么不经常使用共享对象。那是不是用了共享对象的，就不能并发了呢？显然不是，咱们只需找到访问竞争对象的窗口，在竞争窗口（race windows）中坚持同步处置，就可以规避掉条件竞争疑问。

惯例的打算通常是经过引入同步原语来规避，包括互斥锁、原子操作、串行化等打算。

四. 稿件场景下的安保性演讲

在检查场景中，咱们遇到的是用户编辑和检查经过并发惹起的条件竞争 (Race Condition) ，将疑问简化一下，可以看作是下图场景。

先人经过提交前从新查问数据，比对mtime，判别数据出现变化时刷新页面，大幅降落了出现概率，这个打算或许是早期在改形老本和业务安保需求之间做出的斗争选用，但在当天曾经不可满足平台对内容的安保性需求了。咱们须要彻底消弭因技术要素造成的漏审状况，这要求咱们系统性地处置稿件消费环节中的一切条件竞争疑问，确保内容检查的严密性和牢靠性。

稿件消费流程教训了屡次变革，但鉴于业务自身的高复杂性，简化后仍蕴含几十个子流程，横跨多个业务域，难以经过剖析代码、观察日志的惯例手腕发现条件竞争疑问。须要树立观测手腕，辅佐对这类复杂疑问的发现及剖析。

基于之前构建的《内容消费全链路业务观测体系》，进一步树立内容安保对账，经过对稿件生命周期剖析，针对性监控漏审数据，并经过旁路手腕极速止损；同时回捞历史漏审数据启动剖析，将疑问启动演绎分类，全体构思处置打算。

普通状况下，可以选用互斥锁、失望锁、串行化管道来处置并发疑问，将并发场景退步成串行场景。但软件开发没有”银弹“，咱们须要依据改形老本、存储老本、用户体验等多方面要历来选用处置打算。

经过剖析当下的case，稿件消费流程中虽然普及竞争场景，但触及安保性的可以只关注两局部：用户编辑会引入危险，稿件放开会漏出危险。由于一切稿件放开举措均为检查侧触发，咱们仅需关注用户编辑与检查提交之间竞争。

用户编辑与检查提交均为同步接口触发，是须要实时反应能否降级成功的，经常使用信息队列做串性化处置显然会劣化体验，只能思考引入锁破坏竞争条件。为了用户及检查人员的体验，锁的触发概率和影响时长都要尽或许的小，同时用户编辑的可用性要求会高于检查人员。

上图是咱们的检查流程，触及多个检查场景。在该场景下，用户编辑与用户编辑、用户编辑与检查提交、多场景检查两两之间都会存在条件竞争，咱们分开思考。

检查由检查平台保证不会有数据同时被多检查场景提交，所以暂不思考该场景。

用户编辑与用户编辑之间并发普通是非惯例场景，针对该场景咱们添加了编辑限频，同时规避并发疑问和缩小黑灰产编辑，一箭双雕。

检查环节和用户提交的竞争比拟复杂。在检查环节中，从送审读取稿件数据，到检查提交数据，经常会有数十分钟的期间，显然这段期间不让用户编辑是不正当的。因此咱们驳回CAS方式降落报错概率。

稿件编辑、降级形态的时刻，会同时降级数据版本字段；在降级时会指定降级的版本，假设指定的版本低于DB中版本，降级失败。在检查提交因降级的版本低于版本报错时，会智能触发从新送审流程，让检查同窗审一遍最新版本的稿件。

引入降级CAS和限频锁后，咱们的旁路观测系统从每周漏审x条成功清零。虽然打算不算很优雅，但很好的处置了咱们当下的疑问。

五.未来展望

1.稿件消费流程并发竞争处置

阶段只处置了眼下最紧急的安保性上的并发竞争疑问，但稿件消费环节中处处存在竞争疑问，依然会出现卡流程、降级失误、计算意外等疑问，亟需系统性控制。因此要将整个消费流程分为实时、近实时两局部，实时场景做好失望锁版本控制，近实时信息队列局部做好串型化，保证整个稿件消费流程中数据产出合乎预期。

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

为了检查提交CAS，本次在稿件引入了版本号概念，但版本号只是一个数字没有深化开掘，后续可以围绕版本号做更深一步的处置，树立版本降级记载，使检查、技术人员可以对自己上一次性变卦做负向操作，缩小误操作形成的损失。

同时在版本提交抵触时，可以做繁难的merge操作，比如提交版本和版本中的变卦不存在须要检查的要素，可以间接运行检查结果，减轻检查同窗重审上班量。

3.稿件域变卦字段管控

当下稿件系统中降级数据滥用重大，很多场景明明没有修正某字段，也用上次读到的对应数据启动笼罩写操作，引入了很少数据抵触危险。须要树立变卦权限才干，严厉管控各场景对数据的降级范围。比如标签服务只能变卦标签，不能更改题目或形态。这样能细化共享数据粒度，降落数据抵触危险，同时也能缩小相关业务方误操作或跨业务域操作的出现。