CN112738550B - 内容数据的处理方法、装置、电子设备及介质 - Google Patents

Abstract

本申请的实施例提供了一种内容数据的处理方法，包括：接收客户端提交的内容数据，内容数据是在客户端的编辑器上进行内容编辑得到的，客户端按照服务端提供的路径获得编辑器；将内容数据及客户端中编辑器所对应后端代码的第一版本号关联备份于缓存中；进行第一版本号与第二版本号的比较，第二版本号是数据库中所存储后端代码的版本号；若第一版本号不低于第二版本号，则将内容数据写入数据库中；若第一版本号低于第二版本号，则将内容数据与第二版本号的后端代码进行兼容处理。有效实现了内容数据与编辑器的版本的管理，保证了内容数据与编辑器的兼容。

Description

内容数据的处理方法、装置、电子设备及介质

技术领域

本申请涉及计算机及通信技术领域，具体而言，涉及一种内容数据的处理方法、装置、电子设备及介质。

背景技术

用户在观看互动视频的时候，通过与互动视频进行交互，例如进行剧情选择，从而影响所观看互动视频的剧情发展。

互动视频作为一种全新的视频模式，让用户在参与剧情、内容探索等方面待料更丰富的观看体验。

对于互动视频的创作而言，创作者在客户端的编辑器中进行视频创作，期间可能需要多次进行视频编辑修改、调整，而在该过程中，每次编辑修改都会产生不同内容版本的互动视频。所创作得到的互动视频即为一种内容数据。

而对于互动视频开放平台而言，随着应用程序以及服务端中的更新迭代，对应地客户端中的编辑器也对应进行更新，编辑器的更新则对应着编辑器版本的迭代。

如果客户端为网页客户端，则客户端的更新并不会随着发布而立即生效；而且，若服务端是多台机器灰度发布，也不会随着发布立即生效。从而，在此情况下，客户端和服务端可能存在多个版本并存的情况。

而且，由于网页客户端的更新是基于用户在服务端中发布完成后在此访问服务端才会完全生效，因此，不同的创作者在不同时间可能会使用到不同版本的编辑器，而且不同版本的编辑器也可能会产生不同内容版本的互动视频。

由于客户端和服务端可能存在多个版本并存的情况，则可能导致编辑器与互动视频不兼容出现报错，或者向数据库中写入不兼容的互动视频，互动视频无法流畅播放。

综上所述，如何进行内容数据与编辑器的兼容处理是现有技术中亟待解决的技术问题。

发明内容

本申请的实施例提供了一种内容数据的处理方法、装置、电子设备及介质，进而至少在一定程度上可以实现内容数据与编辑器的版本管理，保证内容数据与编辑器的兼容。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

根据本申请实施例的一个方面，提供了一种内容数据的处理方法，应用于服务端，包括：

接收客户端提交的内容数据，所述内容数据是在所述客户端的编辑器上进行内容编辑得到的，所述客户端按照服务端提供的路径获得所述编辑器；

将所述内容数据及所述客户端中编辑器所对应后端代码的第一版本号关联备份于缓存中；

进行所述第一版本号与第二版本号的比较，所述第二版本号是数据库中所存储所述后端代码的版本号；

若所述第一版本号不低于第二版本号，则将所述内容数据写入所述数据库中；

若所述第一版本号低于所述第二版本号，则将所述内容数据与所述第二版本号的后端代码进行兼容处理。

根据本申请实施例的一个方面，提供了一种内容数据的处理装置，应用于服务端，包括：

接收模块，用于接收客户端提交的内容数据，所述内容数据是在所述客户端的编辑器上进行内容编辑得到的，所述客户端按照服务端提供的路径获得所述编辑器；

备份模块，用于将所述内容数据及所述客户端中编辑器所对应后端代码的第一版本号关联备份于缓存中；

比较模块，用于进行所述第一版本号与第二版本号的比较，所述第二版本号是数据库中所存储所述后端代码的版本号；

写入模块，用于若所述第一版本号不低于第二版本号，则将所述内容数据写入所述数据库中；

兼容处理模块，用于若所述第一版本号低于所述第二版本号，则将所述内容数据与所述第二版本号的后端代码进行兼容处理。

根据本申请实施例的一个方面，提供了一种电子设备，应用于服务端包括：

处理器；及

存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现如上所述的方法。

根据本申请实施例的一个方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的方法。

在本申请的一些实施例所提供的技术方案中，将数据兼容问题放在数据写入数据库时进行处理，新版本的编辑器生成的内容数据写入缓存和数据库中，旧版本的编辑器生成的数据仅写入缓存中，有效实现了内容数据与编辑器的版本的管理，保证了内容数据与编辑器的兼容。而且可以实现客户端和服务端中多版本共存。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了本公开实施环境的示意图；

图2是根据一实施例示出的内容数据的处理方法的流程图；

图3是图2对应实施例的步骤210之前步骤在一实施例中的流程图；

图4是图2对应实施例的步骤290在一实施例中的流程图；

图5是图2对应实施例的步骤230在一实施例中的流程图；

图6是根据另一示例性实施例示出的内容数据的处理方法的流程图；

图7是根据一具体实施例示出的互动视频开放平台的架构图；

图8是利用图7的架构进行内容数据处理的时序图；

图9是利用图7中的架构在回滚中进行内容数据处理的时序图；

图10是根据一实施例示出的内容数据的处理装置的框图；

图11示出了适于用来实现本申请实施例的电子设备的计算机***的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

图1是根据本公开所涉及的实施环境的示意图。该实施环境包括：终端110和服务端120。

在终端110与服务端120建立网络连接后，终端110通过运行服务端120所对应的客户端程序，与服务端120进行交互，例如向服务端提交内容数据。终端110中所搭载的客户端程序可以是应用程序客户端，也可以是网页客户端，在此不进行具体限定。

终端110可以是智能手机、平板电脑、笔记本电脑、台式电脑等电子设备。服务端120用于为终端110中的客户端提供服务，可以是服务器或者若干服务器构成的服务器集群。

以下对本申请实施例的技术方案的实现细节进行详细阐述：

图2示出了根据本申请的一个实施例的内容数据的处理方法的流程图，该内容数据的处理方法可以由服务端执行。参照图2所示，该内容数据的处理方法至少包括步骤210至步骤290，详细介绍如下：

步骤210，接收客户端提交的内容数据，内容数据是在客户端的编辑器上进行内容编辑得到的，客户端按照服务端提供的路径获得编辑器。

编辑器中所编辑的内容，可以是视频、文本、图像、音频至少一种内容呈现形式的编辑等，在此不进行具体限定。对应的，则客户端所提交的内容数据可以是携带视频、文本、图像、音频等至少一种内容的数据。

所进行的内容编辑可以是进行内容上传、修改、以及多个内容片段进行组合等编辑方式，在此不进行具体限定。通过在编辑器上进行内容编辑，从而即可将

如上所描述，客户端可以是应用程序客户端或者网页客户端，在此不进行具体限定。

在具体实施例中，该编辑器可以是通过脚本实现，服务端向客户端提供脚本的路径，然后客户端按照服务端所提供的路径获取该脚本，并进行脚本加载，即得到编辑器。

由于客户端按照服务端所提供的路径获得编辑器，从而，使得编辑器所对应的代码与客户端实现解耦，便于进行编辑器的版本管理。

步骤230，将内容数据及客户端中编辑器所对应后端代码的第一版本号关联备份于缓存中。

为保证客户端与服务端之间的交互，服务端中配置了编辑器所对应的后端代码，该后端代码的版本与前端编辑器的版本是一一对应的。从而，在后端进行后端代码的迭代更新后，对应提供新版本的编辑器，并将新版本的编辑器的路径存储于服务端中。

该第一版本号是生成内容数据对应版本编辑器所对应后端代码的版本号，即服务端提供给客户端的路径所对应编辑器所对应后端代码的版本号。

由于客户端中所获得的内容数据是通过服务端中所提供的编辑器得到的，而服务端所提供的编辑器的版本与服务端中后端代码的版本号是一一对应的，从而，在客户端向服务端提交内容数据后，服务端可以根据下发给客户端的路径所对应编辑器的版本号对应得到该第一版本号。

缓存用于备份用户在客户端的编辑器中历史编辑的内容数据。在一实施例中，缓存可以是redis缓存，从而可以通过redis中key命令为该内容数据创建键。而为了进行内容数据与第一版本号的关联存储，在该内容数据所对应key附加该第一版本号。

在缓存中所进行内容数据的存储备份，可以是全量备份、增量备份、差分备份或者该三种备份方式的组合进行，在此不进行具体限定。

全量备份是指对客户端所发送的内容数据进行完全备份，该种备份方式在数据恢复的时间段，但是占用的存储空间大。

增量备份是指每次备份的内容数据指示相当于上一次备份(全量、增量或差量)后增加和修改过的数据。该种备份方式没有重复的备份数据，节省了存储空间，而且缩短了备份时间。

差分备份是指每次备份的数据是相对于上一次全量备份之后新增加的和修改过的数据。差分备份无需每次都做完全备份，因此备份所需时间短，并节省了存储空间。

通过将内容数据与第一版本号关联备份于缓存中，从而服务端可以知晓生成该内容数据的编辑器所对应的版本号，以此保证内容数据与编辑器的兼容。

步骤250，进行第一版本号与第二版本号的比较，第二版本号是数据库中所存储后端代码的版本号。

如上所描述，由于服务端中配置了编辑器所对应后端代码，并对应存储了该后端代码的代码信息，该代码信息例如后端代码的名称，版本号等。从而，该第二版本号可以直接从配置于服务端中的数据库中请求获得。

由于编辑器需要进行版本迭代更新，对应的，编辑器所对应的后端代码也在对应进行迭代更新。而由于用户在编辑器中进行内容编辑需要一定的时间才会向服务端发送内容数据，在客户端按照服务端所提供路径获得编辑器至用户完成内容编辑后，编辑器生成内容数据后这一段时间中，可能服务端已经对后端代码进行迭代更新，从而，通过进行第一版本号与第二版本号的对比，即可获知服务端在该段时间内是否进行了后端代码的迭代更新。

进一步的，通过比较第一版本号与第二版本号的大小可以进一步确定服务端当前所配置的后端代码是向高版本进行迭代，还是向低版本进行回滚。

步骤270，若第一版本号不低于第二版本号，则将内容数据写入数据库中。

如果第一版本号不低于第二版本号，则表明相较于数据库中所存储的后端代码，生成该内容数据的编辑器所对应后端代码为新版本(则说明生成该内容数据的编辑器为新版本)，则可以满足内容数据与生成该内容数据的编辑器的兼容、以及该内容数据与数据库中所存储后端代码对应的编辑器的兼容，从而，可以直接将该内容数据写入数据库中进行存储。

步骤290，若第一版本号低于第二版本号，则将内容数据与第二版本号的后端代码进行兼容处理。

如果第一版本号低于第二版本号，则表明相较于数据库中所存储的后端代码，生成该内容数据的编辑器所对应后端代码为旧版本(则对应的生成该内容数据的编辑器为旧版本)，如果直接写入数据库中，将会导致该内容数据与数据库中所存储后端代码所对应编辑器的不兼容，从而，先将该内容数据与第二版本号的代码进行兼容处理。

所进行的兼容处理可以是新增字段、删除字段、修改字段类型等，在此不进行具体限定。

举例来说，第二版本号的后端代码新增一个字段a，并定义该字段a的类型为字符串，默认值为空，则对该内容数据的兼容处理即是新增字段a，并将该字段a定义为空字符串。

如果第二版本号的后端代码删除一个字段b，则对该内容数据所进行的兼容处理即删除该字段b。

如果第二版本号的后端代码更换了字段c的类型，例如将字段c的类型由int变成string，则对内容数据所进行的兼容处理即将字段c的类型变更为string。

通过如上的过程，将数据兼容问题放在数据写入数据库时进行处理，新版本的编辑器生成的内容数据写入缓存和数据库中，旧版本的编辑器生成的数据仅写入缓存中，有效实现了内容数据与编辑器版本的管理，保证了内容数据与编辑器的兼容。而且可以实现客户端和服务端中多版本共存。

由于客户端按照服务端所下发的路径获取编辑器，并对应在所获取编辑器中进行内容编辑获得内容数据，实现了客户端与编辑器的解耦，便于进行编辑器与服务端的同步迭代更新。

在一实施例中，如图3所示，步骤210之前，该方法还包括：

步骤310，接收客户端发送的路径请求。

客户端为了进行编辑，向服务端请求编辑器的路径。换言之，该路径请求是为了请求获得编辑器而发起的。

在一实施例中，客户端向服务端发起的连接请求即视为客户端所发起的路径请求，从而，服务端在根据客户端发起的连接请求而与客户端成功建立通信连接后，立即向客户端下发自身当前所存储后端代码对应编辑器的路径。

在一实施例中，客户端与服务端采用WebSocket通信，从而，当客户端与服务端WebSocket连接上的时候向服务端下发自身当前所存后端代码所对应编辑器的路径。

步骤330，响应于路径请求，向客户端下发自身当前所配置后端代码所对应编辑器的路径，以使客户端按照所下发的路径获得编辑器。

如上所描述，在服务端中所配置后端代码的版本号与编辑器的版本是一一对应的，从而，服务端通过查询自身当前所配置后端代码的版本号即可对应确定该版本号的后端代码所对应编辑器的版本号，基于此，对应获取该版本号的编辑器所对应代码的存储位置信息。该路径即为编辑器所对应代码的存储位置信息。

在一实施例中，如图4所示，步骤290包括：

步骤410，获取第二版本号的后端代码与第一版本号的后端代码的差异数据。

各个版本号的后端代码定义了不同版本编辑器的属性，例如编辑器中的字段、类型等，从而，若要保证内容数据与编辑器的兼容，则需要按照第二版本号的后端代码来进行兼容处理。

为进行兼容处理，先获取第二版本号的后端代码相较于第一版本号的后端代码的差异数据，该差异数据即反映了相较于第一版本号的后端代码，第二版本号的后端代码所进行的修改。对应的，该差异数据也同时指示了两种版本号的编辑器之间的差异。

步骤430，按照差异数据对内容数据的兼容处理，以使第二版本号的后端代码所对应编辑器兼容内容数据。

通过按照差异数据进行内容数据的兼容处理所进行的兼容处理，从而可以使得该内容数据与第二版本号的后端代码相兼容。

在一实施例中，如图5所示，步骤230，包括：

步骤510，从缓存中获取上一次备份的内容数据。

如上所描述，在进行内容数据备份时，可以是全量备份、增量备份或者差分备份。则所获得的上一次备份的内容数据可以是全量的、增量的、或者差分的。

步骤530，对比所接收到的内容数据和上一次备份的内容数据，获得所接收到内容数据相对于上一次备份的内容数据的增量信息。

步骤550，将增量信息与客户端中编辑器所对应后端代码的第一版本号关联备份于缓存中。

该增量信息用于指示所接收到内容数据相对于上一次备份的内容数据所增加和修改过的数据。

通过对比获得该增量信息即实现了在本次备份中按照增量存储的方式进行所接收到内容数据的备份存储。

通过按照增量存储的方式将内容数据备份存储在缓存中，从而可以降低缓存的存储压力，减少了缓存的数据存储量。

将内容数据备份存储至缓存中，从而，一方面实现了对客户端中历史编辑的内容数据的存储，另一方面，由于仅在内容数据在缓存中备份成功后才将内容数据写入数据，从而缓解了数据库的读写压力。

在一实施例中，步骤290之后，该方法还包括：

将兼容处理后的内容数据写入数据库。

在对内容数据进行兼容处理之后，从而该内容数据即可在第二版本号的后端代码所对应编辑器中的进行呈现，而并不需要在进行内容数据呈现时才进行兼容处理，从而，从源头上解决了版本的迭代更新问题。

在一实施例中，该方法还包括：

按照预设的周期对缓存中的内容数据进行持久化处理。

如上所描述，由于客户端端中所发送的全部内容数据均需要在缓存中进行备份存储，从而，对于缓存而言，存储量大，存储压力大。

而考虑到在进行数据回退或者回滚时，并不会回退到较老版本的内容数据，因此按照预设的周期对缓存中的内容数据进行持久化处理，该预设的周期可以根据实际需要进行设定，例如每24小时，每48小时等。

通过对缓存中的内容数据进行持久化处理，从而可以释放缓存中的存储空间，降低缓存的存储压力。

在一实施例中，如图6所示，该方法还包括：

步骤610，接收客户端为已提交的内容数据发送的修改请求。

步骤630，从缓存中获取修改请求所指示的内容数据。

步骤650，将所获取的内容数据返回至客户端。

用户在客户端的编辑器中进行内容编辑的过程中，可能需要反复进行内容修改，从而使得出现多个内容版本的内容数据。而在客户端向服务端发送内容数据之后，甚至服务端将数据库中所存储的内容数据发布之后，还可能需要对该内容数据进行修改编辑，从而，客户端可以通过向服务端发送修改请求，而从缓存中进行数据提取，并不是从数据库中进行数据提取，从而避免在修改编辑过程中多次进行数据库访问，降低数据库的读写锁压力。

下面结合一具体实施例来对本公开的方法进行进一步说明：

互动视频作为一种全新的视频模式，受到越来越多用户的喜爱。用户在观看互动视频的过程中，可以与互动视频进行交互，例如进行剧情选择，从而来影响视频中剧情的发展。

对于互动视频的生成至在用户终端进行呈现，其中涉及四方，即创作互动视频的互动视频开放平台(又称B端)、互动视频开放平台后台(又称B端后台)、互动视频呈现客户端(又称C端)和互动视频呈现客户端后台(又称C端后台)。

其中互动视频开放平台是提供给创作者在线编辑互动视频的开放平台，即对应于本公开方法中的客户端。

互动视频开放平台后台，用于为互动视频开放平台提供服务，对创作者在B端编辑的互动视频进行管理和存储。

互动视频呈现客户端，用于用户观看创作者所创作的互动视频。

互动视频呈现客户端后台，用于为互动视频呈现客户端提供服务，其数据来源是创作者在B端编辑的互动视频所对应的配置数据。

在本实施例中，B端是基于Web(JS/CSS)前端+Node.JS后端+REDIS缓存/备份+MYSQL数据库的全栈项目。

由于B端在不断地更新迭代，则必然经历代码变更和发布。B端运行在浏览器客户端，用户刷新浏览器(更新代码)的时间不固定，所以B端的代码不会随着发布而立即生效。B端后台是多台机器灰度发布，也不会随着发布立即生效。也就是说，生产环境中，B端/B端后台都可能存在多个版本并存的情况，即众多B端所存在编辑器的版本可能不同，B端后台的每一机器中所配置编辑器所对应后端代码也可能不同。

对于B端而言，所进行的变更和发布仅在B端后台发布完成后，再次访问B端，该变更和发布才会完全生效。因此，不同创作者在不同时间可能会使用到不同版本的“编辑器”。

互动视频是创作者在B端上进行内容编辑所得到的，由于互动视频的特殊性，其背后有一个完整的剧情脉络配置数据，这份配置数据可能是创作者在B端上，经过一段时间、多次编辑和调整，设计出来的。对于这份配置数据，每次编辑修改都会产生不同版本，就是不同的“内容版本”。

而创作者在不同版本的“编辑器”上编辑也可能会产生不同的“内容版本”。

因此，如果“内容版本”和“编辑器版本”前后的兼容问题没有处理好，可可能导致某一段出现异常(例如某一正常功能无法使用)或者向数据库写入不兼容的数据(那么对应的在C端则无法正常播放该互动视频)。

从而，采用本公开的方法来解决互动平台中“内容版本”与“编辑器版本”之间的兼容问题，从而，来对互动平台中版本迭代进行准确和精细管理。

图7示出了本实施例中互动视频开放平台及后台的架构图。如图7所示，前端即为互动视频开放平台(B端)，同时又是上述方法中的客户端，Node服务层、redis缓存以及数据库即作为互动视频开放平台后台(B端后台)，作为本公开上述方法中的服务端。

在前端，不同创作者可能使用不同版本的编辑器进行视频创作，而不同版本的编辑器表现为浏览器上执行的不同JS/CSS，其中CSS(Cascading Style Sheets，层叠CSS文件)是指定义页面中各元素显示样式和布局的文件，而JS即JavaScirpt，是一种基于对象和事件驱动的客户端脚本语言，JS/CSS即指按照JavaScirpt语言所编写的CSS文件。客户端在浏览器上所执行的JS/CSS即表现为客户端的编辑器。

Node服务层与前端进行交互，由于B端后台是多地多机部署，不同机器容器上所运行的服务版本可能不一样，对应的就是不同的服务器版本，即Server Version。对应的，不同的服务器版本则对应为编辑器所配置的后端代码的版本不同。在Node服务层实现统一的版本管理逻辑。由于每一机器可能同时连接多个客户端，从而，在该层还对应进行与客户端所建立WebSocket连接的管理，即socket连接池管理。

Redis缓存，用于实现不同内容版本的互动视频的存储备份，来管理和持久化不同内容版本的互动视频。当然，其中所实现的管理包括在创作者对同一互动视频所进行多次编辑修改的编辑版本管理、以及多机版本管理、持久化数据管理。

数据库用于存储最终唯一的一份内容版本。其中所进行的包括互动视频的兼容处理、事务处理及回滚、读写锁的并发服务控制。

图8示出了基于图7的架构图按照本公开的方法度互动视频进行处理的流程图。

如图8所示，Web前端通过步骤1)请求JS/CSS路径，来向Node后端发起路径请求。

Node后端响应于Web前端所进行的JS/CSS路径请求，通过步骤2)向Web前端返回当前Node后端所配置版本号为V1的后端代码所对应JS/CSS的路径。其中，所下发路径指示的JS/CSS所对应后端代码的版本即为后端代码的第一版本号。

Web前端获得JS/CSS路径的路径后，按照该路径获取JS/CSS文件。并执行步骤3)载入脚本，即获得Web前端用于进行互动创作的编辑器。

进一步的，Web前端在获取到JS/CSS文件后，在JS/CSS文件的文件名上加上文件的HASH后缀，从而保证多个版本的前端代码可以独立共存。

Web前端与Node后端采用WebSocket通信，JS/CSS的文件路径由Node后端下发(WebSocket连接上的时候下发)，这样每个版本的后端都可以控制客户端使用对应的前端代码。

用户通过在Web前端的编辑器中实现步骤4)创作者编辑数据，即对应得到所创作的数据data(即创作的互动视频数据)，并通过步骤5)自动提交数据data到Node后端。

完成步骤5)后，Node后端对应获得所提交的数据data。Node后端执行步骤6)将数据data以及后端代码的版本号V1关联备份于redis缓存中，在备份成功后，由redis缓存通过步骤7)向Node后端返回备份成功的通知消息。通过在redis的key后面添加后端代码的版本号v1，从而可以保证不同版本的编辑器(该编辑器对应相应版本的后端代码)生产的数据不会相互覆盖。

Node后端接收到备份成功的通知消息后，通过步骤8)获取db(data base，数据库)中所存储后端代码的版本号ver。通过步骤8)所获取后端代码的版本号即为当前Node后端中所配置后端代码的版本号，也即本公开方法中的第二版本号。

然后，进行后端代码的版本号V1与版本号ver的比较，如果比较确定ver≤v1，则执行步骤11)将数据data写入db；反之，如果比较确定ver＞v1，则执行步骤13)对该数据data做兼容处理后再写入db中。

对于步骤13)中的兼容处理，需要根据实际情况，在数据结构变更时，B端后台的逻辑处理必须兼容旧版本的后端代码。

通过如上的过程，将不同版本的代码解耦，开发者不需要在处理线上多个版本并存时代码不兼容的问题，节省了工作量。同时，用户的数据不会因为版本的更新(后端代码以及编辑器的更新)出现异常的情况，也不会因为线上多个版本的存在导致数据被多个版本覆盖。而且，即使数据出现异常，也可以通过redis缓存中所备份的数据进行恢复。

本实施例的方法还可以用于解决开放平台中Web应用在灰度上线过程中遇到的数据不一致的问题，可以实现前端和后端多版本共存。

至此，通过本实施例的方法实现了视频开放平台中对版本迭代到的准确和进行管理，提升了互动视频开放平台的可用性和健壮性，扩展了多版本共存的能力。

在实际处理中，如果B端后台发布的后端代码出错，则会出现写入一个错误的高版本内容数据到数据库db的情况。为了解决该问题，在该互动视频开放平台中引入回滚机制。回滚流程的时序图如图9所示。

如图9所示，在发现Node后端(B端后台)发布的后端代码出现错误时，进行后端代码的回滚。假设所发布出现错误的后端代码的版本号为v2，则通过进行回滚，将后端代码重新回滚低版本号(假设回滚至v1版本号)的后端代码。由于此时是在新的时间重新启用v1版本号的后端代码，则将当前所启动的后端代码的版本号重新配置为v3，以与之前发布v1版本号的后端代码进行区分。

在回滚过程中，需要重启Node后端的机器，则Web前端与Node后端的socket连接断开，在Web前端监听到socket断开时间后，重新与Node后端建立socket连接，此时，会连接到配置有v1版本号的后端代码的机器server。

在重新建立socket连接成功后，Node后端将v1版本号所对应JS/CSS下发到Web前端，然后通过图9中的步骤5)-13)实现图8中步骤3)-步骤13)的过程。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的方法实施例。

图10是根据一示例性实施例示出的一种内容数据的处理装置1000的框图，应用于服务端，参照图10所示，该装置包括：

接收模块1010，用于接收客户端提交的内容数据，内容数据是在客户端的编辑器上进行内容编辑得到的，客户端按照服务端提供的路径获得编辑器。

备份模块1030，用于将内容数据及客户端中编辑器所对应后端代码的第一版本号关联备份于缓存中。

比较模块1050，用于进行第一版本号与第二版本号的比较，第二版本号是数据库中所存储后端代码的版本号。

写入模块1070，用于若第一版本号不低于第二版本号，则将内容数据写入数据库中。

兼容处理模块1090，用于若第一版本号低于第二版本号，则将内容数据与第二版本号的后端代码进行兼容处理。

上述装置中各个模块的功能和作用的实现过程具体详见上述语音信号的处理方法中对应步骤的实现过程，在此不再赘述。

可以理解，这些模块可以通过硬件、软件、或二者结合来实现。当以硬件方式实现时，这些模块可以实施为一个或多个硬件模块，例如一个或多个专用集成电路。当以软件方式实现时，这些模块可以实施为在一个或多个处理器上执行的一个或多个计算机程序。

在一实施例中，该装置还包括：

路径请求接收模块，用于接收客户端发送的路径请求。

路径下发模块，用于响应于路径请求，向客户端下发自身当前所配置后端代码所对应编辑器的路径，以使客户端按照所下发的路径获得编辑器。

在一实施例中，兼容处理模块1090，包括：

差异数据获取单元，用于获取第二版本号的后端代码与第一版本号的后端代码的差异数据。

兼容处理单元，用于按照差异数据对内容数据的兼容处理，以使第二版本号的后端代码所对应编辑器兼容内容数据。

在一实施例中，备份模块1030，包括：

第一获取单元，用于从缓存中获取上一次备份的内容数据。

对比单元，用于对比所接收到的内容数据和上一次备份的内容数据，获得所接收到内容数据相对于上一次备份的内容数据的增量信息。

备份单元，用于将增量信息与客户端中编辑器所对应后端代码的第一版本号关联备份于缓存中。

在一实施例中，该装置还包括：

第二写入模块，用于将兼容处理后的内容数据写入数据库。

在一实施例中，该装置还包括：

持久化处理模块，用于按照预设的周期对缓存中的内容数据进行持久化处理。

在一实施例中，该装置还包括：

修改请求接收模块，用于接收客户端为已提交的内容数据发送的修改请求。

数据获取模块，用于从缓存中获取修改请求所指示的内容数据。

数据返回模块，用于将所获取的内容数据返回至客户端。

上述装置中各个模块/单元的功能和作用的实现过程具体详见上述内容数据的处理方法中对应步骤的实现过程，在此不再赘述。

图11示出了适于用来实现本申请实施例的电子设备的计算机***的结构示意图。

需要说明的是，图11示出的电子设备的计算机***1100仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图11所示，计算机***1100包括中央处理单元(Central Processing Unit，CPU)1101，其可以根据存储在只读存储器(Read-Only Memory，ROM)1102中的程序或者从存储部分1108加载到随机访问存储器(Random Access Memory，RAM)1103中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 1103中，还存储有***操作所需的各种程序和数据。CPU 1101、ROM 1102以及RAM 1103通过总线1104彼此相连。输入/输出(Input/Output，I/O)接口1105也连接至总线1104。

以下部件连接至I/O接口1105：包括键盘、鼠标等的输入部分1106；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1107；包括硬盘等的存储部分1108；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分1109。通信部分1109经由诸如因特网的网络执行通信处理。驱动器1110也根据需要连接至I/O接口1105。可拆卸介质1111，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1110上，以便于从其上读出的计算机程序根据需要被安装入存储部分1108。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1109从网络上被下载和安装，和/或从可拆卸介质1111被安装。在该计算机程序被中央处理单元(CPU)1101执行时，执行本申请的***中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (10)

1.一种内容数据的处理方法，应用于互动视频开放平台后台，其特征在于，包括：

接收客户端提交的互动视频，所述互动视频是在所述客户端的编辑器上进行内容编辑得到的，所述客户端按照所述互动视频开放平台后台提供的路径获得所述编辑器，所述互动视频开放平台后台用于对创作者编辑的互动视频进行管理和存储；

将所述互动视频及所述客户端中编辑器所对应互动视频开放平台后台中后端代码的第一版本号关联备份于缓存中，所述互动视频开放平台后台中后端代码的版本与编辑器的版本是一一对应的；

进行所述第一版本号与第二版本号的比较，所述第二版本号是数据库中所存储所述后端代码的版本号；

若所述第一版本号不低于第二版本号，则将所述互动视频写入所述数据库中；

若所述第一版本号低于所述第二版本号，则将所述互动视频与所述第二版本号的后端代码进行兼容处理；

当所述互动视频开放平台后台发布的后端代码出现错误时，将所述互动视频开放平台后台发布的后端代码重新回滚至低版本号的后端代码。

2.根据权利要求1所述的方法，其特征在于，所述接收客户端提交的互动视频之前，所述方法还包括：

接收所述客户端发送的路径请求；

响应于所述路径请求，向所述客户端下发自身当前所配置后端代码所对应编辑器的路径，以使所述客户端按照所下发的所述路径获得所述编辑器。

3.根据权利要求1所述的方法，其特征在于，所述将所述互动视频与所述第二版本号的后端代码进行兼容处理，包括：

获取所述第二版本号的后端代码与所述第一版本号的后端代码的差异数据；

按照所述差异数据对所述互动视频的兼容处理，以使所述第二版本号的后端代码所对应编辑器兼容所述互动视频。

4.根据权利要求1所述的方法，其特征在于，所述将所述互动视频及所述客户端中编辑器所对应互动视频开放平台后台中后端代码的第一版本号关联备份于缓存中，包括：

从所述缓存中获取上一次备份的所述互动视频；

对比所接收到的所述互动视频和所述上一次备份的互动视频，获得所接收到互动视频相对于所述上一次备份的互动视频的增量信息；

将所述增量信息与所述客户端中编辑器所对应互动视频开放平台后台中后端代码的第一版本号关联备份于缓存中。

5.根据权利要求1所述的方法，其特征在于，所述将所述互动视频与所述第二版本号的后端代码进行兼容处理之后，所述方法还包括：

将兼容处理后的所述互动视频写入所述数据库。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

按照预设的周期对所述缓存中的互动视频进行持久化处理。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收所述客户端为已提交的互动视频发送的修改请求；

从所述缓存中获取所述修改请求所指示的互动视频；

将所获取的所述互动视频返回至所述客户端。

8.一种内容数据的处理装置，其特征在于，包括：

接收模块，用于接收客户端提交的互动视频，所述互动视频是在所述客户端的编辑器上进行内容编辑得到的，所述客户端按照互动视频开放平台后台提供的路径获得所述编辑器，所述互动视频开放平台后台用于对创作者编辑的互动视频进行管理和存储；

备份模块，用于将所述互动视频及所述客户端中编辑器所对应互动视频开放平台后台中后端代码的第一版本号关联备份于缓存中，所述互动视频开放平台后台中后端代码的版本与编辑器的版本是一一对应的；

比较模块，用于进行所述第一版本号与第二版本号的比较，所述第二版本号是数据库中所存储所述后端代码的版本号；

写入模块，用于若所述第一版本号不低于第二版本号，则将所述互动视频写入所述数据库中；

兼容处理模块，用于若所述第一版本号低于所述第二版本号，则将所述互动视频与所述第二版本号的后端代码进行兼容处理；以及

当所述互动视频开放平台后台发布的后端代码出现错误时，将所述互动视频开放平台后台发布的后端代码重新回滚至低版本号的后端代码。

9.一种电子设备，其特征在于，包括：

处理器；及

存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现如权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的方法。

Images