CN101102281A - 移动通信系统中大量数据上报时的数据处理方法 - Google Patents

Abstract

本发明公开了一种移动通信系统中大量数据上报时的数据处理方法，提高系统处理数据的能力。所述方法包括以下步骤：当有消息需要入缓存时，将收到的消息追加到第一级缓存队列的尾部；当第一级缓存队列有数据时，提取第一级缓存队列头部的消息，根据预先设置的分流策略选定处理所述消息的消费者线程所对应的第二级缓存，将所述消息追加到选定的第二级缓存队列尾部；消费者线程从第二级缓存中获取数据并处理。

Description

移动通信系统中大量数据上报时的数据处理方法

技术领域

本发明涉及移动通信系统中的数据处理方法，尤其涉及移动通信系统中大量数据上报时的数据处理方法。

背景技术

移动通讯系统存在大量数据上报的情况，例如在移动通讯系统的OMC(操作维护中心)的失败观察，信令跟踪过程中，体现的更显著。一般情况下，系统都采取消息缓存方式，把大量的数据先直接放缓存来减轻数据上报量较大时的处理压力，此方法一般通过生产/消费者模式实现。如图1所示，生产/消费者模式由生产者线程、消费者线程、以及缓存组成，生产者线程把消息放置到缓存，消费者线程从缓存中获取数据进行处理，处理完1条则从缓存中删除1条，直到缓存为空。生产者线程向缓存队列插入数据时，若缓存已满，生产者就直接从缓存中删除1条最旧的数据，插入一条新数据，保证新数据都能放入缓存，目的是让消费者尽最大可能的处理已有数据，同时系统不漏掉1条新数据。

现有技术没有考虑在大量数据上报的情况下(如每秒超过2000条的消息上报)，同时缓冲区也比较大(一般缓存阈值为20000条，而有些系统就没有限制)时，由于新的数据不断由前台上报上来，可能缓存大小始终维持在缓存阈值，缓存被填满后，而消费者线程(消费者线程处理比生产者线程处理能力低1-2个数量级，一般处理消费者处理1条消息的时间，生产者可以追加100条以上的数据)不能及时处理，那么系统会一直由生产者线程执行队列的删除与插入，缓存大小始终在缓存阈值附近震荡，这样占用了大量的CPU处理时间；同时消费者线程也在执行队列的删除，多个线程的并发删除可能会和插入等操作同时发生，使系统在同步上的开销很大。数据量非常大时，系统还需要耗费很多的CPU时间，来不停更新缓存。但是一般消费者线程只能处理缓存队列内10％左右的数据，这会使原本保留的新数据丢失，而消费者得到的也仅是支离破碎的片断信息。由于对同一个队列的并发操作常常产生死锁，或意外破坏了程序的处理逻辑，会发生客户端频繁显示同1条消息的现象，更有甚者，导致程序直接异常退出，或CPU长期占用100％机器没有反应。特别是若缓存的处理同时涉及对同一张表的同步读、写、删除或插入(例如信令跟踪的上报数据是直接先入数据库的，若上报数据单任务超过数据容量阈值，就会产生上面的并发冲突，这样常规意义上的内存块缓存在这里就是数据库中的表了)，会导致消费者线程获取不到表锁，而来不急对数据进行分析处理，最后导致应用程序反应很慢，极限情况下可能需要10分钟之后才有响应。程序没有把处理能力放在对上报数据的分析和呈现上，而是在进行没有意义的队列更新。

对于消息队列缓存的处理，通常的作法是先删除原有的，再插入；在数据量很大时，线程一直处于工作态，CPU大量占用，实际上数据也没有处理多少，数据才入缓存又立即被删除，CPU处理能力主要耗费在每秒千次以上的缓存的频繁插入删除处理上，而且删除与插入是对同一资源的并发处理，会导致死锁，或者由于线程间的同步，影响了正常的处理。

问题的根源在于常规的消息处理机制，也就是目前普遍使用的如图1至3所示的方案，对存储区同时进行删除与插入的并不做处理，因为对表的删除操作时自然就获取了数据库中的表的行锁(排他锁)，插入操作对应新的行，不会产生资源冲突现象。在系统处理的数据量不太大的情况下上述方案的效果还可以，但是在系统处理的数据量很大的极限情况下，处理效果很差。执行数据删除同时，由于数据量大，删除过程会很耗时间，而且由于新数据的上报，数据会入库，对于部分特别的情况需要用到二次解码，客户端需要在跟踪上报解析时每条上报数据都会访问一次数据库，若删除时继续插入，会导致存在同一张表并发的异常频繁的插入、删除、查询，导致删除不能及时完成，同时插入也不能及时插入，由于客户端无法及时的执行二次解码导致客户端无响应或出现异常，由于信令跟踪任务一般各个客户端会同时发起总数可达到40个以上，这种情况会更突出。外在现象是CPU占用率很高，但是系统处理数据的能力却很弱，且可能伴随系统死机、异常退出。常规消息处理机制中都想最大限度的处理上报数据，但是机器的处理能力是有限制的，在极限情况下，需采取其它措施。

发明内容

本发明要解决的技术问题是提供一种移动通信系统中大量数据上报时的数据处理方法，提高系统处理数据的能力。

为了解决上述问题，本发明提供了一种移动通信系统中大量数据上报时的数据处理方法，设置两级缓存，包括以下步骤：

当有消息需要入缓存时，将收到的消息追加到第一级缓存队列的尾部；

当第一级缓存队列有数据时，提取第一级缓存队列头部的消息，根据预先设置的分流策略选定处理所述消息的消费者线程所对应的第二级缓存，将所述消息追加到选定的第二级缓存队列尾部；

消费者线程从第二级缓存中获取数据并处理。

进一步地，当有消息需要入缓存时，先判断第一级缓存的数据量是否超过预设的阈值，如果是，则将第一级缓存中的数据全部删除后，再将所述消息追加到第一级缓存队列的尾部，否则直接将收到的消息追加到第一级缓存队列的尾部。

进一步地，删除第一级缓存中数据时，暂停消息的加入，将此时收到的消息直接丢弃。

进一步地，所述分流策略是指将消息分类的策略。

进一步地，根据以下参数任意之一对消息进行分类：消息来源、消息类型、消息大小。

进一步地，在选定第二级缓存后，判断所述第二级缓存中的数据量是否超过预设的阈值，如果是，则不处理，否则，将所述消息追加到选定的第二级缓存队列尾部。

进一步地，所述不处理是指将从第一级缓存队列提取的消息直接丢弃。

进一步地，消费者线程从第二级缓存队列头获取数据，同时将所述数据从第二级缓存队列中删除。

采用本发明的方法后，通过对数据的分流处理和并发规避，在上报的数据量很大时，系统也能最大限度的处理重要的前台上报信息，清理积压的缓存数据，在充分利用系统内存优势的情况下，提高了系统的处理能力。

附图说明

图1是现有技术中移动通信系统下网管应用的消息处理机制；

图2是图1中生产者线程将数据入缓存的示意图；

图3是图1中消费者线程从缓存中取数据的示意图；

图4是本实施例中大量数据上报的分流处理示意图；

图5是本实施例中数据上报时一级缓存的处理流程图；

图6是本实施例中二级缓存分流处理流程图；

图7是本实施例中消费者线程处理数据流程图。

具体实施方式

为了让系统在极限情况下也能最大限度的处理重要的前台上报信息，对于来不及处理的消息直接丢弃不入缓存，采用以分级别的缓存和多消费者机制实现负荷分担进行积压清理，并有效的进行冲突规避。对各类不同的上报，分不同线程处理，各个线程有独立的消息队列，通过主线程派发到各个工作线程中，通过多流水和2级缓冲，在充分利用系统内存优势的情况下，扩大了系统的处理能力，最大限度的处理上报消息。同时为了体现对重要级别不同的消息的分别对待，提出第2级缓存可以对消息队列的长度做控制，对于重要的，可以把消息队列最大长度设置长些，提高负荷能力。

对于一定流量的前台(运行移动通讯业务的单板)消息上报，后台(操作维护这些移动通讯业务的单板的系统)采用队列方式缓存，虽然上报消息的上报结构不同，但是都有明确的消息来源，系统可根据不同消息来源信息定位到具体的消息类型，例如在失败观察中，我们把消息按消息上报结构，相同的分为相同的消息类型，每种消息类型上上报消息由单独的线程处理在单独的界面上解析、呈现。然后由消息分类派发过程来区分各类不同的上报，分不同消费者线程处理，各个消费者线程有独立的消息队列，通过主线程派发到各个消费者线程中，用空间换取时间，使系统能最大限度的处理上报消息。

数据上报速度过快的情况(例如在开局，或大话务环境下，常常会发生1秒上报2000条以上消息过程)下，界面的刷新已经没有意义，可以暂停界面刷新，并将上报信息处理后放入保存队列，队列满时才写入文件。暂停界面刷新是指客户端对前台上报数据不在界面上显示，对于每秒2000条左右的上报数据，即使界面显示用户也看不过来，另外大量占用CPU资源，而且，如果显示的不及时，则会对前台、后台的消息缓存带来比较大的负荷。上报数据历史文件滚动默认维持10个(可配置系统能支持的数据文件最大总数)。同时若处理负荷超过额定能力，也就是缓冲区满，但是后台没有处理的情况下，首先依赖第二级缓存优势，进行负荷分担；若负荷分担仍然解决不了问题，启动第二级缓存的保护机制，对于部分新消息直接丢弃，因为消息量过大不丢弃，仍然会导致消息阻塞，新的消息不能处理。为保证信息的完整性对二级缓存并不丢弃旧数据，而是让处理线程尽可能的处理完队列中已有的消息，当缓存中的消息被处理几条后，派发线程就可以再追加最新的上报消息到队列尾部，实际效果是系统能更快的得到最新的上报。若二级缓存的保护还不能缓解消息在一级缓存中的积压，系统启动第一级缓存的保护，当第一级缓存容量超过阈值时，系统采取清除当前缓存中全部数据的机制，保证新的数据能及时接收并进行分发，清理完毕一级缓存后恢复对数据的接收。对于清理操作而言，由于主要是内存操作，处理周期应该在5-10毫秒。通过多流水和2级缓存实现负荷分担，如图4所示。

在一级缓存处理时，经常遇到不可避免的数据的同时删除与插入，可采用下面办法规避：删除数据时，暂停数据的插入，对于这些数据直接丢弃。例如在信令跟踪中，上报数据需要入库，但是给每个任务分配的表空间是有限的，每任务满一定记录数就要删除，但是删除时同时也存在大量数据上报，这样就存在同步处理，导致系统有处理能力，但是不能发挥出来，同时CPU占有率增大。

图5所示为数据上报时一级缓存的处理流程，包括以下步骤：

步骤501，网元底层通讯模块收到消息，说明有消息需要入缓存；

步骤502，判断一级缓存的数据量是否超过设定的阈值门限，如果是，执行下一步，否则，将消息追加到一级缓存队列的尾部；

步骤503，将一级缓存中的数据全部删除；

当删除数据时，暂停数据的插入，对于这些数据直接丢弃。

步骤504，将通讯模块接收到的消息追加到一级缓存的尾部。

根据消息类型将一级缓存中的消息分派到不同的二级缓存中；

图6所示为二级业务处理流程，只要一级缓存队列头部有数据，就执行以下步骤：

步骤601，提取一级缓存中的消息；

根据消息类型准备将一级缓存中的消息分派到对应的二级缓存中。

步骤602，根据提取的消息类型，判断处理该消息的消费者线程对应的二级缓存中的数据量是否超过设定的阈值门限，如果是，则不处理(直接丢弃不存入二级缓存)，否则，执行下一步；

二级缓存的分流策略根据需要确定，除了根据消息类型将消息分类外，，还可采用消息来源、大小等参数进行分类，只要能区分不同消费者线程处理的消息类型即可。

步骤603，将消息追加到对应二级缓存的队列尾部。

为了体现对重要级别不同的消息的不同处理，可以在多个二级的缓存中设置消息队列的长度，对于较重要的某个二级缓存，可以设置较长的消息队列长度。

图7为消费者线程处理数据流程，消费者线程处理数据时，从二级缓存获取数据并处理，同时将二级缓存队列头中的数据删除。

在应用实施例中，在信令跟踪在消息上报过程中，消息也同时入库(插入数据库的信令跟踪信息表中)，消息的缓存机制采用本实施例的方案，同时信令跟踪信息表的维护采用一级缓存的处理原则来处理，信令跟踪信息表对每个任务设置的只允许最多保存20000条记录，超过20000条后新的消息自动删除。由于信令跟踪并发任务数最大100个，总的阈值门限就是任务数阈值即消费者线程个数和任务缓存阈值即每个消费者线程对应的缓存大小的乘积。其中，删除数据时采用与1级缓存相同的保护机制，暂停数据的插入，对于这些数据直接丢弃，删除完毕，继续对数据的插入。采用本方案后，进高了信令跟踪的处理能力，客户也能接受。

本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明做出各种相应的改变和变形，这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (8)

1、一种移动通信系统中大量数据上报时的数据处理方法，其特征在于，设置两级缓存，包括以下步骤：

当有消息需要入缓存时，将收到的消息追加到第一级缓存队列的尾部；

当第一级缓存队列有数据时，提取第一级缓存队列头部的消息，根据预先设置的分流策略选定处理所述消息的消费者线程所对应的第二级缓存，将所述消息追加到选定的第二级缓存队列尾部；

消费者线程从第二级缓存中获取数据并处理。

2、如权利要求1所述的方法，其特征在于，当有消息需要入缓存时，先判断第一级缓存的数据量是否超过预设的阈值，如果是，则将第一级缓存中的数据全部删除后，再将所述消息追加到第一级缓存队列的尾部，否则直接将收到的消息追加到第一级缓存队列的尾部。

3、如权利要求2所述的方法，其特征在于，删除第一级缓存中数据时，暂停消息的加入，将此时收到的消息直接丢弃。

4、如权利要求1所述的方法，其特征在于，所述分流策略是指将消息分类的策略。

5、如权利要求4所述的方法，其特征在于，根据以下参数任意之一对消息进行分类：消息来源、消息类型、消息大小。

6、如权利要求1所述的方法，其特征在于，在选定第二级缓存后，判断所述第二级缓存中的数据量是否超过预设的阈值，如果是，则不处理，否则，将所述消息追加到选定的第二级缓存队列尾部。

7、如权利要求6所述的方法，其特征在于，所述不处理是指将从第一级缓存队列提取的消息直接丢弃。

8、如权利要求1所述的方法，其特征在于，消费者线程从第二级缓存队列头获取数据，同时将所述数据从第二级缓存队列中删除。

Images