CN106156047B - 一种快照信息处理方法及装置 - Google Patents

Abstract

本发明实施例公开了一种快照信息处理方法及装置，该方法包括：获取快照采集配置信息；根据所述快照采集配置信息进行快照信息采集；将采集的快照信息写入数据库，所述数据库为基于分布式文件存储的数据库。本发明实施例根据快照配置获取快照信息并进行统一管理，从而当备份要求发生变化时，可以通过更改快照配置进行调整，实现简单；并且，本发明实施例采用基于分布式文件存储的数据库存储快照信息，节省了存储空间，且便于查询，能够准确体现业务流程的走向，全方位展现数据变更的逻辑。

Description

一种快照信息处理方法及装置

技术领域

本发明涉及移动通信客户业务支撑领域，尤其涉及一种快照信息处理方法及装置。

背景技术

现在的移动业务支撑系统越来越复杂，对用户核心信息更改的请求来源也越来越多，有界面发起的受理请求，有电子渠道发起的订单请求，还有后台服务发起的批量业务处理请求等等。因此，一旦出现用户数据问题，难于短时间定位出数据是根据哪个请求而发生的变更，在哪个模块进行变更的，是什么原因导致这个变更的。

目前，大部分的移动业务支撑系统使用历史备份表进行的，就是将变更前的信息保存在对应的历史表中，可以根据历史流水和受理流水来进行追溯，但是这样做会有以下局限：每个业务处理涉及表较多，有些重要信息会有备份，但有些在最初设计的时候没有备份要求，后续需要增加备份要求时相对麻烦；同时，历史备份也消耗关系型数据库的存储空间，造成资源的浪费；还有，采用受理流水来进行备份数据的手工查询，难于准确体现业务流程的走向，无法全方位展现数据变更的逻辑。

发明内容

有鉴于此，为解决现有存在的技术问题，本发明实施例提供：

一种快照信息处理方法，包括：

获取快照采集配置信息；

根据所述快照采集配置信息进行快照信息采集；

将采集的快照信息写入数据库，所述数据库为基于分布式文件存储的数据库。

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

对数据库中存储的快照信息进行分析，获取并保存分析结果。

一具体实施例中，所述分析结果包括以下一项或多项：表更新概率、表操作时段分布情况、业务操作时段分布情况、业务受理数据库占用时长。

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

获取信息查询请求；

根据所述信息查询请求，获取相应的快照信息或分析结果，并返回。

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

获取配置修改请求；

根据所述配置修改请求，修改快照采集配置信息。

本发明实施例还提出了一种快照信息处理装置，包括：快照采集配置模块、快照信息采集模块和数据库；其中，

所述快照采集配置模块，用于进行快照采集信息配置；

所述快照信息采集模块，用于获取快照采集配置信息，并根据所述快照采集配置信息进行快照信息采集；以及将采集的快照信息写入数据库；

所述数据库，为基于分布式文件存储的数据库，用于存储快照信息。

一具体实施例中，该装置还包括快照信息管理模块，

所述快照信息管理模块，用于对数据库中存储的快照信息进行分析，获取分析结果，并将分析结果存储至数据库。

一具体实施例中，所述快照信息管理模块获取的分析结果包括以下一项或多项：表更新概率、表操作时段分布情况、业务操作时段分布情况、业务受理数据库占用时长。

一具体实施例中，该装置还包括交互模块，

所述交互模块，用于获取信息查询请求；以及展示快照信息管理模块返回的快照信息或分析结果；

所述快照信息管理模块，还用于根据所述信息查询请求，获取相应的快照信息或分析结果，并返回交互模块。

一具体实施例中，所述交互模块，还用于获取配置修改请求；

所述快照采集配置模块，还用于根据所述配置修改请求，修改快照采集配置信息。

本发明实施例所述的快照信息处理方法及装置，获取快照采集配置信息；根据所述快照采集配置信息进行快照信息采集；将采集的快照信息写入数据库，所述数据库为基于分布式文件存储的数据库。本发明实施例根据快照配置获取快照信息并进行统一管理，从而当备份要求发生变化时，可以通过更改快照配置进行调整，实现简单；并且，本发明实施例采用基于分布式文件存储的数据库存储快照信息，节省了存储空间，且便于查询，能够准确体现业务流程的走向，全方位展现数据变更的逻辑。

附图说明

图1为本发明实施例一种快照信息处理方法流程示意图；

图2为本发明实施例一种快照信息处理装置结构示意图；

图3为本发明实施例再一种快照信息处理装置结构示意图；

图4为本发明实施例再一种快照信息处理装置结构示意图；

图5为本发明实施例1所述快照信息处理装置的结构示意图；

图6为本发明实施例1所述快照信息处理装置的逻辑架构示意图；

图7为本发明实施例1中所述快照信息处理方法的流程示意图。

具体实施方式

本发明实施例提出了一种快照信息处理方法，如图1所示，该方法包括：

步骤11：获取快照采集配置信息；

这里，快照采集配置信息可以以业务请求功能代码、模块点标识、模块快照点为关键字进行存储，同时，可以根据实际需求随时进行修改。

步骤12：根据所述快照采集配置信息进行快照信息采集；

步骤13：将采集的快照信息写入数据库，所述数据库为基于分布式文件存储的数据库。

需要说明的是，步骤11、步骤12、步骤13的执行主体一般为应用进程，相应的，步骤13中，在应用进程结束时，将采集的快照信息写入数据库。

这里，数据库可以采用MongoDB，MongoDB由C++语言编写，旨在为Web应用提供可扩展的高性能数据存储解决方案。MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bson格式，因此可以存储比较复杂的数据类型。MongoDB最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

MongoDB是无模式的文档型数据库，Mongo的BSON数据格式非常适合文档化格式的存储及查询，在表1描述了一种快照信息的存储表格式，：

表1

如表1所示，一个业务快照信息包括多张Oracle数据库表快照信息，一个表快照信息包括多个行快照信息，一个行快照信息包括多个字段的快照信息，根据存储结构可以很方便的检索出业务的快照情况、模块更新的表和表的新旧更新值。

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

对数据库中存储的快照信息进行分析，获取并保存分析结果。具体的，可以分析获取表更新概率、表操作时段分布情况、业务操作时段分布情况、业务受理数据库占用时长等信息，以便后续使用。

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

获取信息查询请求；

根据所述信息查询请求，获取相应的快照信息或分析结果，并返回。

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

获取配置修改请求；

根据所述配置修改请求，修改快照采集配置信息。

本发明实施例还提出了一种快照信息处理装置，如图2所示，该装置包括：快照采集配置模块21、快照信息采集模块22和数据库23；其中，

所述快照采集配置模块21，用于进行快照采集信息配置；

所述快照信息采集模块22，用于获取快照采集配置信息，并根据所述快照采集配置信息进行快照信息采集；以及将采集的快照信息写入数据库；

所述数据库23，为基于分布式文件存储的数据库，用于存储快照信息。

一具体实施例中，如图3所示，该装置还包括快照信息管理模块24，

所述快照信息管理模块24，用于对数据库23中存储的快照信息进行分析，获取分析结果，并将分析结果存储至数据库。

一具体实施例中，所述快照信息管理模块24获取的分析结果包括以下一项或多项：表更新概率、表操作时段分布情况、业务操作时段分布情况、业务受理数据库占用时长。

一具体实施例中，如图4所示，该装置还包括交互模块25，

所述交互模块25，用于获取信息查询请求；以及展示快照信息管理模块返回的快照信息或分析结果；

所述快照信息管理模块24，还用于根据所述信息查询请求，获取相应的快照信息或分析结果，并返回交互模块。

一具体实施例中，所述交互模块25，还用于获取配置修改请求；

所述快照采集配置模块21，还用于根据所述配置修改请求，修改快照采集配置信息。

采用本发明实施例所述的方案，能够解决目前难于对业务数据进行追溯的问题，同时提供一个管理工具，支持查询业务受理给业务数据带来变更的全方位视图，利用基于分布式文件存储的数据库实现业务数据快照的分布式存储及高效的快照备份，实现类似内存消息队列的功效，由于使用分布式的部署，可以有效的降低设备资金投入和关系型数据库的使用，同时增强并发能力，能够实现部署云化，对外提供无限扩展的快照信息存储能力。

下面通过具体实施例对本发明的技术方案作进一步详细说明。

实施例1

本发明实施例为了兼顾目前的移动业务支撑系统的局限性，有效的解决移动业务快照信息统一处理的问题，同时实现数据可追溯的功能，以及为了满足低成本、高效率和可扩展的要求，使用MongoDB作为数据库存储，同时使用Tailable游标(MongoDB TailableCursors)的功能实现了快照管理系统的分布式消息接收队列。需要说明的是，MongoDBTailable Cursors是一个类似于UNIX tail-f命令的功能，它使用在MongoDB的固定大小的集合(Capped Collection)上。在一个Capped Collection上面执行查询操作，当操作完成后，可以不关闭返回的数据Cursor，并持续地从中读出新加入的数据，而且集合的大小可设定，当数据大小超出设定大小时，新数据会抹掉旧数据，利用此特性加上MongoDB的复制(Replication)机制，可以实现一个分布式的消息队列系统。

图5为本发明实施例1所述快照信息处理装置的结构示意图，如图5所示，该装置包括：

内存(对应快照采集配置模块21)，用于存储快照采集信息；

快照生成模块(对应快照信息采集模块22)：用于根据业务请求功能代码、模块点标识和模块快照点,查找内存中的快照配置，看该模块内的该快照点，需要哪些快照信息；以及根据返回的需要快照的对象，循环调用各个对象的快照，将快照信息保存在程序缓存中，模块执行结束后，将快照对象生成的快照缓存输出到MongoDB数据库集群中；

快照管理模块(对应快照信息管理模块24)：对Capped Collection数据进行处理的模块，将消息中的数据备份到普通表中，并且进行相应的数据分析统计，为后续的查询服务提供原始数据的支撑，如表更新概率、表操作时段分布情况、业务操作时段分布情况、业务受理数据库占用时长等等，将目前基于Oracle的统计迁移到MongoDB上，减少Oracle数据的压力。查询服务则是提供Web其他进行相应的数据查询；

Web管理模块(对应交互模块25)：使用MongoDB使得可以有效直观的查看业务快照信息，提供更新前后的数据对比查询，也提供表变更概率及效率的统计查询，可以体现系统对表的操作情况，为运维提供相关的报表及数据分析结果的多中形式的展现，同时Web管理模块还提供快照生成配置的维护，实现对内存Cache中的快照配置进行管理；

MongoDB数据集群(对应数据库23)：提供快照接收信息队列，同时存储处理后的快照信息；MongoDB是基于文档的，因此对于不规则的数据存储优势明显，同时整个集群可以横向扩展，保存较长时间的数据，提供故障查询，而且可以利用MongoDB的mapreduce功能进行复杂的分析功能，包括反向查询表操作效率和表数据更新情况，不仅仅只是对快照信息进行监控等等。

图6为本发明实施例1中所述快照信息处理装置的逻辑架构示意图，如图6所示，快照信息处理装置逻辑架构包括：

数据采集层：提供单向数据流，从外部应用服务中获取快照数据写入数据层的工单信息中；

数据层：提供双向数据流，保存采集层的快照工单信息，以及向应用层提供快照信息的读取能力；

应用层：提供双向数据流，从数据层获取快照工单信息，进行合并、疏理和分析，组织成数据层中的分析数据，以及将分析数据经过Web应用层提供给展现层；

Web应用层：提供双向数据流，沟通应用层与用户之间的数据流，提供网络服务服务；

展现层：提供双向数据流，获取数据层的分析数据，以及经由Web应用层向数据采集层提供采集配置信息。

图7为本发明实施例1中所述快照信息处理方法的流程示意图，如图7所示，该流程包括：

步骤702：用户根据需要在Web界面配置快照信息采集规则，并且写入内存。

这里，应用程序的快照生成规则保存在整个业务系统的全局内存中，提供全系统的配置能力，在Web应用层中提供相应的管理功能，可以配置业务请求功能代码、模块标识和模块快照点的采集规则，实现数据更新时的备份，如集团产品变更快照配置，业务请求功能代码：93200331，模块标识：TEGroupCancel，模块快照点：GroupProductDeal::CencelGroupProduct。

步骤704：各应用进程使用快照生成模块从内存加载快照采集规则。

这里，应用进程在受理服务请求到达时从内存中获取相应的快照配置，形成程序的全局参数供子模块使用。

步骤706：各应用进程的采集点根据采集规则获取快照信息，包括更新信息和旧数据信息，生成数据插入到程序缓存中。

这里，应用进程在调用子模块时，子模块根据相应的配置信息，调用快照生成模块根据生成相应的快照信息，使用MongoDB的文档存储格式BJSON进行存储。

步骤708：应用进程结束时，将程序缓存中的数据写入MongoDB中的cappedcollection模式的表business_snap中，同时清除快照内容缓存。

应用进程在服务执行结束时，将打包的快照信息调用写入操作，将数据写入到MongoDB的business_snap表中。

步骤710：快照管理模块处理business_snap，并且进行统计分析，形成聚合文档数据。

快照管理模块处理business_snap，并且进行统计分析，形成聚合文档数据，方便查询服务进行查询，该模块根据具体需求可以进行扩展，支撑各类统计服务，如数据库操作情况、操作分布情况，在Web前台可以方便形成柱状图、饼图等等。

可以看出，本发明实施例1与现有技术相比，具有如下优点：

实现业务受理快照信息的统一查询和集中展现，可以展现出数据变更的顺序和变更发起请求来源，实现对业务场景数据进行追溯，为故障的定位提供了清晰的路线；

将部分需要从核心数据库上进行统计的分析的报表，迁移到快照管理系统中，如表的变更频率，操作的时段分布等等，减少了核心数据库的压力，同时降低了成本；

使用MongoDB分布式数据库作为业务信息快照存储数据库，减少业务支撑系统的oracle数据库的使用，支持低成本的PC Server，有效的降低了投资成本；

使用MongoDB的Tailable Cursors特性，实现备份信息的高效处理，忙闲均匀。

上述各单元可以由电子设备中的中央处理器(Central Processing Unit，CPU)、数字信号处理器(Digital Signal Processor，DSP)或可编程逻辑阵列(Field－Programmable Gate Array，FPGA)实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (10)

1.一种快照信息处理方法，其特征在于，该方法包括：

根据配置修改请求，修改快照采集配置信息，其中，所述快照采集配置信息以业务请求功能代码、模块标识和模块快照点为关键字进行存储；

获取快照采集配置信息；

根据所述快照采集配置信息进行快照信息采集；

将采集的快照信息写入数据库，所述数据库为基于分布式文件存储的数据库。

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

对数据库中存储的快照信息进行分析，获取并保存分析结果。

3.根据权利要求2所述的方法，其特征在于，所述分析结果包括以下一项或多项：表更新概率、表操作时段分布情况、业务操作时段分布情况、业务受理数据库占用时长。

4.根据权利要求1至3任一项所述的方法，其特征在于，该方法还包括：

获取信息查询请求；

根据所述信息查询请求，获取相应的快照信息或分析结果，并返回。

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

获取配置修改请求。

6.一种快照信息处理装置，其特征在于，该装置包括：快照采集配置模块、快照信息采集模块和数据库；其中，

所述快照采集配置模块，用于进行快照采集信息配置；

所述快照信息采集模块，用于获取快照采集配置信息，并根据所述快照采集配置信息进行快照信息采集；以及将采集的快照信息写入数据库；

所述数据库，为基于分布式文件存储的数据库，用于存储快照信息；

其中，所述快照采集配置模块，还用于根据所述配置修改请求，修改快照采集配置信息；所述快照采集配置信息以业务请求功能代码、模块标识和模块快照点为关键字进行存储。

7.根据权利要求6所述的装置，其特征在于，该装置还包括快照信息管理模块，

所述快照信息管理模块，用于对数据库中存储的快照信息进行分析，获取分析结果，并将分析结果存储至数据库。

8.根据权利要求6所述的装置，其特征在于，所述快照信息管理模块获取的分析结果包括以下一项或多项：表更新概率、表操作时段分布情况、业务操作时段分布情况、业务受理数据库占用时长。

9.根据权利要求6至8任一项所述的装置，其特征在于，该装置还包括交互模块，

所述交互模块，用于获取信息查询请求；以及展示快照信息管理模块返回的快照信息或分析结果；

所述快照信息管理模块，还用于根据所述信息查询请求，获取相应的快照信息或分析结果，并返回交互模块。

10.根据权利要求9所述的装置，其特征在于，

所述交互模块，还用于获取配置修改请求。