[发明专利]移动通信系统中大量数据上报时的数据处理方法

说明书

技术领域

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

背景技术

移动通讯系统存在大量数据上报的情况，例如在移动通讯系统的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占用率很高，但是系统处理数据的能力却很弱，且可能伴随系统死机、异常退出。常规消息处理机制中都想最大限度的处理上报数据，但是机器的处理能力是有限制的，在极限情况下，需采取其它措施。

发明内容

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

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

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