具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚明白,下面结合实施例和附图,对本申请实施例做进一步详细说明。在此,本申请实施例的示意性实施例及其说明用于解释本申请实施例,但并不作为对本申请实施例的限定。
下面结合附图,对本申请实施例的具体实施方式作进一步的详细说明。
参考图1所示,本申请实施例的业务处理方法包括以下步骤:
步骤S101、接收业务请求。
在本申请实施例中,业务请求可以是任意业务处理***的任意的业务请求,比如支付宝的商户群红包转账请求,比如电子优惠券发放***中的电子优惠券发放请求,再比如积分***中的积分减扣请求,等等。
步骤S102、将所述业务请求的业务领域模型中的数据对象进行数据模型转换,以使转换后得到的新数据对象与指定数据库中的各个业务相关数据表对应。
一般的,在当前已使用的业务处理***中,业务请求的业务领域模型是预先建立好的。而在本申请实施例中,将业务请求的已有业务领域模型中的数据对象(比如各种业务相关的Java类对象)进行数据模型转换的主要目的在于,是要使得转换后得到的新数据对象可直接与指定数据库中的各个业务相关数据表对应,从而方便在指定数据库的数据存储。
在本申请一个实施例中,所述数据模型转换比如可以是从实体联系图(ER,EntityRelationship Diagram)转换成关系模型等等。
步骤S103、在成功处理所述业务请求后,将当前所述新数据对象中指定范围内的数据打包成数据包保存,并返回业务处理结果。
本申请实施例中的打包可以理解为减少要存储对象的一种方式。而将当前所述新数据对象中指定范围内的数据打包的主要目的,亦是在于压缩或合并数据(比如将原本需要存储在多张数据表中的数据,压缩到一张数据表中),这样可以降低业务处理***同步处理业务请求时的数据库操作次数,这在业务高并发时(比如双十一购物促销狂欢日等),很有利于减轻业务处理***的压力。
在本申请的一个实施例中,所述将当前所述新数据对象中指定范围内的数据打包比如可以是通过序列化的方式,具体包括:
首先,通过序列化的方式将当前所述新数据对象中指定范围内的数据转换为字符串,比如通过hession协议转换成文本字符串;
其次,将所述字符串作为扩展字段写入所述指定数据库中的一个指定的业务相关数据表中;
最后,更新所述指定的业务相关数据表中的数据库记录状态位(比如status=SUCCESS,substatus=PACKED)。
本申请其他实施例中,也可以采用其他减少要存储对象的方法。比如可将当前所述新数据对象中指定范围内的数据转换为二进制文件形式存贮到一个基于内存的其他数据库(比如NOSQL(Not Only SQL)数据库)中,待业务低峰(即业务量低于设定阈值)的时候恢复数据,即从NOSQL数据库中读取文件信息再将完整的数据对象恢复到目标业务数据库中。
本申请实施例中,所述返回业务处理结果一般是指向上游调用方返回业务处理结果。
步骤S104、当业务量低于设定阈值时,捞取保存的数据包以进行解包处理,并将解包后得到的数据对应***所述指定数据库中的各个业务相关的数据表中。
当业务量低于设定阈值时,表示业务处理***当前正处于空闲或业务量低峰期。此时,业务处理***可以解包数据落地数据库明细。
在本申请一个实施例中,所述的捞取可以为定时捞取。在本申请一个具体实施例中,定时捞取比如可以在中间件(比如任务调度中心)定时发送的驱动消息下触发,每隔一个固定时间,任务调度中心的触发器会调用业务处理***的一个接口来执行一个任务,此任务的具体可以是根据特定过滤条件搜索数据库中的记录,返回满足条件的数据库记录,对于本申请实施例来说,就是返回那些包含打包数据信息的数据记录。
而在在本申请另一个实施例中,所述的捞取也可以不使用定时任务,比如采用人工触发方式等等,但是相对而言,定时捞取更方便触发解包,以恢复数据的过程。
在本申请上述方法实施例中,上述的解包和打包是对应的,如果打包是采用序列化的方式,那么后续的解包则采用反序列化的方式。其中,序列化与反序列化可以使用的协议比如Protobuf、Thrift、Hessian和Kryo等等。
在本申请另一个实施例中,在步骤S102之后,还可以包括:
如果处理所述业务请求失败,则直接回业务处理结果。如果业务请求处理失败,则无需更新数据库,因此也就无需进行数据打包。
本申请实施例中,在接收业务请求后,可将业务请求的业务领域模型中的数据对象进行数据模型转换,以使转换后得到的新数据对象与指定数据库中的各个业务相关数据表对应;在成功处理该业务请求后,可将当前新数据对象中指定范围内的数据打包成数据包保存,并返回业务处理结果;待业务量低于设定阈值时,捞取保存的数据包以进行解包处理,并将解包后得到的数据对应***指定数据库中的各个业务相关的数据表中,可见,本申请实施例中,在业务处理完成后并不同步更新数据库,而是将处理结果按照要求打包,待业务量低峰时再将处理结果解包后更新数据库。因此,在高并发时,本申请实施例可以在很大程度上减轻业务处理***的处理压力。并且,本申请实施例是同步处理业务请求并返回处理结果,使得用户可以及时获得处理结果,用户体验较高。
虽然上文描述的过程流程包括以特定顺序出现的多个操作,但是,应当清楚了解,这些过程可以包括更多或更少的操作,这些操作可以顺序执行或并行执行(例如使用并行处理器或多线程环境)。
为便于理解本申请,以下结合图1的实施例介绍一种具体应用场景。
在支付宝商户红包转账业务中,支付宝的资金业务处理***接收到上游调用方的转账请求后;将转账业务请求的业务领域模型中的数据对象进行数据模型转换,以使转换后得到的新数据对象与数据库中的各个业务相关数据表对应;其中在该资金业务处理***中转账业务请求的得到的新数据对象与数据库中的六张数据表对应,该六张数据表的名称分别如下:
a)、CFM_TABLE_MASTER
b)、CFM_TABLE_A
c)、CFM_TABLE_B
d)、CFM_TABLE_C
e)、CFM_TABLE_D
f)、CFM_TABLE_E
其中,CFM_TABLE_MASTER为业务主单据,其内包含有余下5个数据表的业务相关数据;因此,在资金业务处理***成功处理转账业务请求后,可仅将CFM_TABLE_MASTER当前打包成数据包保存,并向上游调用方返回业务处理结果;待业务低峰时,资金业务处理***捞取保存的数据包以进行解包处理,并将解包后得到的数据对应***数据库中的上述六张数据表中。统计表明,采用本申请实施例的方案后,资金业务处理***同步处理请求时的数据库操作可由原来的大约25次减少到现在的7次左右,显著降低了业务处理***的处理压力。
参考图2所示,本申请实施例的业务处理***中配置有业务处理装置。
结合图3a所示,在本申请的一个实施例中,该业务处理装置可以包括:
业务请求接收模块31,用于接收业务请求。
在本申请实施例中,业务请求可以是任意业务处理***的任意的业务请求,比如支付宝的商户群红包转账请求,比如电子优惠券发放***中的电子优惠券发放请求,再比如积分***中的积分减扣请求,等等。
数据模型转换模块32,用于将所述业务请求的业务领域模型中的数据对象进行数据模型转换,以使转换后得到的新数据对象与指定数据库中的各个业务相关数据表对应。
一般的,在当前已使用的业务处理***中,业务请求的业务领域模型是预先建立好的。而在本申请实施例中,将业务请求的已有业务领域模型中的数据对象(比如各种业务相关的Java类对象)进行数据模型转换的主要目的在于,是要使得转换后得到的新数据对象可直接与指定数据库中的各个业务相关数据表对应,从而方便在指定数据库的数据存储。
本申请一个具体实施例中,所述数据模型转换比如可以是从ER图转换成关系模型等等。
业务数据打包模块33,用于在成功处理所述业务请求后,将当前所述新数据对象中指定范围内的数据打包成数据包保存。
本申请实施例中的打包可以理解为减少要存储对象的一种方式。而将当前所述新数据对象中指定范围内的数据打包的主要目的,亦是在于压缩或合并数据(比如将原本需要存储在多张数据表中的数据,压缩到一张数据表中),这样可以降业务处理***同步处理业务请求时的数据库操作次数,这在业务高并发时(比如双十一购物促销狂欢日等),很有利于减轻业务处理***的压力。
在本申请的一个实施例中,所述将当前所述新数据对象中指定范围内的数据打包比如可以是通过序列化的方式,在本申请其他实施例中,也可以采用其他减少要存储对象的方法。比如可将当前所述新数据对象中指定范围内的数据转换为二进制文件形式存贮到一个基于内存的其他数据库(比如NOSQL(Not Only SQL)数据库)中,待业务低峰(即业务量低于设定阈值)的时候恢复数据,即从NOSQL数据库中读取文件信息再将完整的数据对象恢复到目标业务数据库中。
第一结果返回模块34,用于在成功处理所述业务请求后,返回业务处理结果。本申请实施例中,所述返回业务处理结果一般是指向上游调用方返回业务处理结果。
数据库异步更新模块35,用于当业务量低于设定阈值时,捞取保存的数据包以进行解包处理,并将解包后得到的数据对应***所述指定数据库中的各个业务相关的数据表中。
当业务量低于设定阈值时,表示业务处理***当前正处于空闲或业务量低峰期。此时,业务处理***可以解包数据落地数据库明细。
在本申请一个实施例中,所述的捞取可以为定时捞取。在本申请一个具体实施例中,定时捞取比如可以在中间件(比如任务调度中心)定时发送的驱动消息下触发,每隔一个固定时间,任务调度中心的触发器会调用业务处理***的一个接口来执行一个任务,此任务的具体可以是根据特定过滤条件搜索数据库中的记录,返回满足条件的数据库记录,对于本申请实施例来说,就是返回那些包含打包数据信息的数据记录。
而在在本申请另一个实施例中,所述的捞取也可以不使用定时任务,比如采用人工触发方式等等,但是相对而言,定时捞取更方便触发解包,以恢复数据的过程。
结合图3b所示,在本申请的另一个实施例中,业务处理装置还可以包括:第二结果返回模块36,用于当处理所述业务请求失败时,直接回业务处理结果。
参考图4所述,上述数据打包模块33,具体可以包括:
序列化子模块331,用于通过序列化的方式将当前所述新数据对象中指定范围内的数据转换为字符串,比如通过hession协议转换成文本字符串;
数据保存子模块332,用于将所述字符串作为扩展字段写入所述指定数据库中的一个指定的业务相关数据表中;
状态位更新子模块332,用于更新所述指定的业务相关数据表中的数据库记录状态位(比如status=SUCCESS,substatus=PACKED)。
本申请其他实施例中,也可以采用其他减少要存储对象的方法。比如可将当前所述新数据对象中指定范围内的数据转换为二进制文件形式存贮到一个基于内存的其他数据库(比如NOSQL(Not Only SQL)数据库)中,待业务低峰(即业务量低于设定阈值)的时候恢复数据,即从NOSQL数据库中读取文件信息再将完整的数据对象恢复到目标业务数据库中。
在本申请上述装置实施例中,上述的解包和打包是对应的,如果打包是采用序列化的方式,那么后续的解包则采用反序列化的方式。其中,序列化与反序列化可以使用的协议比如Protobuf、Thrift、Hessian和Kryo等等。
本申请实施例中,在接收业务请求后,可将业务请求的业务领域模型中的数据对象进行数据模型转换,以使转换后得到的新数据对象与指定数据库中的各个业务相关数据表对应;在成功处理该业务请求后,可将当前新数据对象中指定范围内的数据打包成数据包保存,并返回业务处理结果;待业务量低于设定阈值时,捞取保存的数据包以进行解包处理,并将解包后得到的数据对应***指定数据库中的各个业务相关的数据表中,可见,本申请实施例中,在业务处理完成后并不同步更新数据库,而是将处理结果按照要求打包,待业务量低峰时再将处理结果解包后更新数据库。因此,在高并发时,本申请实施例可以在很大程度上减轻业务处理***的处理压力。并且,本申请实施例是同步处理业务请求并返回处理结果,使得用户可以及时获得处理结果,用户体验较高。
为了描述的方便,描述上述装置时以功能分为各种模块分别描述。当然,在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。
本领域技术人员还可以了解到本申请实施例列出的各种说明性逻辑块、单元和步骤可以通过硬件、软件或两者的结合来实现。至于是通过硬件还是软件来实现取决于特定的应用和整个***的设计要求。本领域技术人员可以对于每种特定的应用,可以使用各种方法实现所述的功能,但这种实现不应被理解为超出本申请实施例保护的范围。
本申请实施例中所描述的各种说明性的逻辑块,或单元都可以通过通用处理器,数字信号处理器,专用集成电路(ASIC),现场可编程门阵列或其它可编程逻辑装置,离散门或晶体管逻辑,离散硬件部件,或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器,可选地,该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现,例如数字信号处理器和微处理器,多个微处理器,一个或多个微处理器联合一个数字信号处理器核,或任何其它类似的配置来实现。
本申请实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件模块、或者这两者的结合。软件模块可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地,存储媒介可以与处理器连接,以使得处理器可以从存储媒介中读取信息,并可以向存储媒介存写信息。可选地,存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中,ASIC可以设置于用户终端中。可选地,处理器和存储媒介也可以设置于用户终端中的不同的部件中。
在一个或多个示例性的设计中,本申请实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现,这些功能可以存储与电脑可读的媒介上,或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如,这样的电脑可读媒体可以包括但不限于RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁性存储装置,或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外,任何连接都可以被适当地定义为电脑可读媒介,例如,如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电缆、双绞线、数字用户线(DSL)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、DVD、软盘和蓝光光盘,磁盘通常以磁性复制数据,而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。
以上所述的具体实施例,对本申请的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本申请实施例的具体实施例而已,并不用于限定本申请的保护范围,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。