新闻制播系统云容灾数据同步方案设计与实践

任芳琴

（浙江广播电视集团，浙江 杭州 310005）

0 引言

新闻制播系统是电视台的重要信息系统，业务连续性要求高，因此在系统设计和建设过程中，除了采用服务集群化部署、负载均衡、网络堆叠等多种措施确保系统本身的稳定性，还会考虑搭建灾备系统，提高可用性。

电视台以媒体数据作为节目生产的核心要素，视音频素材、图片等非结构化数据占整体数据的90%以上，且随着近些年分布式存储的发展及性价比提升，在线数据存储周期变长。以浙江广播电视集团新闻制播系统为例，在线数据容量常年在500 TB以上。因此，如果存储发生故障或发生人为误操作，数据恢复时间（Recovery Time Object，RTO）很有可能超过新闻生产业务连续性要求的阈值，最终造成节目来不及制作、无法播出等重大播出事故。对此，构建一套高效、可靠、可行的容灾方案，针对数据库层、存储层的数据容灾是关键[1]。

1 设计思路

本文介绍的新闻制播系统的数据容灾基于媒体私有云平台，两者采用异址多活的设计思路。新闻制播系统（以下称本地系统）采用本地化部署设计，各类服务组件、应用均部署在物理机上，视音频素材、图片、故事板等非结构化数据存储于分布式存储上，存储文稿数据、系统配置信息和业务过程数据采用MySQL 数据库。媒体私有云平台采用多租户模式，其平台服务层（Platform as a Service，PaaS）能够为上层业务系统提供各类公共服务，包括媒体服务、数据库服务及中间件等各类通用服务，满足节目生产所需[2]。

云平台与本级系统之间数据实时双向同步，保持媒体内容（元数据、代理码率、媒体素材等）一致。正常情况下，本地系统和云平台相互独立运行，互不依赖。基于一致性的媒体内容，浙江广播电视集团采用以下业务模式：大屏新闻节目的采编播流程主要使用本地制播系统的功能模块资源，新媒体服务业务则选用云平台的功能模块资源。应急情况下，若本级系统出现问题无法使用，云平台的弹性可快速实现所需资源的调配，通过手动修改后台策略设置，将后端服务指向云平台侧，提供持续业务生产能力。总体设计思路如图1 所示。

图1 容灾总体设计思路

1.1 数据同步总体设计原则

实现容灾的关键设计要素是数据的同步。数据同步总体设计原则[3]如下。

第一，本地系统与云平台之间具备持续性、高效、高可靠的数据传输链路和传输协议。

第二，同步的数据包括用户数据、文稿数据、时间线数据、视频素材数据、后期包装图片以及字幕动画数据等。支持对数据操作的同步，比如对数据的删除、数据的元数据属性编辑。

第三，任意一方数据中心的数据发生变化，都将变化同步到另一方。数据接受方应禁止访问未同步完成的数据并给出明确的提示。

第四，任何时候都要保证双方数据的一致性和完整性。任何一方的后台服务或数据宕机瘫痪不能影响另一方的正常运行，并能继续生产节目。

第五，需要对数据同步进行统一监控和管理，第一时间发现潜在异常，以免影响业务的正常运转。

第六，如遇同步链路中断，恢复后自动完成未完成的复制任务，保持数据的最终一致性。

1.2 同步数据类型

从业务角度分析，双数据中心间可同步的数据对象包括媒体元数据、视音频、图片等媒体文件、非编工程文件及元数据、文稿及串联单等。根据类型的不同，不同数据采用不同的同步机制。

2 双向同步的实现

2.1 实现机制

同步服务模块由消息服务、流程服务、传输服务3 个部分组成，用于提供本地系统和云平台两个数据中心之间的数据同步服务。消息服务通过收集系统中数据变化的通知消息，对其进行判断过滤，进而执行同步策略，驱动流程服务进行同步流程操作。流程服务接受消息服务发送的同步请求，执行数据同步流程。传输服务提供需要同步数据的传输。3 个服务之间通过REST 接口交互。通过消息、流程、传输3 个服务的配合，完成数据的同步备份，如图2所示，主要步骤如下。

图2 同步服务模块

消息服务通过订阅消息队列，对用户操作引起的数据变化进行监听，如新建稿件或者素材上载。消息服务接收消息，进行消息过滤。消息服务接收消息后，开始扫描变更数据，并根据系统策略配置完成数据同步范围、周期、同步源的设定。设定完成后，系统自动执行同步。流程服务发起同步流程，生成传输任务（文件、元数据、基础数据类型）发给传输服务。传输服务开始传输数据，元数据使用超文本传输安全协议（Hypertext Transfer Protocol Secure，HTTPS）调用RestFul 接口传输，媒体文件采用自定义用户数据报协议（User Datagram Protocol，UDP）多链路传输。对端数据中心的传输服务开始接收数据，接收完成后，由流程服务开始入库流程，完成数据校对后，完成数据入库。

2.2 最终一致性

数据同步遵循最终一致性原则。为此，需要解决两个问题。一是数据同步带来的数据版本管理的问题[4]。比如正常情况下，本地系统和云平台的上层应用可能同时打开同一份稿件或时间线，这时双向同步便产生多个数据版本，产生数据混乱。对此，通过增加控制标识（云端或本地），确保同一时刻只更新一端数据库，即应用只读取/写入使用一个数据中心的数据，另一份数据中心的数据只是同步更新，以此规避多版本管理的问题。对于记者编辑来说，无论使用本地或是云平台的应用，只有设置当前系统标识的稿件、节目时间线等才能被打开并编辑，否则就只会提示只读打开。二是数据同步失败的处理。在系统维护层面，对数据同步过程的监控和管理是确保准确性的重要一环。为此，系统为运维人员提供同步监控管理界面（如图3 所示），实时追踪数据同步状态和进度，及时捕捉并应对异常情况。对于没有完成同步或者同步到对端元数据有问题的情况，可以删除有问题的对端同步文件，并通过同步工具重新发起同步流程。在应用层面，如果记者编辑打开了正在同步的时间线或者同步失败，应用软件便会给出相应的提示。

图3 同步监控界面

2.3 数据同步的可靠性

在网络层，本地系统与云平台两个数据中心通过冗余网络链路联通。为确保同步服务的稳定性，进行了以下调优。第一，因同步服务数据库数据量较大，同步数据库与业务核心数据库分开，单独创建数据库部署在同步服务器上。第二，本地系统侧和云平台侧均采用集群化部署，即使某同步服务器出现链路断开或服务异常的情况，集群中的其他服务器会接管继续执行同步任务。第三，为防止单台服务器负载过大导致服务宕机，由流程服务产生的任务调度模式采用负载均衡模式，并可根据实际情况设置最大任务数量。第四，根据每天同步的数据量以及同步服务器之间的带宽，传输服务设置最大传输执行器，每个执行器对应不同的UDP 端口。

3 应急切换测试

为保证容灾可用性，进行应急切换测试。设置如下测试场景：本地系统因分布式存储故障导致不可用，非编工作站访问不到非编素材，打开时间线显示 “media offline” ，准备进行应急操作，将支撑非编应用的后台服务、数据库和存储快速切换到云平台，云平台按需调配资源。

非编软件配置信息主要做以下更改：将非编软件所访问的CMS 服务和中间件、数据库等后台服务网际互连协议（Internet Protocol，IP）地址从本地系统更改为云平台，向云平台的服务注册非编工作站终端IP 地址，非编工作站挂载云平台的存储，更改非编软件的登录认证信息，并改向蓝云的轻型目录访问协议（Lightweight Directory Access Protocol，LDAP）认证。为简化切换操作，做到快速切换，技术人员提前将相关配置写入配置文件，切换时，直接进行配置文件替换即可。

后台服务和存储切换成功后，如果时间线的控制标识是 “本地系统” ，需要将该控制标识切至 “云平台” ，在时间线上右键刷新并打开时间线，时间线成功识别到云平台素材，能够正常进行编辑操作。编辑完成后，发送合成并审核通过。审核通过后，演播室播出。整个演练流程[5]，如图4 所示。

图4 应急切换演练流程

4 结语

制播系统的容灾多种多样，有些是建设最小应急系统，有些则是简单地通过配置双体存储确保数据高可用。但是这些方式的资源调配都不够灵活，或者只能起到数据备份的作用，或者应急生产规模缩小，而且从经济角度讲，需要投入一套包括软件、计算、存储及网络等在内的重复资源。相比传统的灾备方式，借助云平台进行灾备，提高了资源利用效率，且真正获得了一套完整生产系统克隆的能力。相信云上灾备的解决方案将越来越被行业所认可。