CN113934793A

CN113934793A - 一种运营系统的分布式数据管理系统和方法

Info

Publication number: CN113934793A
Application number: CN202111043461.3A
Authority: CN
Inventors: 肖兴祥; 沈涛; 胡忠雨; 杜盼盼; 邱倩芸; 卢小辉; 沈华雄
Original assignee: Wasu Media & Network Co ltd
Current assignee: Wasu Media & Network Co ltd
Priority date: 2021-09-07
Filing date: 2021-09-07
Publication date: 2022-01-14

Abstract

本发明为一种运营系统的分布式数据管理系统和方法，通过设置中心运营管理系统以及渠道子系统，并且这两者之间采用发布‑订阅的通信连接方式，组成分布式和组件化的整体技术框架，在中心点和拓展点的数据库、缓存和中心点的消息中间件，都支持平滑扩容，从而系统整体具有平滑的扩容能力，并且发布‑订阅的通信连接方式使得数据的同步性更好。

Description

一种运营系统的分布式数据管理系统和方法

技术领域

本发明涉及数据管理领域，特别是涉及一种运营系统的分布式数据管理系统和方法。

背景技术

随着广电传媒行业的发展，对于广电数据的处理也提出了更高的要求。在广电传媒行业中，业务数据具备统一运营、地区数据个性化、数据颗粒度小等特点；其中统一运营表示外拓外拓地市区县的业务运营由中心运营系统统一运营管理；地区数据个性化表示对于不同的地区，存在特定的运营需求；颗粒度小表示外拓业务的数量多，小至乡镇，甚至社区为单位。上述的业务数据主要包括三部分，分别为通用基础数据、个性化热活数据以及第三方关联热活数据。其中通用基础数据表示在拓展地区业务时通用的非个性化基本数据，该部分数据在运营的过程中变化较小，一般也不会因地区变化而产生转变。个性化热活数据表示根据拓展地区的实际情况，衍生出的个性化数据，每个拓展地区的个性化数据不相同，且每个拓展地区在个性化数据上只使用各自地区的个性化数据，比如地方新闻、旅游资讯、当地政府公告、本地应急广播消息等。个性化热活数据的更新频率较高，通常要求编辑发布后实时生效和展示，是运营人员日常编辑最为频繁的数据类型。第三方关联热活数据表示根据运营业务需求，从具备其他功能的外部系统引入的数据，比如从大数据系统引入计算后的用户画像数据、从搜索系统引入的搜索排行榜等；这类数据的特点是需要定期更新。

基于上述广电行业的业务数据特点以及分类，现有的业务数据管理方式主要分为两类，分别为单独运营部署以及统一运营部署。其中单独运营部署表示对每个拓展地区独立部署一套完整的运营管理系统和服务能力系统，要求业务数据的存储以独享的数据库或者缓存集群的方式实现，对于集群中每一个存储介质中存储的数据一致。在单独运营部署中由于每个地区都部署有各自的系统和存储，因此在数据变更时，尤其是通用基础数据变更时，需要对每个地区都进行更新，提高了人力和物力成本；另一方面众多的设备以及设备的广泛分布，提高了系统部署和维护的成本；最后每个地区的数据相互独立，也提高了运营成本。统一运营部署表示设置中心数据库，通过唯一的统一运营系统实现所有地区的业务数据的管理；要求业务数据的存储以庞大的共用的数据库或缓存集群方式实现，集群中每一个存储介质中存储的数据一致；其中，外拓地区通过授权，直接访问统一运营系统及其数据库和缓存。在统一运营部署中，由于数据高度集中，因此一旦统一运营系统出现问题，会影响所有的拓展地区，另一方面，还对中心数据库的存储能力提出了极高的要求。因此需要一种分布式的业务数据存储方法，既能集中管理所有拓展地区的业务数据，也能缓解中心数据库的存储压力，契合各地区数据个性化特点。

发明内容

本发明的目的是解决现有技术的不足，提供一种运营系统的分布式数据管理系统和方法。

为了解决上述问题，本发明采用如下技术方案：

一种运营系统的分布式数据管理系统，包括中心运营管理系统、渠道子系统以及外部系统；其中外部系统用于获取第三方关联热活数据；外部系统与中心运营管理系统连接；中心运营管理系统与至少一个渠道子系统连接；中心运营管理系统与渠道子系统之间采用发布-订阅的通信连接方式。

进一步的，所述中心运营管理系统包括运营管理平台以及中心数据管理模块，其中运营管理平台与中心数据管理模块通信连接。

进一步的，所述中心数据管理模块包括中心缓存、中心数据库、消息中间件以及CANAL模块；其中消息中间件分别与中心缓存以及CANAL模块连接；CANAL模块与中心数据库连接；中心缓存分别与外部系统以及运营管理平台连接；消息中间件还与渠道子系统连接；中心数据库还与运营管理平台连接。

进一步的，所述渠道子系统包括地区数据管理模块以及渠道子系统服务模块，其中地区数据管理模块分别与渠道子系统服务模块以及中心数据管理模块的消息中间件连接。

进一步的，所述地区数据管理模块包括地区缓存以及地区数据库，其中地区缓存以及地区数据库均与中心数据管理模块的消息中间件连接，另外地区缓存还与地区数据库以及渠道子系统服务模块连接。

一种运营系统的分布式数据管理方法，包括如下步骤：

步骤1：中心运营管理系统获取业务数据；业务数据包括通用基础数据、个性化热活数据和第三方关联热活数据；

步骤2：判断业务数据的类型；若业务数据为个性化热活数据和第三方关联热活数据，则将业务数据存储于中心缓存；若业务数据为通用基础数据，则将业务数据存储于中心数据库；

步骤3：消息中间件从中心缓存中获取个性化热活数据和第三方关联热活数据，以及通过CANAL模块从中心数据库中自动获取通用基础数据；

步骤4：消息中间件根据渠道子系统订阅的消息topic，将获取的业务数据发送到指定的渠道子系统；

步骤5：渠道子系统判断业务数据的类型；若业务数据为个性化热活数据和第三方关联热活数据，则将业务数据存储于地区缓存；若业务数据为通用基础数据，则将业务数据存储于地区数据库。

进一步的，所述步骤1中，中心运营管理系统获取业务数据中的个性化热活数据为设定的数据；个性化热活数据中包括指定的消息topic；第三方关联热活数据由中心运营管理系统周期性获取，包括定时任务或者外部系统推送的获取方式；第三方关联热活数据中包括特定消息topic。

进一步的，所述步骤2中的中心数据库为mysql数据库。

进一步的，所述步骤3中，CANAL模块从中心数据库中自动获取通用基础数据的过程包括如下步骤：

步骤31：CANAL模块监控中心数据库，判断中心数据库中的通用基础数据是否发生改变；若中心数据库中的通用基础数据发生改变，则进入下一步骤；否则返回步骤31；

步骤32：中心数据库的通用基础数据发生改变；中心数据库将改变记录写入其二进制日志中；

步骤33：CANAL模块根据mysql slave的交互协议，模拟mysql slave，向中心数据库的mysql master发送dump协议；其中mysql slave表示从数据库，mysql master表示主数据库，dump表示备份；

步骤34：中心数据库收到dump请求，并向CANAL模块推送二进制日志；

步骤35：CANAL模块解析二进制日志对象，并将解析后的二进制日志封装为消息中间件的消息；

步骤36：CANAL模块将封装后的包含增量数据的消息发布到消息中间件。

进一步的，所述步骤5中，渠道子系统将通用基础数据存储于地区数据库后，还会将地区数据库中的数据加载到地区缓存中。

本发明的有益效果为：

通过消息中间件将业务数据分别传输到渠道子系统中，其中通用基础数据由运营人员集中编辑，并实时同步到订阅的渠道子系统中，个性化热活数据由运营人员集中编辑，渠道子系统只同步自己需要的个性化热活数据，第三方关联热活数据由中心运营管理系统集中引入，渠道子系统通过消息的订阅，获取全部或者指定的第三方关联热活数据，形成集中运营和灵活的业务数据管理模式；

通过设置中心运营管理系统以及渠道子系统，并且这两者之间采用发布-订阅的通信连接方式，组成分布式和组件化的整体技术框架，在中心点和拓展点的数据库、缓存和中心点的消息中间件，都支持平滑扩容，从而系统整体具有平滑的扩容能力，并且发布-订阅的通信连接方式使得数据的同步性更好；

通过设置渠道子系统包括地区缓存和地区数据库，使得拓展地区能够独立管理地区的所有数据，能够灵活的更改自己的数据存储组件和存储方式，使得系统数据管理在整体上更加灵活；

通过设置CANAL模块监控中心数据库，其一实时同步了中心数据库的数据到下游子系统，其二是实现了实时增量同步，而不是全量同步，提高通用基础数据同步的速度；

通过设置中心运营管理系统，并由运营人员集中在中心运营管理系统编辑数据后，下游渠道子系统根据订阅消息自动获取数据，缩小运营人员参与日常数据运营的范围，简化运营人员个性化运营操作，节省运营成本。

附图说明

图1为本发明实施例一的整体结构图；

图2为本发明实施例一的通用基础数据处理流程图。

具体实施方式

以下通过特定的具体实例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

实施例一：

如图1所示，一种运营系统的分布式数据管理系统，包括中心运营管理系统、渠道子系统以及外部系统；其中外部系统用于获取第三方关联热活数据，外部系统包括外部的视频软件平台等；外部系统与中心运营管理系统连接；中心运营管理系统与至少一个渠道子系统连接；中心运营管理系统与渠道子系统之间采用发布-订阅的通信连接方式。

所述中心运营管理系统包括运营管理平台以及中心数据管理模块，其中运营管理平台与中心数据管理模块通信连接。运营管理平台用于实现人机交互，实现对整个系统的操控；通过运营管理平台还能够向系统输入通用基础数据以及个性化热活数据。中心数据管理模块包括中心缓存、中心数据库、消息中间件以及CANAL模块；其中消息中间件分别与中心缓存以及CANAL模块连接；CANAL模块与中心数据库连接；中心缓存分别与外部系统以及运营管理平台连接；消息中间件还与渠道子系统连接；中心数据库还与运营管理平台连接。在本例中中心数据库用于管理通用基础数据，中心缓存用于管理个性化热活数据以及第三方关联热活数据；消息中间件用于分发数据，在本例中根据渠道子系统的订阅实现分发数据，每个渠道子系统订阅至少一个消息topic；CANAL模块用于监控中心数据库中的数据变化，在本例中为中心数据库中的通用基础数据变化。在本例中中心数据库采用mysql数据库。

所述渠道子系统包括地区数据管理模块以及渠道子系统服务模块，其中地区数据管理模块分别与渠道子系统服务模块以及中心数据管理模块的消息中间件连接。地区数据管理模块用于存储地区的业务数据，包括通用基础数据、个性化热活数据和第三方关联热活数据；渠道子系统服务模块用于处理地区的请求，作为该渠道子系统所服务的地区的数据源，给该地区用户提供数据能力服务。地区数据管理模块包括地区缓存以及地区数据库，其中地区缓存以及地区数据库均与中心数据管理模块的消息中间件连接，另外地区缓存还与地区数据库以及渠道子系统服务模块连接。

在实施的过程中，通过设置中心运营管理系统以及渠道子系统，并且这两者之间采用发布-订阅的通信连接方式，保证了业务数据同步的实时性，便于更新和管理渠道子系统，另外在运营管理平台输入数据后，下游的渠道子系统会根据订阅的内容进行数据的获取，缩小了运营人员参与日常数据运营的范围，简化了运营人员个性化运营操作，节约了运营成本。

一种运营系统的分布式数据管理方法，包括如下步骤：

所述步骤1中，中心运营管理系统获取业务数据中的个性化热活数据，在本例中为运营人员输入的数据，个性化热活数据中包括指定的消息topic，即运营人员指定该个性化热活数据传输向对应的一个或多个渠道子系统，在本例中为对应的一个渠道子系统。对于第三方关联热活数据，中心运营管理系统设置为周期性获取，包括定时任务或者外部系统推送等获取方式。第三方关联热活数据中包括设定的特定消息topic，在本例中，由操作人员对不同的第三方关联热活数据预先设定特定消息topic，在中心运营管理系统封装消息时，会对消息写入消息topic。

如图2所示，所述步骤3中，CANAL模块从中心数据库中自动获取通用基础数据的过程包括如下步骤：

步骤31：CANAL模块监控中心数据库，判断中心数据库中的通用基础数据是否发生改变；若中心数据库中的通用基础数据发生改变，则进入下一步骤；否则返回步骤31；在本例中，中心数据库为mysql数据库；

步骤32：中心数据库的通用基础数据发生改变，并将改变记录写入其二进制日志中；

步骤36：CANAL模块将封装后的包含增量数据的消息发布到消息中间件；增量数据表示步骤32中的改变记录对应的通用基础数据。

在步骤32中，中心数据库仅将改变的通用基础数据的内容写入二进制日志，后续步骤中，CANAL组件解析该二进制文件并将文件内容封装成消息中间件的消息，由于中心数据库的二进制日志只记录更改的数据信息，故可以实现通用基础数据的增量更新。

在步骤35中，在二进制日志封装为消息中间件的过程中还会写入消息topic。

在步骤36中，消息中间件发布封装的通用基础数据后，下游的渠道子系统会根据订阅情况，获取封装的通用基础数据，并对本地通用基础数据进行更新，在本例中为增量更新。

需要说明的是，在步骤5中，通用基础数据存储于地区数据库后，渠道子系统还会将地区数据库中的数据加载到地区缓存中，以便快速使用；在本例中渠道子系统中的渠道子系统服务模块的业务数据直接来源均为地区缓存。

在实施的过程中，通过消息中间件将业务数据分别传输到渠道子系统中，其中通用基础数据由运营人员集中编辑，并实时同步到订阅的渠道子系统中，个性化热活数据由运营人员集中编辑，渠道子系统只同步自己需要的个性化热活数据，第三方关联热活数据由中心运营管理系统集中引入，渠道子系统通过消息的订阅，获取全部或者指定的第三方关联热活数据，形成集中运营和灵活的业务数据管理模式；通过设置中心运营管理系统以及渠道子系统，并且这两者之间采用发布-订阅的通信连接方式，组成分布式和组件化的整体技术框架，在中心点和拓展点的数据库、缓存和中心点的消息中间件，都支持平滑扩容，从而系统整体具有平滑的扩容能力，并且发布-订阅的通信连接方式使得数据的同步性更好；通过设置渠道子系统包括地区缓存和地区数据库，使得拓展地区能够独立管理地区的所有数据，能够灵活的更改自己的数据存储组件和存储方式，使得系统数据管理在整体上更加灵活；通过设置CANAL模块监控中心数据库，保证对渠道子系统更新通用基础数据的及时性；通过设置中心运营管理系统，并由运营人员集中在中心运营管理系统编辑数据后，下游渠道子系统根据订阅消息自动获取数据，缩小了运营人员参与日常数据运营的范围，简化了运营人员个性化运营操作，节约了运营成本。

以上描述仅是本发明的一个具体实例，不构成对本发明的任何限制。显然对于本领域的专业人员来说，在了解了本发明内容和原理后，都可能在不背离本发明原理、结构的情况下，进行形式和细节上的各种修改和改变，但是这些基于本发明思想的修正和改变仍在本发明的权利要求保护范围之内。

Claims

1.一种运营系统的分布式数据管理系统，其特征在于，包括中心运营管理系统、渠道子系统以及外部系统；其中外部系统用于获取第三方关联热活数据；外部系统与中心运营管理系统连接；中心运营管理系统与至少一个渠道子系统连接；中心运营管理系统与渠道子系统之间采用发布-订阅的通信连接方式。

2.根据权利要求1所述的一种运营系统的分布式数据管理系统，其特征在于，所述中心运营管理系统包括运营管理平台以及中心数据管理模块，其中运营管理平台与中心数据管理模块通信连接。

3.根据权利要求2所述的一种运营系统的分布式数据管理系统，其特征在于，所述中心数据管理模块包括中心缓存、中心数据库、消息中间件以及CANAL模块；其中消息中间件分别与中心缓存以及CANAL模块连接；CANAL模块与中心数据库连接；中心缓存分别与外部系统以及运营管理平台连接；消息中间件还与渠道子系统连接；中心数据库还与运营管理平台连接。

4.根据权利要求3所述的一种运营系统的分布式数据管理系统，其特征在于，所述渠道子系统包括地区数据管理模块以及渠道子系统服务模块，其中地区数据管理模块分别与渠道子系统服务模块以及中心数据管理模块的消息中间件连接。

5.根据权利要求4所述的一种运营系统的分布式数据管理系统，其特征在于，所述地区数据管理模块包括地区缓存以及地区数据库，其中地区缓存以及地区数据库均与中心数据管理模块的消息中间件连接，另外地区缓存还与地区数据库以及渠道子系统服务模块连接。

6.一种运营系统的分布式数据管理方法，其特征在于，包括如下步骤：

7.根据权利要求5所述的一种运营系统的分布式数据管理方法，其特征在于，所述步骤1中，中心运营管理系统获取业务数据中的个性化热活数据为设定的数据；个性化热活数据中包括消息topic；第三方关联热活数据由中心运营管理系统周期性获取；周期性获取包括定时任务或者外部系统推送的获取方式；第三方关联热活数据中包括消息topic。

8.根据权利要求5所述的一种运营系统的分布式数据管理方法，其特征在于，所述步骤2中的中心数据库为mysql数据库。

9.根据权利要求5所述的一种运营系统的分布式数据管理方法，其特征在于，所述步骤3中，CANAL模块从中心数据库中自动获取通用基础数据的过程包括如下步骤：

步骤31：CANAL模块监控中心数据库，判断中心数据库中的通用基础数据是否发生改变；若中心数据库中的通用基础数据发生改变，则进入下一步骤；

否则返回步骤31；在本例中，中心数据库为mysql数据库；

步骤32：中心数据库的通用基础数据发生改变，并将改变记录写入其二进制日志中

步骤33：CANAL模块根据mysqlslave的交互协议，模拟mysqlslave，向中心数据库的mysql master发送dump协议；其中mysqlslave表示从数据库，mysqlmaster表示主数据库，dump表示备份；

10.根据权利要求5所述的一种运营系统的分布式数据管理方法，其特征在于，所述步骤5中，渠道子系统将通用基础数据存储于地区数据库后，还会将地区数据库中的数据加载到地区缓存中。