本发明涉及互联网技术领域,尤其涉及一种基于分布式架构的交易处理系统及方法。
背景技术:
近几年,互联网金融的快速崛起,使得低成本支付模式在金融市场掀起了巨浪,第三方支付机构的支付业务规模获得了快速增长。同时由于央行已发文确认二维码支付的市场地位,定位于传统线下银行卡支付业务的补充,所以基于二维码的移动支付业务必将以更猛的势头增长。
但由于市场上付款端钱包种类繁多(如微信,支付宝,翼支付,沃钱包等),不同的收单机构所支持的移动支付标准也不同,技术力量也有差异,导致收单机构与付款端钱包接入整合难度大,成本高,时间久,重复工作多;同时也容易造成政策资金风险。主要存在如下问题:
1、收单机构接入多个付款端,要做多次开发调试;
2、每个付款端支持的移动支付流程不一致,收单机构接入困难;
3、收单机构需在每个付款端钱包开对应的结算账户,需适配每个付款端的结算流程;
4、收单机构技术能力不能支持的复杂结算流程和交易流程。
技术实现要素:
本发明的主要目的在于提出一种基于分布式架构的交易处理系统及方法,旨在解决现有技术中收单机构需通过不同的结算流程和交易流程来适配不同的付款机构的技术问题。
为实现上述目的,本发明提供一种基于分布式架构的交易处理系统,所述基于分布式架构的交易处理系统包括:输入路由集群、输出路由集群以及交易处理集群;
所述输入路由集群,用于接收收单机构的请求报文,提取所述请求报文中的目标付款机构信息,将所述目标付款机构信息发送给所述交易处理集群;
所述交易处理集群,用于根据所述目标付款机构信息查询出预设付款信息,并将所述预设付款信息发送给所述输出路由集群;
所述输出路由集群,用于接收所述预设付款信息,并将所述预设付款信息进行相应的处理,并将处理后的付款信息发送给所述目标付款机构。
优选地,所述基于分布式架构的交易处理系统还包括报文转换设备;
所述报文转换设备,用于接收收单机构的原始报文,将所述原始报文进行转换,将所述原始报文转换为预设报文,将所述预设报文作为所述收单机构的请求报文。
优选地,所述输入路由集群,还用于接收收单机构的请求报文,将所述请求报文进行解析,根据解析后的报文进行相应的业务处理。
优选地,所述交易处理集群,还用于获取所述目标付款机构对应的若干付款方式,将所述若干付款方式与预设模型进行匹配,选取出目标付款方式;
所述交易处理集群,还用于从所述目标付款机构信息中提取业务信息,将所述业务信息与预设业务模式进行匹配,选取出目标业务模式;
所述交易处理集群,还用于将所述目标付款方式与所述目标业务模式发送给所述输出路由集群。
优选地,所述输出路由集群,还用于根据所述预设付款信息选择相应的路由地址;
所述输出路由集群,还用于将所述预设报文信息转换为目标付款机构的报文信息;
所述输出路由集群,还用于根据所述路由地址将所述报文信息发送给所述目标付款机构。
优选地,所述基于分布式架构的交易处理系统还包括清结算集群;
所述清结算集群,用于接收用户的清结算请求,提取所述清结算请求中的账户信息,根据所述账户信息进行对账结算。
优选地,所述基于分布式架构的交易处理系统还包括实时库、备份库以及历史库;
所述交易处理集群与所述清结算集群还用于实时读取所述实时库中的第一交易数据,并将处理完成的第二交易数据实时写入所述实时库;
所述交易处理集群与所述清结算集群还用于实时读取所述备份库中的备份交易数据;
所述历史库,用于批处理所述实时库中的历史数据,并将所述实时库中的历史数据进行删除。
此外,为实现上述目的,本发明还提出一种基于分布式架构的交易处理方法,所述基于分布式架构的交易处理方法包括:
所述输入路由集群接收收单机构的请求报文,提取所述请求报文中的目标付款机构信息,将所述目标付款机构信息发送给所述交易处理集群;
所述交易处理集群根据所述目标付款机构信息查询出预设付款信息,并将所述预设付款信息发送给所述输出路由集群;
所述输出路由集群接收所述预设付款信息,并将所述预设付款信息进行相应的处理,并将处理后的付款信息发送给所述目标付款机构。
优选地,所述基于分布式架构的交易处理系统还包括清结算集群;
所述方法还包括:
所述清结算集群接收用户的清结算请求,提取所述清结算请求中的账户信息,根据所述账户信息进行对账结算。
优选地,所述基于分布式架构的交易处理系统还包括备份库、实时库以及历史库;
所述方法还包括:
所述交易处理集群与所述清结算集群实时读取所述实时库中的第一交易数据,并将处理完成的第二交易数据实时写入所述实时库;
所述交易处理集群与所述清结算集群实时读取所述备份库中的备份交易数据;
所述历史库批处理所述实时库中的历史数据,并将所述实时库中的历史数据进行删除。
本发明提出的基于分布式架构的交易处理系统,通过提供统一的收单机构接入标准来无缝的接入各个付款端机构,并进行相应的交易处理。
附图说明
图1为本发明基于分布式架构的交易处理系统第一实施例的结构示意图;
图2为本发明交易处理集群进行交易处理的流程示意图;
图3为本发明基于分布式架构的交易处理系统第二实施例的结构示意图;
图4为本发明基于分布式架构的交易处理系统第三实施例的结构示意图;
图5为本发明基于分布式架构的交易处理系统第四实施例的结构示意图;
图6为本发明基于分布式架构的交易处理系统第五实施例的结构示意图;
图7为本发明基于分布式架构的交易处理系统第六实施例的结构示意图;
图8为本发明转清结算集群的结构示意图;
图9为本发明基于分布式架构的交易处理系统第七实施例的结构示意图;
图10为本发明数据库的结构示意图;
图11为本发明基于分布式架构的交易处理方法第一实施例的流程示意图;
图12为本发明基于分布式架构的交易处理方法第二实施例的流程示意图;
图13为本发明基于分布式架构的交易处理方法第三实施例的流程示意图。
本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。
具体实施方式
应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
参照图1,图1为本发明基于分布式架构的交易处理系统第一实施例的结构示意图。所述基于分布式架构的交易处理系统包括:输入路由集群20、输出路由集群40以及交易处理集群30;
所述输入路由集群20,用于接收收单机构10的请求报文,提取所述请求报文中的目标付款机构信息,将所述目标付款机构信息发送给所述交易处理集群30;
需要说明的是,用户通过付款机构进行交易支付时,发起业务请求,收单机构根据该业务请求向处理平台发送请求报文,该报文中包括付款机构的信息,例如用户通过支付宝进行付款支付,收单机构收到通过支付宝进行支付的业务,并通过报文发送通过支付宝完成支付。所述输入路由集群20接收收单机构发送的报文请求,提取所述报文请求中的目标付款机构的信息,例如支付宝、微信等,并将该报文发送给所述交易处理集群30。所述收单机构是指与商户签有协议或为持卡人提供服务,直接或间接凭交易单据(包括电子单据或纸质单据)参加交换的清算会员单位,例如各大银行,银联或visa。
所述交易处理集群30,用于根据所述目标付款机构信息查询出预设付款信息,并将所述预设付款信息发送给所述输出路由集群40;
如图2所示的交易处理集群进行交易处理的流程示意图,其中接入路由集群相当于本实施例中的输入路由集群,输入路由集群20通过分布式服务框架(dubbo协议)远程调用所述交易处理集群30,所述交易处理集群30通过dubbo协议远程调用所述输出路由集群40。
需要说明的是,输入路由集群20、输出路由集群40以及交易处理集群30通过分布式应用程序协调服务(zookeeper)建立分布式服务层,zookeeper是一个分布式的,开放源码的分布式应用程序协调服务,是google的一个开源的实现。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等,zookeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。从而通过服务来进行分类建立各个业务处理流程。
在具体实现中,本基于分布式架构的交易处理系统通过从而通过zookeeper服务层来进行分类建立各个业务处理流程,所述输入路由集群20通过dubbo协议远程调用交易处理集群30,并将带有目标付款机构信息的报文转发给交易处理集群30,交易处理集群30负责处理主要业务逻辑和数据库的存储操作。
可以理解的是,所述目标付款机构信息查询出预设付款信息,并将所述预设付款信息发送给所述输出路由集群40,根据目标付款信息中查询若干个付款信息,并从中选取预设付款信息,在一般情况下,在某个付款信息下有若干个付款信息,可对该若干个付款信息进行处理,筛选出最优的付款信息,例如在付款机构支付宝下有若干个付款信息,例如支付宝-工行、支付宝-招行等,在若干在付款信息中,由于选择的银行不同,支付需要花费的手续费也会不同,在这种情况下,通过系统进行处理,筛选出费率或手续费最低的付款信息。
继续如图2所示,所述交易处理集群30通过dubbo调用输出路由集群40,并将筛选出的付款信息发送给所述输出路由集群40。
所述输出路由集群40,用于接收所述预设付款信息,并将所述预设付款信息进行相应的处理,并将处理后的付款信息发送给所述目标付款机构50。
需要说明的是,对于不同的付款机构,所支持的报文信息也会有所不同,例如支付宝与微信所支付的报文格式就不相同,为了实现对于不同付款机构的报文输出,在输出之前,根据目标付款机构的报文格式要求,将输出的报文进行组装,组装成对应于付款机构的报文,再进行报文的输出。例如在获取交易处理集群30发送的付款信息,并获取到付款机构为微信的付款机构,将带有付款信息的报文进行组装,从而符合微信支持的报文格式,在将处理后的报文发送给付款机构50,其中,所述付款机构可指支付宝、微信等第三方支付端。
本实施例提出的基于分布式架构的交易处理系统通过提供统一的收单机构接入标准来无缝的接入各个付款端机构,并进行相应的交易处理。
进一步地,如图3所示,基于第一实施例提出本发明基于分布式架构的交易处理系统第二实施例,在本实施例中,所述基于分布式架构的交易处理系统还包括报文转换设备60;
所述报文转换设备60,用于接收收单机构10的原始报文,将所述原始报文进行转换,将所述原始报文转换为预设报文,将所述预设报文作为所述收单机构10的请求报文。
需要说明的是,本基于分布式架构的交易处理系统可提供统一的标准的转清结算平台,在进行交易处理之前,需将收单机构10发送的业务请求转换为统一的报文请求,从而针对不同的收单机构都可接入在统一标准的转清结算平台进行处理。
在具体实现中,在接收到业务请求时,可将请求报文转换为统一的格式进行业务处理,所述预设报文可为该系统进行业务处理的统一报文或信息格式,将不同收单机构的报文转换为统一的报文格式,并将转换后的统一的报文格式作为收单机构的报文并进行后续的业务处理,例如收到银联或visa的业务请求时,由于银联或visa的报文格式并不相同,在这种情况下,将银联或visa的报文格式转换为本系统统一的报文格式,从而适应统一的系统进行相应的业务处理。
在本实施例中,可通过报文转换设备将业务请求的报文进行转换,转换为适配本系统的报文格式,从而实现对不同收单机构进行业务处理。
进一步地,如图4所示,基于第一实施例提出本发明基于分布式架构的交易处理系统第三实施例,在本实施例中,所述输入路由集群20',还用于接收收单机构10的请求报文,将所述请求报文进行解析,根据解析后的报文进行相应的业务处理。
需要说明的是,在一般情况下,为了实现高效的数据传输,报文一般都是以打包的形式,从而减少报文传输的流量,另外,在进行交易处理时,也要面临报文传输过程过程中的安全性,因此,在获取到收单机构的报文之后,可将报文进行解析,从而提取中报文中的信息,以方便进行后续的处理。
继续如图2所示,在输入路由集群20'接收到报文之后,首先将报文进行解析,提取解析之后的报文数据,然后根据解析的报文数据进行接口验证,并进行接口路由,根据业务需求路由到相应的业务接口,并通过相应的接口进行数据的分发。
在具体实现中,在接口验证时,还可通过调用数据服务层a中的数据,从而完成接口的验证,并将验证后的结构发送给数据服务层进行相应的保存。
在本实施例中,输入路由集群20'通过对报文进行解析,获取到业务数据,并通过业务数据进行相应的处理,根据业务的不同需求分发到不同的接口进行处理,从而实现分布式的数据处理。
进一步地,如图5所示,基于第一实施例、第二实施例以及第三实施例中任一项提出本发明基于分布式架构的交易处理系统第四实施例,在本实施例中,以基于第一实施例进行说明,所述交易处理集群30',还用于获取所述目标付款机构50对应的若干付款方式,将所述若干付款方式与预设模型进行匹配,选取出目标付款方式;
需要说明的是,在本实施例中的付款机构可为支付宝、微信等第三方付款机构,用于通过支付宝进行交易支付时,名下的支付宝可由多种付款方式,例如支付宝-工行、支付宝-招行等。
在具体实现中,在交易处理集群中设有预设模型,通过训练的模型可为可提取中手续费最低的付款方式,获取可提取中时效最短的付款方式,还可为各付款方式的限额状态等信息。通过若干付款方式与预设模型进行匹配,从而可选取出最佳的付款方式,例如,通过预设模型进行匹配,在进行当前支付的状态下,工行的手续费为10%,而招行的手续费为11%,从而选取中支付宝-工行作为最佳付款方式。
所述交易处理集群30',还用于从所述目标付款机构信息中提取业务信息,将所述业务信息与预设业务模式进行匹配,选取出目标业务模式;
可以理解的是,在进行交易支付时,还可获取到相应的业务信息,通过该业务信息可与预设业务模式进行匹配,所述预设业务模式可为同步处理、异步处理以及混合模式处理,通过业务信息的不同,采用适配的业务模式进行相应的处理,例如收单机构发起多业务处理,在这种情况向,最佳的业务处理模式为异步处理,从而对单点业务处理时,从而不影响其他业务的流程。
所述交易处理集群30',还用于将所述目标付款方式与所述目标业务模式发送给所述输出路由集群40。
继续如图2所示,交易处理集群30'接收输入输入路由集群20的业务信息,通过该业务信息调用交易适配模块进行处理,例如微信交易、支付宝交易以及其他交易处理,在进程选择之后,对业务信息进行分析,选取相应的业务模式,例如同步处理、异步处理以及混合模式处理,并将处理后的业务信息发送给业务适配模块。
在本实施例中,通过交易处理集群30'适配出最佳的付款方式以及最佳的业务模式,从而实现对多种服务的并行处理。
进一步地,如图6所示,基于第一实施例、第二实施例以及第三实施例中任一项提出本发明基于分布式架构的交易处理系统第五实施例,在本实施例中,以基于第一实施例进行说明,所述输出路由集群40',还用于根据所述预设付款信息选择相应的路由地址;
需要说明的是,在本实施例中,通过服务进行不同业务的划分,在进行不同业务处理时,将处理的业务数据发送到不同的业务处理接口,通过路由表中的路由信息,将业务发送到不同的接口。
所述输出路由集群40',还用于将所述预设报文信息转换为目标付款机构50的报文信息;
可以理解的是,对于不同的付款结构,报文的格式都有所不同,例如支付宝和微信,支付宝是使用支付宝的报文格式,微信也有属于自己一套的报文格式,在进行报文处理时,根据付款机构的类别,从而获取到付款机构的报文信息,从而将该系统的报文转换为付款机构的报文信息。
所述输出路由集群40',还用于根据所述路由地址将所述报文信息发送给所述目标付款机构50。
继续如图2所示,在输出路由集群40',在接收到处理后的报文时,根据路由信息将报文进行输出接口路由,并进行相应的输出验证,在验证成功之后,对报文进行组装,从而适配不同的付款机构,并通过输出分发端进行报文的分发给相应的付款机构。
在本实施例中,通过对输出报文进行相应的报文处理,适配不同的付款机构,从而实现对不同的付款机构的业务处理。
进一步地,如图7所示,基于第一实施例、第二实施例以及第三实施例中任一项提出本发明基于分布式架构的交易处理系统第六实施例,在本实施例中,以基于第一实施例进行说明,所述基于分布式架构的交易处理系统还包括清结算集群70;
所述清结算集群70,用于接收用户的清结算请求,提取所述清结算请求中的账户信息,根据所述账户信息进行对账结算。
需要说明的是,清结算集群70用于处理各个付款机构50以及收单机构10的对账,并向收单机构10提供统一的转清结算服务。
在具体实现中,收单机构10或者是付款机构50通过服务器登录到转清结算系统中进行相应的业务处理,清结算集群70根据将处理后的对账结构发送到服务器,收单机构10或者是付款机构50通过登录到服务器进行相应的查询。
如图8所示的转清结算集群的结构示意图,在转清结算集群中,首先通过动态加载调度任务配置,再进行调度任务分发,从而进行任务启动,包括的任务分为四服务模块进行处理,第一个服务流程是进行付款端对账请求,根据请求获取对账文件,并适配对账逻辑,为了确定对账结果的正确性,并进行差错处理;
第二个服务流程是收单机构对账,适配对账逻辑,生成对账文件,并将对账结构上传在服务器上;
第三个服务流程是账单汇总任务,适配清算逻辑,并进行相应的计费;
第四个服务流程是清算任务,获取账单汇总,清算给指定账户。
在本实施例中,通过清结算集群70处理各个付款机构以及收单机构的对账,并向收单机构提供统一的转清结算服务。
进一步地,如图9所示,基于第一实施例、第二实施例以及第三实施例中任一项提出本发明基于分布式架构的交易处理系统第七实施例,在本实施例中,以基于第六实施例进行说明,所述基于分布式架构的交易处理系统还包括实时库80、备份库90以及历史库100;
所述交易处理集群30与所述清结算集群70还用于实时读取所述实时库80中的第一交易数据,并将处理完成的第二交易数据实时写入所述实时库80;
所述交易处理集群30与所述清结算集群70还用于实时读取所述备份库90中的备份交易数据;
所述历史库100,用于批处理所述实时库80中的历史数据,并将所述实时库80中的历史数据进行删除。
需要说明的是,根据总体设计的描述,通过组建数据库集群,一共有三组数据库,分别是备份库、实时库以及历史库。备份库通过oracle自带工具实时从实时库同步,只读操作。主要用于同步基础数据到缓存,同时分散实时库的读操作压力。实时库主要用于交易核心的读写,使用高性能服务器,应对高并发操作。历史库使用批处理任务同步历史数据,并删除过期的实时库数据分区,降低实时库的高水位线。同时提供读操作,满足应用对历史数据的查询需求。
如图10所示的数据库的结构示意图,所述交易处理集群30与所述清结算集群70还用于实时读取所述实时库80中的交易数据,并将处理完成的交易数据实时写入所述实时库80;
所述交易处理集群30与所述清结算集群70实时读取所述备份库90中的备份交易数据;
所述历史库100批处理所述实时库80中的历史数据,并将所述实时库80中的历史数据进行删除。
在本实施例中,通过设备多个服务器,从而在其他服务器出现异常的情况下,不影响业务的处理。
此外,参照图11,本发明实施例还提出一种基于分布式架构的交易处理方法第一实施例流程示意图,应用于基于分布式架构的交易处理系统,所述系统包括:输入路由集群、输出路由集群以及交易处理集群;
所述基于分布式架构的交易处理方法包括以下步骤:
步骤s10,所述输入路由集群接收收单机构的请求报文,提取所述请求报文中的目标付款机构信息,将所述目标付款机构信息发送给所述交易处理集群;
需要说明的是,用户通过付款机构进行交易支付时,发起业务请求,收单机构根据该业务请求向处理平台发送请求报文,该报文中包括付款机构的信息,例如用户通过支付宝进行支付,收单机构收到通过支付宝进行支付的业务,并通过报文发送通过支付宝完成支付。所述输入路由集群接收收单机构发送的报文请求,提取所述报文请求中的目标付款机构的信息,例如支付宝、微信等,并将该报文发送给所述交易处理集群。所述收单机构是指与商户签有协议或为持卡人提供服务,直接或间接凭交易单据(包括电子单据或纸质单据)参加交换的清算会员单位,例如各大银行,银联或visa。
步骤s20,所述交易处理集群根据所述目标付款机构信息查询出预设付款信息,并将所述预设付款信息发送给所述输出路由集群;
如图2所示的交易处理集群进行交易处理的流程示意图,其中接入路由集群相当于本实施例中的输入路由集群,输入路由集群通过分布式服务框架(dubbo协议)远程调用所述交易处理集群,所述交易处理集群通过dubbo协议远程调用所述输出路由集群。
需要说明的是,输入路由集群、输出路由集群以及交易处理集群通过分布式应用程序协调服务(zookeeper)建立分布式服务层,zookeeper是一个分布式的,开放源码的分布式应用程序协调服务,是google的一个开源的实现。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等,zookeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。从而通过服务来进行分类建立各个业务处理流程。
在具体实现中,本基于分布式架构的交易处理系统通过从而通过zookeeper服务层来进行分类建立各个业务处理流程,所述输入路由集群通过dubbo协议远程调用交易处理集群,并将带有目标付款机构信息的报文转发给交易处理集群,交易处理集群负责处理主要业务逻辑和数据库的存储操作。
可以理解的是,所述目标付款机构信息查询出预设付款信息,并将所述预设付款信息发送给所述输出路由集群,根据目标付款信息中查询中若干个付款信息,并从中选取预设付款信息,在一般情况下,在某个付款信息下有若干个付款信息,可对该若干个付款信息进行处理,筛选出最优的付款信息,例如在付款机构支付宝下有若干个付款信息,例如支付宝-工行、支付宝-招行等,在若干在付款信息中,由于选择的银行不同,支付需要花费的手续费也会不同,在这种情况下,通过系统进行处理,筛选出费率或手续费最低的付款信息。
继续如图2所示,所述交易处理集群通过dubbo调用输出路由集群,并将筛选出的付款信息发送给所述输出路由集群。
步骤s30,所述输出路由集群接收所述预设付款信息,并将所述预设付款信息进行相应的处理,并将处理后的付款信息发送给所述目标付款机构。
需要说明的是,对于不同的付款机构,所支持的报文信息也会有所不同,例如支付宝与微信所支付的报文格式就不相同,为了实现对于不同付款机构的报文输出,在输出之前,根据目标付款机构的报文格式要求,将输出的报文进行组装,组装成对应于付款机构的报文,再进行报文的输出。例如在获取交易处理集群发送的付款信息,并获取到付款机构为微信的付款机构,将带有付款信息的报文进行组装,从而符合微信支持的报文格式,在将处理后的报文发送给付款机构,其中,所述付款机构可指支付宝、微信等第三方支付端。
本实施例提出的基于分布式架构的交易处理系统通过提供统一的收单机构接入标准来无缝的接入各个付款端机构,并进行相应的交易处理。
进一步地,如图12所示,基于提出本发明基于分布式架构的交易处理方法第二实施例,在本实施例中,所述方法还包括:
步骤s40,所述清结算集群接收用户的清结算请求,提取所述清结算请求中的账户信息,根据所述账户信息进行对账结算。
需要说明的是,清结算集群用于处理各个付款机构以及收单机构的对账,并向收单机构提供统一的转清结算服务。
在具体实现中,收单机构或者是付款机构通过服务器登录到转清结算系统中进行相应的业务处理,清结算集群根据将处理后的对账结构发送到服务器,收单机构或者是付款机构通过登录到服务器进行相应的查询。
如图8所示的转清结算集群的结构示意图,在转清结算集群中,首先通过动态加载调度任务配置,再进行调度任务分发,从而进行任务启动,包括的任务分为四服务模块进行处理,第一个服务流程是进行付款端对账请求,根据请求获取对账文件,并适配对账逻辑,为了确定对账结果的正确性,并进行差错处理;
第二个服务流程是收单机构对账,适配对账逻辑,生成对账文件,并将对账结构上传在服务器上;
第三个服务流程是账单汇总任务,适配清算逻辑,并进行相应的计费;
第四个服务流程是清算任务,获取账单汇总,清算给指定账户。
在本实施例中,通过清结算集群处理各个付款机构以及收单机构的对账,并向收单机构提供统一的转清结算服务。
进一步地,如图13所示,基于第一实施例或第二实施例提出本发明基于分布式架构的交易处理系统第三实施例,在本实施例中,所述方法还包括:
步骤s50,所述交易处理集群与所述清结算集群实时读取所述实时库中的第一交易数据,并将处理完成的第二交易数据实时写入所述实时库;
步骤s60,所述交易处理集群与所述清结算集群实时读取所述备份库中的备份交易数据;
步骤s70,所述历史库批处理所述实时库中的历史数据,并将所述实时库中的历史数据进行删除。
需要说明的是,根据总体设计的描述,通过组建数据库集群,一共有三组数据库,分别是备份库、实时库以及历史库。备份库通过oracle自带工具实时从实时库同步,只读操作。主要用于同步基础数据到缓存,同时分散实时库的读操作压力。实时库主要用于交易核心的读写,使用高性能服务器,应对高并发操作。历史库使用批处理任务同步历史数据,并删除过期的实时库数据分区,降低实时库的高水位线。同时提供读操作,满足应用对历史数据的查询需求。
如图10所示的数据库的机构示意图,所述交易处理集群30与所述清结算集群70还用于实时读取所述实时库80中的交易数据,并将处理完成的交易数据实时写入所述实时库80;
所述交易处理集群30与所述清结算集群70实时读取所述备份库90中的备份交易数据;
所述历史库100批处理所述实时库80中的历史数据,并将所述实时库80中的历史数据进行删除。
在本实施例中,通过设备多个服务器,从而在其他服务器出现异常的情况下,不影响业务的处理。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在如上所述的一个存储介质(如rom/ram、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本发明各个实施例所述的方法。
以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。