具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅用以解释本发明,并不用于限定本发明。
图1为本发明一种记录日志的方法的一个实施例的流程图,包括:
11,接收记录业务请求相关信息日志的请求。
具体的,日志处理装置接收记录业务请求相关信息日志的请求。业务请求可以是外部系统发起的请求(如开户、订购、呼叫等),也可以是本系统内提供的界面操作发起的请求,也可能是系统内部定时任务等自动触发的请求,由业务处理装置接收后,向日志处理装置发送记录该业务请求相关信息日志的请求。
业务请求相关信息指与该业务请求有关的全部或者部分信息,包括外部系统发送的业务请求参数信息,系统内对该业务请求的处理流程信息,以及处理结果信息。
12,根据该记录业务请求相关信息日志的请求将该业务请求相关信息记录到与该业务请求关联的日志缓存区。
具体的,该日志处理装置收到该记录业务请求相关信息日志的请求,可以根据该业务请求的唯一标识或者业务流水号或者线程变量查找与该业务请求关联的日志缓存区,然后将该业务请求携带的参数信息以及对该业务请求的处理流程信息都记录到该日志缓存区中。这样,该对应的日志缓存区就记录了关于这一个业务请求的参数信息以及该业务请求对应的全部或者部分处理流程信息。以该业务请求为一个开户请求为例,该开户请求在不同的模块会经过多个处理流程,参见图9所示的实施例,这些处理流程信息可以全部或者部分记录到与该开户请求对应的日志缓存区中。为了业务请求记录信息的完整性,日志处理装置可以在业务处理装置完成对该业务请求每一个处理后,接收业务处理装置发送的记录该业务请求处理相关信息日志的请求,并将这些相关信息记录到与该业务请求关联的日志缓存区,具体可以是将业务请求相关信息按照业务请求相关信息发生的先后顺序记录在日志缓存区,如按照处理流程的先后来记录,记录的时候可以同时把该缓存区的唯一标识保存在每一个日志记录中。
13,接收日志输出请求,根据所述日志输出请求将所述业务请求关联的日志缓存区中的业务请求相关信息写入日志文件中。
具体的,业务处理装置在每完成与该业务请求的一次处理后,可以判断处理结果是成功还是失败,判断为失败时,业务处理装置向日志处理装置发出日志输出请求,要求其提交该业务请求对应的缓存区中的日志信息,日志处理装置根据该日志输出请求执行提交操作,把该对应的缓存区中的存储的该业务请求的信息按记录的先后顺序写入日志文件中,以便进行后续的分析,找出业务请求处理失败原因。
在java中提供了很多集合类型的数据结构,比如队列、数组等,可用来实现缓存区中的存储的该业务请求的相关信息按记录的先后顺序输出到日志文件中的功能。图2为本发明实现按记录顺序输出日志的一个实施例的示意图,在图2中,使用java数组的add方法进行增加对象,实现按顺序向日志缓存区增加新的日志信息,并且,在输出日志信息时,利用get(i)方法进行遍历对象操作,在提交日志缓存区中的日志信息时遍历数组中各个日志信息对象,然后逐一输出到日志文件中。
本实施例通过将该业务请求相关信息记录到与该业务请求关联的日志缓存区,当该业务请求处理失败时,根据日志输出请求将该业务请求关联的日志缓存区中的业务请求相关信息写入日志文件中,实现了只输出处理失败的业务请求相关信息,控制了日志的输出量,减少了对磁盘空间和读写资源的占用,并且当业务请求处理失败时,输出有关该业务请求相关信息的全部日志,体现了业务请求与输出日志的关联性,方便结合该业务请求的全部处理流程进行后续分析,快速定位出失败原因。
在本发明实施例中,日志处理装置还可以包括在接收记录业务请求相关信息日志的请求之前,接收包含了业务请求的关联信息的缓存区建立请求,并根据该缓存区建立请求建立与所述业务请求关联的日志缓存区。
该业务请求的关联信息是将该业务请求和日志缓存区对应起来的一个标识。在不同的应用场景下有所不同,可以是一个唯一标识,也可以是两者都对应的线程,还可以是业务请求对应的业务流水号。
该缓存区建立请求可以由业务处理装置在进行业务请求处理前向日志处理装置发送。即业务处理装置收到业务请求后,向日志处理装置发送开始新的日志缓存的请求。具体的,日志处理装置可以通过如下方法建立与该业务请求关联的日志缓存区:
一种方法是:创建一个空的日志缓存区对象,然后将该空的日志缓存区对象与该业务请求建立关联关系。对于关联关系的建立,存在多种方法可以实施。图3为本发明通过线程变量建立与业务请求关联的日志缓存区的一个实施例的示意图;如图3所示,以java语言为例,在java中,一个请求的处理依附在某一个具体的线程上,因此通过java中的线程变量技术,可以将日志缓存区和处理该业务请求相应线程的线程变量建立关联,这样就实现了每一个业务请求都有自己独立的缓存区。
另一种方法是:定义一个唯一标识,业务请求和日志缓存区分别建立和这个唯一标识的关联关系,从而通过这个唯一标识实现业务请求和缓存区的关联。如图4所示,为通过唯一标识将业务请求和日志缓存区进行关联的示意图。这种实施方案对基于消息的处理系统非常适用,因为在消息中可以携带这样的标识,从而在系统的各个地方很容易的获取和使用这个标识。比如业务处理装置在日志处理装置在每次向日志处理装置发送请求时携带这个参数,日志处理装置就可以实现将业务请求和日志缓存区关联,并将该业务请求相关信息记录到与该业务请求关联的日志缓存区中。
当业务请求全部流程处理完毕,并且成功时,日志处理装置还可以根据业务处理装置发送的缓存区回滚请求清除该业务请求关联的日志缓存区中的业务日志信息并删除该业务请求关联的日志缓存区。
业务处理装置在业务请求全部流程处理完毕,并且成功时,向日志处理装置发送缓存区回滚请求,要求其回滚缓存区,日志处理装置收到缓存区回滚请求后,根据该业务请求和缓存区的关联关系信息,找到相应的缓存区,执行回滚操作,即把该缓存区的日志信息清除、删除该缓存区,回收出存储空间。
本实施例中通过建立与每一个业务请求相关联的日志缓存区,为不同的业务请求分别输出提供条件,并且通过在业务请求处理成功时,回滚该业务请求关联的缓存区,及时释放了缓存空间,减少了对存储空间的占用。
图5为本发明一种记录日志的方法的另一个实施例的流程图,包括:
21,发送记录业务请求相关信息的请求,以便日志处理装置根据所述记录业务请求相关信息的请求将业务请求相关信息记录到与所述业务请求关联的日志缓存区;
业务处理装置接收业务请求,然后对该业务请求进行处理,在此过程中,可以多次调用日志处理装置记录该业务请求相关信息,具体为多次向日志处理装置发送记录业务请求相关信息的请求。
该业务请求相关信息可以是业务处理装置多次接收到的,如在不同的处理流程后接收的,每次接收后都会请求日志处理装置记录。日志处理装置收到业务处理装置发出的记录业务请求相关信息的请求后,查找与该业务请求相关信息关联的日志缓存区,将与该业务请求相关信息都记录到与该业务请求关联的日志缓存区。
22,当所述业务请求处理失败时,发送日志输出请求,以便日志处理装置根据所述日志输出请求将所述业务请求关联的日志缓存区中的业务请求相关信息写入日志文件中。
业务处理装置在每完成与该业务请求的一次处理后,都会判断处理结果是成功还是失败,如果判断为处理失败,业务处理装置向日志处理装置发出日志输出请求,要求其提交该业务请求对应的缓存区上的内容。
一般的,业务处理装置有统一的入口和出口作为处理流程开始和结束点,可以在出口处增加处理成功还是失败的判断(如果不止一个出口,则需要在多个出口出都要增加这样的判断)。
对于判断是否处理成功的方法,可以使是利用本函数(有时也称为过程)前面处理步骤的结果和子函数的返回结果进行判断,如果这些结果均是预期的值,则认为是成功的;也可以是利用底层计算机语言的异常机制,看本函数前面处理步骤和子函数是否抛出了异常,如果没有异常,则认为是成功的。
如果业务处理装置判断该业务请求处理失败,业务处理装置则向日志处理装置发出日志输出请求,要求其提交缓存区,日志处理装置根据该日志输出请求执行提交操作,可以把该对应的缓存区中的存储的该业务请求的全部信息按记录的先后顺序写入日志文件中,以便进行后续的分析,找出业务请求处理失败原因。
本实施例中,通过业务处理装置调用日志处理装置将业务请求相关信息缓存到其关联的缓存区,并且在该业务请求处理失败时,调用日志处理装置将该业务请求关联的日志缓存区中的业务请求相关信息写入日志文件中,实现了只输出处理失败的业务请求相关信息,控制了日志的输出量,减少了对磁盘空间和读写资源的占用,并且当业务请求处理失败时,输出有关该业务请求相关信息的全部日志,体现了业务请求与输出日志的关联性,方便结合该业务请求的全部处理流程进行后续分析。
在本发明实施例中,业务处理装置在接收业务请求后,发送记录业务请求相关信息的请求之前,还可以向日志处理装置发送缓存区建立请求,该缓存区建立请求中包含了业务请求;以便所述日志处理装置根据该缓存区建立请求建立与该业务请求关联的日志缓存区。
业务处理装置在收到业务请求后,进行业务请求处理前,向日志处理装置发送缓存区建立请求,请求日志处理装置建立与该业务请求关联的日志缓存区,日志处理装置收到该缓存区建立请求,建立与该业务请求关联的日志缓存区。日志处理装置建立与业务请求关联的日志缓存区的实现方法在上面的实施例中已有详细介绍,在此不再赘述。
当业务请求处理全部流程处理完毕,并且处理成功时,业务处理装置还可以向日志处理装置发送缓存区回滚请求,即调用日志处理装置将该业务请求关联的日志缓存区中的业务请求相关信息清除并删除业务请求关联的日志缓存区。日志处理装置收到缓存区回滚请求后,根据该业务请求和缓存区的关联关系信息,找到相应的缓存区,执行回滚操作,即把缓存区的日志信息清除、删除该缓存区,释放缓存空间。
本实施例中通过业务处理装置调用日志处理装置,建立与每一个业务请求相关联的日志缓存区,为不同的业务请求分别输出提供条件,并且通过在业务请求处理成功时,回滚该业务请求关联的缓存区,及时释放了缓存空间,减少了对存储空间的占用。
图6为本发明一种日志处理装置的一个实施例的结构示意图,具体包括:
接收单元31,用于接收记录业务请求相关信息日志的请求,以及日志输出请求。
具体的,接收单元31提供与业务处理装置的接口,可以根据业务处理装置不同的请求提供不同的接口,包括:记录日志接口,用于接收业务处理装置发送的记录业务请求相关信息日志的请求;提交缓存接口,用于在业务请求处理失败时,接收业务处理装置发送的提交关联的缓存区的调用请求;回滚缓存接口,用于接收业务处理装置发送的回滚关联的缓存区的缓存区回滚请求。
更具体的,接收单元31开放给业务处理装置的接口可以有不同的封装方式,如:
begin():表明开始一个业务请求或者事务处理。
end(boolean result):表明结束一个业务请求,并表明该业务请求处理结果是成功还是失败。
日志处理单元32,用于根据所述记录业务请求相关信息的请求将该业务请求相关信息记录到与所述业务请求关联的日志缓存区;以及根据日志输出请求将所述业务请求关联的日志缓存区中的业务请求相关信息写入日志文件中。
日志处理单元32将该业务请求相关信息记录到关联的日志缓存区。将该业务请求关联的日志缓存区中的业务请求相关信息写入日志文件中可以是按信息记录的时间先后顺序写入日志文件中。
本实施例提供的日志处理装置可以根据业务处理装置发送的记录业务请求相关信息的请求将业务请求相关信息记录到关联的日志缓存区,并根据业务处理装置发送的日志输出请求将关联的日志缓存区中的业务请求相关信息输出到日志文件中。实现了只输出处理失败的业务请求相关信息,控制了日志的输出量,减少了对磁盘空间和读写资源的占用,并且当业务请求处理失败时,输出有关该处理失败的业务请求相关信息的全部日志,体现了业务请求与输出日志的关联性,方便结合该处理失败的业务请求的全部处理流程进行后续分析。
可选的,另一个实施方式中,接收单元31还可以用于接收缓存区建立请求,所述缓存区建立请求中包含了业务请求的关联信息。
具体的,接收单元31向业务处理装置提供开始缓存接口,用于接收缓存区建立请求。
具体的,缓存区建立请求由业务处理装置在接收到业务请求后,准备进行业务请求处理时向日志处理装置发送,缓存区建立请求中包括业务请求的关联信息。该业务请求的关联信息在图1所示的实施例中已有说明,在此不赘述。
相应的,日志处理单元32还可以用于根据该缓存区建立请求建立与该业务请求关联的日志缓存区。
接收单元31收到缓存区建立请求后,通知日志处理单元32,日志处理单元32则根据该缓存区建立请求建立与该业务请求关联的日志缓存区。具体建立该业务请求关联的日志缓存区的实施方式在图1的实施例中已经有详细说明,在此不赘述。
可选的,在另一实施方式中,接收单元31还可以用于接收缓存区回滚请求。
相应的,日志处理单元32还可以用于根据该缓存区回滚请求清除所述业务请求关联的日志缓存区中的业务日志信息并删除所述业务请求关联的日志缓存区。
当所述业务请求全部处理完毕,并成功时,业务处理装置向日志处理装置发送缓存区回滚请求,由接收单元31接收,该缓存区回滚请求要求日志处理装置回滚该日志缓存区,日志处理单元32则根据该缓存区回滚请求清除所述业务请求关联的日志缓存区中的业务日志信息,并且删除该日志缓存区。
另外该日志处理装置还可以包括日志缓存区,以及日志文件存储区;当然,也可以在日志处理装置之外建立日志缓存区和日志文件存储区。
该日志处理装置通过日志处理单元32根据接收单元31接收到的请求执行相关操作,通过建立与每一个业务请求关联的日志缓存区,为不同的业务请求分别输出提供了条件,并且通过在业务请求处理成功时,回滚该业务请求关联的缓存区,及时释放了缓存空间,减少了对存储空间的占用。
图7为本发明一种业务处理装置的一个实施例的结构示意图,具体包括:
请求发送单元41,用于发送记录业务请求相关信息的请求,以便日志处理装置根据所述记录业务请求相关信息的请求将业务请求相关信息记录到与所述业务请求关联的日志缓存区;
处理单元42,用于当所述业务请求处理失败时,发送日志输出请求,以便日志处理装置根据所述日志输出请求将所述业务请求关联的日志缓存区中的业务请求相关信息写入日志文件中。
具体的,处理单元42提供与日志处理装置的接口,用于在当所述业务请求处理失败,向日志处理模块发送日志输出请求,要求日志处理装置提交缓存,即要求日志处理装置将日志缓存区中的业务请求相关信息写入日志文件中。处理单元42可以判断业务请求处理是否失败,判断的过程请参考图2的实施例中的介绍,在此不赘述。
本实施例提供的业务处理装置,通过处理单元42在业务请求处理结果失败时,请求日志处理装置提交与该业务请求关联的缓存区中的全部日志信息。实现了只输出处理失败的业务请求相关信息,控制了日志的输出量,减少了对磁盘空间和读写资源的占用,并且当业务请求处理失败时,输出有关该处理失败的业务请求相关信息的全部日志,体现了业务请求与输出日志的关联性,方便结合该处理失败的业务请求的全部处理流程进行后续分析。
另一实施方式中,处理单元42还用于向日志处理装置发送缓存区建立请求,该缓存区建立请求中包含了业务请求,以便该日志处理装置根据该缓存区建立请求建立与该业务请求关联的日志缓存区。
具体的,接收到业务请求后,业务处理装置在进行业务请求处理之前,通过处理单元42向日志处理装置发送缓存请求,该请求要求日志处理装置开始对该业务请求进行缓存。
在另一实施方式中,处理单元42还用于在该业务请求全部处理完毕,并且该业务请求处理结果为成功时,向日志处理装置发送缓存区回滚请求,要求其回滚缓存区,日志处理装置收到缓存区回滚请求后,根据该业务请求和缓存区的关联关系信息,找到相应的缓存区,执行回滚操作,即把缓存区的日志信息清除、删除该缓存区,回收出存储空间。
本实施例中的业务处理装置通过处理单元42调用日志处理装置建立与每一个业务请求相关联的日志缓存区,为不同的业务请求分别输出提供条件,并且通过在业务请求处理成功时,回滚该业务请求关联的缓存区,及时释放了缓存空间,减少了对存储空间的占用。
图8为本发明一种记录日志的系统的一个实施例的结构示意图,包括:
业务处理装置51,用于发送记录业务请求相关信息的请求,以便日志处理装置根据所述记录业务请求相关信息的请求将业务请求相关信息记录到与所述业务请求关联的日志缓存区,以及当所述业务请求处理失败时,发送日志输出请求,以便日志处理装置根据所述日志输出请求将所述业务请求关联的日志缓存区中的业务请求相关信息写入日志文件中;
日志处理装置52,用于接收记录业务请求相关信息的请求,根据所述记录业务请求相关信息日志的请求将所述业务请求相关信息记录到与所述业务请求关联的日志缓存区,以及接收日志输出请求,根据所述日志输出请求将所述业务请求关联的日志缓存区中的业务请求相关信息写入日志文件中。
具体的,日志处理装置52提供与业务处理装置的接口,可以包括记录日志接口,提交缓存接口,回滚缓存接口,具体功能请参见图6所示实施例中对接收单元31的介绍。
本实施例提供的记录日志的系统的工作原理与请述实施例中一致或类似,在此不赘述。
本实施例提供的记录日志的系统通过业务处理装置51调用日志处理装置52建立与业务请求对应的日志缓存区,以及在该业务请求处理失败时,调用日志处理装置52将所述业务请求关联的日志缓存区中的业务请求相关信息写入日志文件中。实现了只输出处理失败的业务请求相关信息,控制了日志的输出量,减少了对磁盘空间和读写资源的占用,并且当业务请求处理失败时,输出有关该业务请求相关信息的全部日志,体现了业务请求与输出日志的关联性,方便结合该业务请求的全部相关信息进行后续分析。
另一实施方式中,业务处理装置51还用于向日志处理装置52发送缓存区建立请求,所述缓存区建立请求中包含了业务请求;和/或,当所述业务请求全部处理完毕,并成功时,发送缓存区回滚请求,所述缓存区回滚请求用于指示所述日志处理装置根据将所述业务请求关联的日志缓存区中的业务请求相关信息清除并删除所述业务请求关联的日志缓存区。
另一实施方式中,日志处理装置52还用于根据业务处理装置51发送的缓存区建立请求建立与所述业务请求关联的日志缓存区;和/或,接收缓存区回滚请求,根据所述缓存区回滚请求清除所述业务请求关联的日志缓存区中的业务请求相关信息并删除所述业务请求关联的日志缓存区。
具体的,日志处理装置52向业务处理装置51提供开始缓存接口,用于接收缓存区建立请求。
业务处理装置51和日志处理装置52的工作原理与实施例一致或类似,在此不再赘述。
上述实施方式中,日志处理装置52通过接收业务处理装置51的调用请求,建立与每一个业务请求关联的日志缓存区,为不同的业务请求分别输出提供条件,并且通过在业务请求处理成功时,回滚该业务请求关联的缓存区,及时释放了缓存空间,减少了对存储空间的占用。
图9为一种记录日志的方法的一个实施例的流程图。在OCS系统的管理节点中,一个重要的处理就是与客户服务相关的业务受理请求处理,比如开户、销户、产品订购、充值等等。该实施方式以OCS系统中开户请求为例,包括:
601,业务处理装置接收营业系统发送的开户请求。
602,业务处理装置向日志处理装置发送该开户请求的缓存区建立请求。
603,日志处理装置建立与开户请求关联的日志缓存区并记录开户请求参数信息。
建立与开户请求关联的日志缓存区的实现细节请参见前面的实施例。
604,业务处理装置进行该开户请求接入控制处理,并调用日志处理装置记录该处理流程日志。具体是向日志处理装置发送记录该开户请求接入控制处理的请求。
605,日志处理装置将接入控制处理流程日志记录到与开户请求关联的日志缓存区。
606,业务处理装置进行该开户请求数据检查处理,并调用日志处理装置记录该处理流程日志。具体是向日志处理装置发送记录该开户请求数据检查处理的请求。
607,日志处理装置将该开户请求数据检查处理日志记录到与开户请求关联的日志缓存区。
608,业务处理装置进行该开户请求保存客户资料及订购信息处理,并调用日志处理装置记录该处理流程日志。具体是向日志处理装置发送记录该开户请求保存客户资料及订购信息处理的请求。
609,日志处理装置将该开户请求保存客户资料及订购信息处理日志记录到与开户请求关联的日志缓存区。
610,业务处理装置进行设置该开户请求初始账户金额处理,
611,调用日志处理装置记录该处理流程日志;具体是向日志处理装置发送记录该开户请求初始账户金额处理的请求。
612,日志处理装置将设置该开户请求初始账户金额处理日志记录到与开户请求关联的日志缓存区。
613,业务处理装置进行扣月租处理。
614,调用日志处理装置记录该处理流程日志。具体是向日志处理装置发送记录该开户请求扣月租处理的请求。
615,日志处理装置将该扣月租处理日志记录到与开户请求关联的日志缓存区。
616,计费系统向业务处理装置返回异常信息。
617,业务处理装置调用日志处理装置记录该异常信息日志;具体是向日志处理装置发送记录该异常信息的请求。
618,日志处理装置将该异常信息日志记录到与开户请求关联的日志缓存区。
619,业务处理装置判断该开户请求处理结果,为失败。
620,业务处理装置向日志处理装置发送日志输出请求,要求其提交与该开户请求关联的日志缓存区。
621,日志处理装置将与该开户请求关联的日志缓存区中全部日志按记录的顺序写入日志文件中。
本实施例中,为了达到定位问题的目录,可以记录以下几方面信息:
1、外部系统发过来的开户请求参数信息;
2、重要的处理步骤及相应处理结果信息,比如接入控制、数据校验,保存客户资料、保存产品订购信息等;
3、管理节点调用计费节点进行计费处理的请求和结果信息;
4、返回外部系统的结果信息。
如果系统不管最后业务请求处理是成功还是失败都输出缓存区中记录的日志到日志文件中的话,如果上述开户请求必须记录的信息总量为35K,平以一百万用户为基准的局点,一天开户请求达到1万,合计一天要产生340M日志。如果保留一个星期的话则需要2.3G空间。而开户则是整个系统的其中一个业务,还有充值、订购等等其它业务类型,根据计算,全部业务一周产生的日志达到100G左右的空间。如果是500万局点,则是500G左右空间。如此巨量的日志不仅消耗了大量的系统性能,也增加了产品的制造成本(需要磁盘阵列),后续的日志分析也将非常困难,而实际上,系统的错误率一般在1%以下。本实施例中采用的记录日志的方法,只需要输出1%以下的处理失败的业务请求日志即可,并且在业务请求失败时,输出与该业务请求有关的全部日志信息,而不只是某个关键点的信息,这样更有利于后续结合全部处理流程定位出失败原因。
另外,本实施例提供的记录日志的方法在该开户请求处理成功时,向日志处理装置发送缓存区回滚请求,要求其回滚与该开户请求关联的缓存区,日志处理装置根据该缓存区回滚请求,执行回滚操作,即把该与开户请求关联的缓存区的日志信息清除、删除该缓存区,回收出存储空间。这样,及时释放了缓存空间,减少了对存储空间的占用,减少了系统负担。
通过以上实施例的描述,本领域的技术人员可以清楚地了解到需要说明的是,本发明实施例不需要引入独立的功能部件,可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以执行本发明各个实施例所述的方法。这里所称的存储介质,如:ROM/RAM、磁盘、光盘等。
综上所述,以上仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。