CN101646140A - 消息日志处理方法和系统 - Google Patents
消息日志处理方法和系统 Download PDFInfo
- Publication number
- CN101646140A CN101646140A CN200810144483A CN200810144483A CN101646140A CN 101646140 A CN101646140 A CN 101646140A CN 200810144483 A CN200810144483 A CN 200810144483A CN 200810144483 A CN200810144483 A CN 200810144483A CN 101646140 A CN101646140 A CN 101646140A
- Authority
- CN
- China
- Prior art keywords
- message
- database
- former
- memory
- unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明提供了一种消息日志处理方法和系统,该系统包括接收单元、处理单元及数据库,其中接收单元用于接收业务处理系统转发的消息,包括原消息和关联消息;判断单元用于判断接收单元接收的消息是原消息还是关联消息,若为关联消息则通知缓存管理单元,若为原消息则缓存入缓存单元;缓存单元用于缓存接收单元接收的原消息;缓存管理单元用于接收判断单元的通知,根据关联消息更新对应原消息的信息,并发送更新后的消息到所述处理单元,同时删除缓存单元中的该消息;处理单元用于执行数据库操作。本发明方法和系统可以减少数据库操作,提高消息入库效率。
Description
技术领域
本发明方法涉及数据通信领域,具体地说,涉及一种消息日志处理方法和系统。
背景技术
目前,短消息业务已经成为移动数据通信领域中最为成熟的业务。由于短消息业务涉及每一个移动用户,因此随着今年移动用户的不断增长以及用户对短消息的使用习惯,短消息业务量也不断增大。涉及短消息业务的设备主要是短信中心和短信网关,为用户提供点对点短消息业务和SP增值短消息业务。对于短消息设备系统,为了便于事后查询统计,必须全面记录短消息日志信息。而由于业务量的猛增,一方面要合理、即时、准确的记录短消息日志信息,另一方面又要尽量减少对系统的业务处理的影响,还要能够方便后续的查询和统计,因此大业务量的短消息日志记录已经成为一个越来越重要的课题。
目前短消息日志记录一般存在两种方式,一种是文件方式,也即把短消息以及对应的状态报告保存到日志文件中。一种是数据库方式,也即把短消息以及对应的状态报告保存到数据库中。
用日志文件方式存在如下缺陷:1)短消息和状态报告由于产生在不同的时刻,因此可能存储在不同的日志文件中,不利于对应原消息的最终状态;2)由于产生了大量的日志文件,不但占用磁盘空间,而且后续查询和统计都要基于这些日志文件来进行分析,不但耗时而且程序实现十分复杂;3)由于每条消息和状态报告都要记录下来,都要与读写磁盘,因此增加了磁盘的IO,占用了大量的系统资源,在一定程度上影响了正常的业务运行;4)日后若需要扩展日志格式,则可能影响原有基于该日志的一些分析处理程序,因此导致扩展性不强。
对于数据库方式,一般是把原消息直接保存到数据库中,消息下发成功后再更新数据库的状态。这种方式存在如下缺陷:1)随着业务量的增加,大大增加了实时数据库的操作,每个短消息业务要做一次插入和一次更新操作,大大增加了系统的负担;2)消息直接保存在业务数据库中,占用业务数据库资源,系统繁忙时严重影响正常业务的运行;3)消息日志全部记录到一个数据表中,导致数据量巨大,影响后续分析效率以及对消息日志的维护。
目前尚未发现有公开的文献介绍短消息系统的日志记录的方法。
发明内容
本发明要解决的技术问题是提供一种消息日志处理方法和系统,以减少数据库操作,提高消息入库效率。
为了解决上述问题,本发明提供了一种消息日志处理方法,该方法由消息日志处理系统实现,该方法包括以下步骤:
(a)业务处理系统将原消息或关联消息转发给消息日志处理系统;
(b)消息日志处理系统接收并判断消息是原消息还是关联消息,若是原消息则缓存该原消息到内存中等待状态报告,若是关联消息,则执行步骤(c);
(c)消息日志处理系统根据关联消息更新内存中的对应原消息信息,并插入数据库。
进一步地,所述消息日志处理系统定时检查缓存中的原消息是否超过预设的暂存有效期,若超过,则将原消息插入数据库,步骤(c)中,消息日志处理系统先检查内存中是否有与关联消息对应的原消息,有则更新后,插入数据库,否则直接到数据库中更新原消息。
进一步地,缓存原消息前,判断该消息流程是否结束,若流程结束则直接插入数据库,否则缓存该原短消息。
进一步地,在对数据库进行插入或更新操作前,待插入或更新的消息先存入批量存储区,当缓存为满或到达预设时间时再执行批量插入或更新操作。
进一步地,所述数据库和批量存储区采用按天分表进行数据存储。
为解决上述技术问题,本发明还提供了一种消息日志处理系统,该系统包括接收单元、处理单元及数据库,其中:
接收单元用于接收业务处理系统转发的消息,包括原消息和关联消息;
判断单元用于判断接收单元接收的消息是原消息还是关联消息,若为关联消息则通知缓存管理单元;若为原消息则缓存入缓存单元;
缓存单元用于缓存接收单元接收的原消息;
缓存管理单元用于接收判断单元的通知,根据关联消息更新对应原消息的信息,并发送更新后的消息到所述处理单元,同时删除缓存单元中的该消息;
处理单元用于执行数据库操作。
进一步地,所述缓存管理单元,还用于定时检查缓存单元存储的消息是否超过预设的暂存有效期,若超过,则送入处理单元进行处理,所述判断单元判断接收单元接收的状态报告在缓存单元中没有对应的原消息,则直接发送到处理单元。
进一步地,所述判断单元判断接收单元接收的消息是原消息时,还用于判断该消息流程是否结束,若流程结束则直接送入处理单元,否则缓存该原消息。
进一步地,所述处理单元包括批量存储模块和批量处理模块,其中批量存储模块用于批量存储需要更新或插入数据库的消息,所述批量处理模块用于判断批量存储模块存储为满或到达预设时间时,将批量存储模块存储的消息批量插入或更新到数据库。
进一步地,所述批量存储模块包括批量更新存储区和批量插入存储区,其中,批量更新存储区用于存储在缓存单元中没有找到对应原消息的关联消息;批量插入存储区,用于存储已根据状态消息更新过状态的消息。
进一步地,所述数据库独立于业务处理系统访问的数据库,且所述数据库和批量存储区采用按天分表进行数据存储。
本发明系统和方法对需要记录的、且具有关联消息的消息进行缓存处理,尤其对于短消息的日志处理,采用内存缓存技术来等待状态报告,一个短消息业务仅需要做一次数据库插入操作即可完成,从而大大减少了数据库更新操作,提高消息入库效率。
另外,本发明利用专门的日志服务器完成短消息日志的记录工作,并存储在日志服务器上的专门的数据库中,该方法实现了与业务数据库的分离,不管是在实时入库还是后续查询统计都大大减少了对正常业务运行的影响。同时,消息日志处理系统在做数据库插入和更新操作时均采用批量入库方式,极大的提高了数据库操作的效率,使得日志服务器在最小配置的情况下可以支撑业务系统的大业务量的消息入库。日志服务器的消息库采用按天分表的方式,可以保证每张表的数据量不会很大,可以提高后续消息查询和统计的效率,也便于后续对消息表的维护。
附图说明
图1是独立日志服务器与业务服务器的结构示意图。
图2是本发明消息日志处理方法的流程图。
图3是本发明消息日志处理系统的结构框图。
具体实施方式
如图1所示,本发明日志服务器,独立于业务服务器之外,该日志服务器包括消息日志处理系统和日志数据库,该消息日志处理系统通过实时消息接收业务处理系统的消息日志数据流,该日志数据库与业务服务器的业务数据库相分离,实现对日志的记录,同时支持查询、统计、分析等数据库操作,且不会影响业务数据库的操作和业务。
以上所说的业务服务器包括业务处理系统和业务数据库,以短信网关为例,网关的主要功能是接收消息并转发给下级网元,因此业务处理系统就是指处理短消息业务转发的服务器或进程。业务处理系统主要是接收消息、路由并转发,同时根据转发结果产生计费话单。
本发明消息日志处理方法包括以下步骤:
A业务处理系统将原消息或关联消息转发给消息消息日志处理系统;
B消息消息日志处理系统接收并判断消息是原消息还是关联消息,若是原消息则缓存该原消息到内存中等待状态报告,若是关联消息,则执行步骤C;
C消息消息日志处理系统根据关联消息更新内存中的对应原消息信息,并插入数据库。
具体应用到短消息系统,原消息指原短消息,关联消息指短消息的状态报告,根据实际的现网设备经验,95%的状态报告一般会在5分钟之内返回,因此本发明系统先把原短消息缓存到内存中等待状态报告,若状态报告在5分钟之内返回则系统直接更新内存状态并进行入库操作,该方法可以减少90%的数据库更新操作,仅做一次插入即可。若状态报告超过5分钟未返回,则在中处理入库,一方面减少对内存的占用,另外一方面提高入库的及时性,便于用户查询消息状态。并且等待状态报告的时间应该是可以灵活设置的,用户可以根据自身网络情况进行调整。
另外,为了提高数据库执行插入和更新操作的效率,采用批量插入和批量更新的方式,其效率可以提高至少一个数量级。
下面将结合附图,详细说明本发明方法的具体流程。
本发明实现的消息日志处理方法参见图2所示,一条短消息业务分为两个流程,一是收到原用户提交的短消息并转发给目的用户流程,一是用户成功接收后产生的状态报告流程,该状态报告能够明确标识前一条消息下发给用户是否成功,若失败是何原因等。因此,对于短消息的日志记录也包含这两个步骤。而对于一条消息的日志记录在本发明中涉及两个实体,一是业务处理系统在处理业务过程中应该把消息转发给消息消息日志处理系统便于后者处理和记录日志,一是消息消息日志处理系统接收业务处理系统转发的消息,并经过处理后进行入库操作。下面业务处理系统和消息消息日志处理系统的处理流程进行描述:
步骤201:业务处理系统把原短消息以及状态报告转发给消息消息日志处理系统,业务处理系统在如下情况下需要给消息消息日志处理系统转发消息:
(1)被业务处理系统直接拒绝了的消息,该消息不会有状态报告,流程结束;
(2)消息转发失败的消息,包括最终重试失败,旁路流程失败的如预付费扣费流程等,被下级网元拒绝以及其他内部原因造成的没有转发成功的情况,这种情况下不会有状态报告,流程结束;
(3)转发下级网元成攻且不需要等待状态报告的消息,比如用户发起到SP的MO业务流程无需等待状态报告,该消息流程直接结束;
(4)转发下级网元成功且需要等待状态报告的消息,这种情况下日志服务器不能直接入库需要等待状态报告;
(5)接收到下级网元返回的状态报告,消息消息日志处理系统要据此更新内存或数据库中的数据;
(6)系统定时处理那些超期没有返回状态报告的消息也要转发给消息消息日志处理系统,用于更新原有数据。
步骤202:消息消息日志处理系统收到消息后,首先判断该消息是原短消息还是状态报告,若是原短消息则执行步骤203,若是状态报告则跳转到步骤206;
步骤203:判断该原短消息的流程是否已经结束,也即是否还需要等待状态报告,若流程已经结束则执行步骤209,若流程未结束,则执行步骤204;
步骤204:流程未结束表示需要等待状态报告,将该原消息加入到内存缓存队列中;
步骤205:系统定时检查内存缓存队列是否有消息超过预先设置的消息暂存有效期,如5分钟,如过期,则执行步骤208;
步骤206:在内存中查找与该状态报告对应的原短消息,若查找到原消息,则执行步骤207,若在内存中没有查找到,说明消息已经超期并存入了数据库中,执行步骤208;
步骤207:根据状态报告更新原短消息的消息状态;
步骤208:从内存缓存队列中删除,同时执行步骤209:
步骤209:把消息插入到当天的批量插入队列中;
步骤210:把状态报告消息插入到原短消息那天(状态报告有可能不是当天的,状态报告可能延迟最长48小时返回)的批量更新队列中;
批量入库队列分为批量插入队列和批量更新队列,这两类队列再按天分子队列,与日志按天的表一一对应,这种队列的分配方法可以最大可能的提高入库的效率。
步骤211:批量入库任务定时扫描所有的入库队列,若某队列满或即使队列没有满但是已经达到一定的时间则对该队列执行批量入库操作,完成最终的入库动作。
日志数据库的日志表采用按天分表的方式,根据原短消息的接收时间来确定插入哪天的表中,收到状态报告后也是直接更新这个表中的对应原短消息状态。
通过上述流程的分析,可以看出基于独立日志系统的短消息日志记录方法,分离了业务数据库和日志数据库,减少了对业务正常运行的影响,减少数据更新操作以及批量入库的方式提高了入库效率,控制内存缓存有效期达到了入库效率与入库及时性的合理平衡,按天分表的日志记录方式不但有利于入库效率的提高,也更有利于后期的查询、分析、统计以及维护。
为了实现以上方法,本发明的消息日志处理系统与业务处理系统采用实时消息的方式通信,如图3所示,该系统包括接收单元、判断单元、缓存单元、缓存管理单元及处理单元,其中,
接收单元用于通过实时消息接收业务处理系统转发的消息,包括原消息和状态报告(关联消息);
判断单元用于对接收单元接收的消息进行判断,包括判断该消息是原消息还是状态报告,若为状态报告则进一步判断缓存单元是否有该状态报告对应的原短消息,若有,则通知缓存管理单元,否则通知处理单元进行处理;若为原消息则进一步判断该消息是否还有后续关联消息(即该消息流程是否结束),若有则缓存入缓存单元,否则发送到处理单元,以执行插入数据库操作;
缓存单元用于缓存接收单元接收的消息,缓存单元以缓存队列的形式存储接收的消息。
缓存管理单元用于接收判断单元的通知,根据状态报告更新对应原短消息的状态信息,并发送到处理单元,同时删除缓存单元中的该消息;检查缓存单元中存储的消息是否过期,若已过期则将缓存单元中的该消息发送到处理单元;
检查缓存单元中存储的消息是否过期,可以预先设置收到原消息直至收到状态消息的等待时间,
根据实际的现网设备经验,95%的状态报告一般会在5分钟之内返回,因此本发明系统先把原短消息缓存到内存中等待状态报告,若状态报告在5分钟之内返回则系统直接更新内存状态并进行入库操作,该方法可以减少90%的数据库更新操作,仅做一次插入即可。若状态报告超过5分钟未返回,则直接处理入库,一方面减少对内存的占用,另外一方面提高入库的及时性,便于用户查询消息状态。并且等待状态报告的时间应该是可以灵活设置的,用户可以根据自身网络情况进行调整。
处理单元用于执行插入或更新数据的操作,该处理单元包括批量存储模块和批量处理模块,其中,
批量存储模块用于批量存储需要更新或插入数据库的消息,批量存储单元包括批量更新存储区和批量插入存储区,其中,批量更新存储区用于存储在缓存单元中没有找到对应原短消息的状态报告消息;批量插入存储区,用于存储已根据状态报告消息更新过状态的消息;
批量存储区直接采用最简单的队列,作为一个暂存队列,等消息累积到一定量再批量的一次入库来提高处理效率。
批量处理模块用于检测批量存储单元是否符合批量处理条件,若符合则将批量存储单元中的消息批量更新或插入数据库;
批量处理涉及数据库的插入和更新操作,为了提高数据库执行效率,均采用数据库提供的批量插入和批量更新的方式来执行,其效率可以提高至少一个数量级。
本发明系统和方法对需要记录的、且具有关联消息的消息进行缓存处理,尤其对于短消息的日志处理,采用内存缓存技术来等待状态报告,一个短消息业务仅需要做一次数据库插入操作即可完成,从而大大减少了数据库更新操作。
另外,本发明利用专门的日志服务器完成短消息日志的记录工作,并存储在日志服务器上的专门的数据库中,该方法实现了与业务数据库的分离,不管是在实时入库还是后续查询统计都大大减少了对正常业务运行的影响。该方案对于核心的业务系统来说只是异步的把消息发送给消息日志处理系统进行记录,对于业务系统来说负荷很轻,相比一般的日志文件记录或直接入库方式,该方法对业务系统来说负荷是最小的。同时,消息日志处理系统在做数据库插入和更新操作时均采用批量入库方式,极大的提高了数据库操作的效率,使得日志服务器在最小配置的情况下可以支撑业务系统的大业务量的消息入库。日志服务器的消息库采用按天分表的方式,可以保证每张表的数据量不会很大,可以提高后续消息查询和统计的效率,也便于后续对消息表的维护,比如删除过期的数据时只需要删除过期表即可,效率非常高,对数据库的影响很小。由此可见,基于独立日志系统的短消息日志记录方法是一种全新的更为先进合理的方法,特别是在大业务量的短消息系统中体现尤为显著。
本发明方法和系统日志记录达到如下目标:1)优化入库程序,减少数据库操作,提高消息入库效率;2)避免对业务数据库的访问,从而减少对正常业务的影响;3)尽可能减少入库周期,提高入库及时性,便于用户即时查询统计;4)在系统繁忙以及业务量大时不但要能够正常记录消息日志,还要能够正常运行系统业务;5)记录的日志应该便于后期的查询、分析、统计以及维护等。
应当理解的是,上述针对短消息日志记录的各具体步骤的实现流程较为具体,并不能因此而认为是对本发明的专利保护范围的限制。本领域技术人员在不脱离上述技术构思的情况下所做的所有改变或替换,都应属于本发明专利请求保护的范围之内。
Claims (11)
1、一种消息日志处理方法,该方法由消息日志处理系统实现,其特征在于,该方法包括以下步骤:
(a)业务处理系统将原消息或关联消息转发给消息日志处理系统;
(b)消息日志处理系统接收并判断消息是原消息还是关联消息,若是原消息则缓存该原消息到内存中等待状态报告,若是关联消息,则执行步骤(c);
(c)消息日志处理系统根据关联消息更新内存中的对应原消息信息,并插入数据库。
2、如权利要求1所述的方法,其特征在于:所述消息日志处理系统定时检查缓存中的原消息是否超过预设的暂存有效期,若超过,则将原消息插入数据库,步骤(c)中,消息日志处理系统先检查内存中是否有与关联消息对应的原消息,有则更新后,插入数据库,否则直接到数据库中更新原消息。
3、如权利要求1所述的方法,其特征在于,步骤(b)中,缓存原消息前,判断该消息流程是否结束,若流程结束则直接插入数据库,否则缓存该原短消息。
4、如权利要求1至3中任一项所述的方法,其特征在于,在对数据库进行插入或更新操作前,待插入或更新的消息先存入批量存储区,当缓存为满或到达预设时间时再执行批量插入或更新操作。
5、如权利要求1至3中任一项所述的方法,其特征在于,所述数据库和批量存储区采用按天分表进行数据存储。
6、一种消息日志处理系统,其特征在于,该系统包括接收单元、处理单元及数据库,其中:
接收单元用于接收业务处理系统转发的消息,包括原消息和关联消息;
判断单元用于判断接收单元接收的消息是原消息还是关联消息,若为关联消息则通知缓存管理单元;若为原消息则缓存入缓存单元;
缓存单元用于缓存接收单元接收的原消息;
缓存管理单元用于接收判断单元的通知,根据关联消息更新对应原消息的信息,并发送更新后的消息到所述处理单元,同时删除缓存单元中的该消息;
处理单元用于执行数据库的操作。
7、如权利要求6所述的系统,其特征在于,所述缓存管理单元,还用于定时检查缓存单元存储的消息是否超过预设的暂存有效期,若超过,则送入处理单元进行处理,所述判断单元判断接收单元接收的状态报告在缓存单元中没有对应的原消息,则直接发送到处理单元。
8、如权利要求6所述的系统,其特征在于,所述判断单元判断接收单元接收的消息是原消息时,还用于判断该消息流程是否结束,若流程结束则直接送入处理单元,否则缓存该原消息。
9、如权利要求6至8中任一项所述的系统,其特征在于,所述处理单元包括批量存储模块和批量处理模块,其中批量存储模块用于批量存储需要更新或插入数据库的消息,所述批量处理模块用于判断批量存储模块存储为满或到达预设时间时,将批量存储模块存储的消息批量插入或更新到数据库。
10、如权利要求9所述的系统,其特征在于,所述批量存储模块包括批量更新存储区和批量插入存储区,其中,批量更新存储区用于存储在缓存单元中没有找到对应原消息的关联消息;批量插入存储区,用于存储已根据状态消息更新过状态的消息。
11、如权利要求6至8中任一项所述的系统,其特征在于,所述数据库独立于业务处理系统访问的数据库,且所述数据库和批量存储区采用按天分表进行数据存储。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2008101444837A CN101646140B (zh) | 2008-08-05 | 2008-08-05 | 消息日志处理方法和系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2008101444837A CN101646140B (zh) | 2008-08-05 | 2008-08-05 | 消息日志处理方法和系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101646140A true CN101646140A (zh) | 2010-02-10 |
CN101646140B CN101646140B (zh) | 2012-05-09 |
Family
ID=41657807
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2008101444837A Expired - Fee Related CN101646140B (zh) | 2008-08-05 | 2008-08-05 | 消息日志处理方法和系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101646140B (zh) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102110167A (zh) * | 2011-03-01 | 2011-06-29 | 上海奈凯电子科技有限公司 | 数控系统中实现日志信息管理的方法 |
CN102195786A (zh) * | 2010-03-16 | 2011-09-21 | 中国电信股份有限公司 | 智能数据交换平台及方法 |
CN103188297A (zh) * | 2011-12-29 | 2013-07-03 | 北大方正集团有限公司 | 一种消息存储和获取方法及系统 |
CN104572105A (zh) * | 2015-01-07 | 2015-04-29 | 广东欧珀移动通信有限公司 | 数据更新方法及装置 |
CN105183920A (zh) * | 2015-10-20 | 2015-12-23 | 广东欧珀移动通信有限公司 | 播放列表信息处理方法及装置 |
CN105653564A (zh) * | 2014-12-03 | 2016-06-08 | Tcl集团股份有限公司 | 一种短信投票系统的数据库阻塞处理方法及装置 |
CN107870850A (zh) * | 2017-08-25 | 2018-04-03 | 成都萌想科技有限责任公司 | 一种高效的互联网应用日志系统 |
CN110727689A (zh) * | 2019-09-09 | 2020-01-24 | 杭州玖欣物联科技有限公司 | 一种合并设备状态信息的方法 |
CN114641034A (zh) * | 2022-05-09 | 2022-06-17 | 上海大汉三通通信股份有限公司 | 一种基于5g消息系统的下行信息处理方法及相关组件 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100440795C (zh) * | 2004-01-05 | 2008-12-03 | 华为技术有限公司 | 一种系统日志实现方法和装置 |
CN100596353C (zh) * | 2006-12-05 | 2010-03-31 | 阿里巴巴集团控股有限公司 | 提供日志服务的方法及系统 |
CN100521623C (zh) * | 2007-05-22 | 2009-07-29 | 网御神州科技(北京)有限公司 | 高性能的Syslog日志处理和存储方法 |
-
2008
- 2008-08-05 CN CN2008101444837A patent/CN101646140B/zh not_active Expired - Fee Related
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102195786A (zh) * | 2010-03-16 | 2011-09-21 | 中国电信股份有限公司 | 智能数据交换平台及方法 |
CN102195786B (zh) * | 2010-03-16 | 2014-07-23 | 中国电信股份有限公司 | 智能数据交换平台及方法 |
CN102110167B (zh) * | 2011-03-01 | 2013-07-31 | 上海维宏电子科技股份有限公司 | 数控系统中实现日志信息管理的方法 |
CN102110167A (zh) * | 2011-03-01 | 2011-06-29 | 上海奈凯电子科技有限公司 | 数控系统中实现日志信息管理的方法 |
CN103188297B (zh) * | 2011-12-29 | 2016-05-18 | 北大方正集团有限公司 | 一种消息存储和获取方法及系统 |
CN103188297A (zh) * | 2011-12-29 | 2013-07-03 | 北大方正集团有限公司 | 一种消息存储和获取方法及系统 |
CN105653564A (zh) * | 2014-12-03 | 2016-06-08 | Tcl集团股份有限公司 | 一种短信投票系统的数据库阻塞处理方法及装置 |
CN104572105B (zh) * | 2015-01-07 | 2017-10-20 | 广东欧珀移动通信有限公司 | 数据更新方法及装置 |
CN104572105A (zh) * | 2015-01-07 | 2015-04-29 | 广东欧珀移动通信有限公司 | 数据更新方法及装置 |
CN105183920A (zh) * | 2015-10-20 | 2015-12-23 | 广东欧珀移动通信有限公司 | 播放列表信息处理方法及装置 |
CN105183920B (zh) * | 2015-10-20 | 2018-12-11 | 广东欧珀移动通信有限公司 | 播放列表信息处理方法及装置 |
CN107870850A (zh) * | 2017-08-25 | 2018-04-03 | 成都萌想科技有限责任公司 | 一种高效的互联网应用日志系统 |
CN110727689A (zh) * | 2019-09-09 | 2020-01-24 | 杭州玖欣物联科技有限公司 | 一种合并设备状态信息的方法 |
CN114641034A (zh) * | 2022-05-09 | 2022-06-17 | 上海大汉三通通信股份有限公司 | 一种基于5g消息系统的下行信息处理方法及相关组件 |
CN114641034B (zh) * | 2022-05-09 | 2022-08-16 | 上海大汉三通通信股份有限公司 | 一种基于5g消息系统的下行信息处理方法及相关组件 |
Also Published As
Publication number | Publication date |
---|---|
CN101646140B (zh) | 2012-05-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101646140B (zh) | 消息日志处理方法和系统 | |
CN101853287B (zh) | 数据压缩快速检索文件系统及其方法 | |
JP4824753B2 (ja) | 時間制限メッセージの効率的な処理 | |
CN101416183B (zh) | 保存无线设备当前数据的方法和系统 | |
CN101673192B (zh) | 时序化的数据处理方法、装置及系统 | |
CN100478956C (zh) | 生成和获取报表的方法及相应的系统 | |
US20040085980A1 (en) | System and method for maintaining transaction cache consistency in mobile computing environment | |
CN101217571B (zh) | 用于多副本数据网格系统中的写/读文件操作的方法 | |
CN101364217B (zh) | 数据库中数据维护方法、设备及其系统 | |
CN102142024A (zh) | 在分布式数据库中使用递增捕捉来进行逻辑数据备份和回退 | |
JP2009504030A (ja) | 収益管理システムおよび方法 | |
CN101556678A (zh) | 一种批处理业务的处理方法、系统及业务处理控制设备 | |
CN102323940A (zh) | 基于数据库的配置台实现方法、配置台及系统 | |
CN102104617A (zh) | 一种网站运营系统存储海量图片数据的方法 | |
CN109101580A (zh) | 一种基于Redis的热点数据缓存方法和装置 | |
CN105227662A (zh) | 消息处理方法、装置和系统 | |
CN101883111A (zh) | 一种处理在线业务日志的计费服务器及方法 | |
CN1996305A (zh) | 一种数据存储及读取方法及装置以及数据传输系统 | |
CN106649530B (zh) | 云详单查询管理系统及方法 | |
CN103209397A (zh) | 短信发送、接收的控制方法及其服务器和终端 | |
CN102098170A (zh) | 一种数据采集优化方法及系统 | |
CN100558188C (zh) | 消息处理设备、系统及方法 | |
CN101217755B (zh) | 一种用于数据采集的前置机系统和方法 | |
CN103914514A (zh) | 控制业务凭证输出方式的方法及系统 | |
CN117992257B (zh) | 一种分布式数据库并行数据采集处理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20120509 Termination date: 20160805 |
|
CF01 | Termination of patent right due to non-payment of annual fee |