技术领域
[0001] 本
发明涉及互联网技术领域，尤其涉及一种基于分布式环境的用于账务日切的核对方法及装置。
背景技术
[0002] 随着互联网技术的发展，在线金融业务逐步扩大，目前国内的
银行、金融业已基本实现数字化和网络化。而对于银行、金融行业，账务管理的有效性和准确性是重中之重，尤其是金融行业不同于零售行业，需要日清月结。
[0003] 当前采用的主要是基于核心银行系统(corebanki ng)的架构，账务的日终处理时都会进行总分和借贷平衡的检查。在这其中，如何实现7*24小时不间断条件下留存日切时点，成为一个技术难点。为了解决该问题，
现有技术中主要采用会计分录校对的机制，即余额快照机制进行账务核对。在这其中，日切处理会由一种机制触发，所有的账务报表都会提交到
数据库的单一记录中，因此银行业称为了高端
服务器设备的最大用户，每年会花费很多资金建设中央机房，并竭尽所能堆高中央机房的
硬件性能。而一旦遇到了黑客攻击，往往也会造成整个银行系统瘫痪。
发明内容
[0004] 本发明的
实施例提供一种基于分布式环境的用于账务日切的核对方法及装置，能够在分布式账务处理条件下，以去中心化，完全避免单点的方式解决总分核对的问题，使会计逻辑最大化的后置，避免了内部管理要求对客户服务的干扰，同时也极大的提高了会计处理的灵活度，减少了系统中业务处理部分的设计关注事项。
[0005] 为达到上述目的，本发明的实施例不采用传统以数据库表中日期做为账务时间的机制(传统集中式大机房)，完全以各分布式
节点中
应用服务器时间为账务时间。具体技术方案如下：
[0006] 接收到
请求消息后，抓取业务服务器的当前时间的日期部分作为当前请求的账务时间(RTD)，其中，接收请求消息的为分布式系统，所述分布式系统由至少2个作为节点的业务服务器组成；在每一个客户的账户表中记录所述RTD和上一笔交易发生的时间(LTD)；
[0007] 当检测到账户表中的RTD和数据库记录中的时间(TD)不一致时，以时间轴中最靠后的时间为准进行时间滚动；
[0008] 汇总
指定日期的账户金额，得到所述指定日期的期末余额。
[0009] 本发明实施例提供的基于分布式环境的用于账务日切的核对方法，不通过单点存储的方式解决一致性日切的问题，极大的降低了部署和应用开发的难度。解决了账务时间和客户
感知时间不一致，以及传统日切机制会有毫秒级的拒绝交易的情况。
附图说明
[0010] 为了更清楚地说明本发明实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
[0011] 图1a、图1b为本发明实施例提供的系统架构示意图；
[0012] 图2为本发明实施例提供的一种方法流程示意图；
[0013] 图3为本发明实施例提供的具体实例的示意图；
[0014] 图4为本发明实施例提供的具体实例的示意图。
具体实施方式
[0015] 为使本领域技术人员更好地理解本发明的技术方案，下面结合附图和具体实施方式对本发明作进一步详细描述。下文中将详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。本技术领域技术人员可以理解，除非特意
声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的
说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/ 或”包括一个或更多个相关联的列出项的任一单元和全部组合。本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。
[0016] 本发明实施例具体可以实现在一种如图1a所示的系统中，其中：
[0017] 分析服务器具体可以是单独作成的服务器设备，比如：
机架式、刀片、塔式或者机柜式的服务器设备，也可以采用工作站、大型计算机等具备较强计算能
力硬件设备；也可以是由多个服务器设备组成的服务器集群。
[0018] 数据库系统上运行用户账户数据和信息，用于存储并管理用户账户数据和信息。数据库系统具体可以是单独作成的，用于数据的管理、存储的分析服务器，也可以是由多个分析服务器组成的服务器集群。在数据库系统的硬件设备上运行对应分析服务器的数据库，用于管理并存储分析服务器的数据。具体可以采用常用的网状数据库(Network Database)、关系数据(Relational Database)、树状数据库(Hierarchical Database)、面向对象数据库 (Object-oriented Database)以及新一代
大数据系统架构。
[0019] 分析服务器具体也可以集成在数据库系统中，比如：将服务器集群中的部分分析服务器划分为前端服务器，用于与用户终端交互数据，这种前端服务器即可以称为分析服务器；而将服务器集群中的另一部分服务器和大部分的存储设备(比如磁盘阵列、缓存机等)都可以作为后台数据库为前端服务器提供数据
访问服务，且在后台数据库上维护所述问题库。
[0020] 可选的，如图1b所示的系统，还可以包括用户终端，具体可以实做成单独一台系统，或整合于各种不同的业务应用系统中，诸如智能手机、
平板电脑 (Tablet Personal Computer)、膝上型电脑(Laptop Computer)或者
个人数字助理(personal digital assistant，简称PDA)等。
[0021] 本发明实施例提供一种基于分布式环境的用于账务日切的核对方法，具体可以通过分析服务器实现，如图2所示，包括：
[0022] S1、接收到请求消息后，抓取业务服务器的当前时间的日期部分作为当前请求的账务时间(RTD)。
[0023] 其中，接收请求消息的为分布式系统，所述分布式系统由至少2个作为节点的业务服务器组成；在每一个客户的账户表中记录所述RTD和上一笔交易发生的时间(LTD)[0024] 接收到请求消息后，在处理流程中抓取业务服务器的当前时间的日期部分作为当前请求的账务时间(RTD)，并贯穿整个处理过程。
[0025] 本实施例中所述的账务时间，可以理解为机器的当前时间值的日期部分，日切处理不关注时分秒，只关注是哪一天。
[0026] 本实施例不采用传统以数据库表中日期做为账务时间的机制(传统集中式大机房)，完全以各分布式节点中业务服务器时间为账务时间，这一处理至少还有两个好处，解决了账务时间和客户感知时间不一致，以及传统日切机制会有毫秒级的拒绝交易的情况。
[0027] S2、当检测到账户表中的RTD和数据库记录中的时间(TD)不一致时，以时间轴中最靠后的时间为准进行时间滚动。
[0028] 其中，处理账户表时，请求的账务日期RTD和数据库记录中的账务日期应保持一致，以时间轴中最靠后的时间为准进行时间滚动，即对于请求账务日期RTD, 数据库记录中的账户的账务日期TD，账户的上一账务日期LTD，账户的余额A，账户的上日余额LA，具体的，RTD和TD都向后保持一致，update较早的一个。如图3所示，有如下关系和处理(其中算符＝>表示：将算符左边参数的值放到右边的参数中)：
[0029] 若RTD＝TD，则更新A；
[0030] 若RTD>TD，则进行处理：TD＝>LTD、RTD＝>TD、A＝>LA，并且更新A；若RTDRTD，并且更新A。
[0031] S3、汇总指定日期的账户金额，得到所述指定日期的期末余额。
[0032] 具体的，日终时，由系统的会计处理部分选择一个日期D，通知业务处理部分按汇总该日客户账目总金额，则对于当前机器日期RTD,账户的账务时间TD，账户的上一笔交易发生的时间LTD，账户的余额A，账户的上日余额LA，有如下关系和处理：
[0033] 当检测到指定日期D小于或等于任意一台业务服务器上的RTD时，判定处理失败，否则：
[0034] 若D＝TD，则以LA参与所述指定日期的期末余额的汇总；
[0035] 若D>TD，则以A参与所述指定日期的期末余额的汇总。
[0036] 举例来说，如图4所示：
[0037] 进一步的，系统的会计处理部分将某一科目的上日分录流
水逐条过账后形成上日期末余额，此余额应与获取到的分布式系统所有部分的汇总余额的总和相等，则完成总分核对过程，即，对于某一科目：期初余额+∑当日流水明细＝∑该项目下所有分户金额。
[0038] 需要说明的是，本实施例中所提及的一些名词，比如：账务时间(RTD)、上一笔交易发生的时间(LTD)、数据库记录中的时间(TD)等，皆为会计领域中的专业名词，在一些场合中，这些词可能会由于需要有所变化，比如：数据库记录中的时间，有时也可以称为数据记录时间，或者入库时间等等，本领域技术人员可以按照会计领域中的惯常理解使用这些词。
[0039] 再例如：目前在会计数据的管理中，通常会金融系统中建立总账，同时在客户系统中也建立对应的账户，实现双系统记账管理，比如：每一个客户在系统中建立的一对一的账户称之为分户，分户又称为账户表。而在数据层面上，一个针对总账的增减的指令消息，即为会计分录的内容。在本实施例步骤1中，所述抓取业务服务器的当前时间的日期部分作为当前请求的账务时间(RTD)，包括：
[0040] 若检测到所述请求消息对应至少两个账户，则确定各个账户所在的节点；
[0041] 获取所确定的各个节点的业务服务器的当前时间的日期部分，并将所述各个节点的业务服务器的当前时间的日期部分中最早的，抓取作为所述RTD。
[0042] 进一步的，当请求消息对应至少两个账户时，有两种处理机制：
[0043] 机制1:每一个客户账户的会计处理都只跟“内部账”做借贷平衡；
[0044] 机制2：业务处理部分应能标注每次账户操作的请求ID，同一请求触发的多次账户操作ID相同，但账务时间可能不同。对于跨日期的一套账户操作，会计引擎处理时自动加入过渡分录处理。
[0045] 进一步的，在本实施例步骤2中，处理过程中，先处理账户表，后处理账务或事件表，账户表和账务/事件表中相关记录的账务时间必须一致。
[0046] 本发明实施例还提供一种基于分布式环境的用于账务日切的核对装置，具体包括：
[0047] 接收模
块：用于接收到请求消息后，抓取业务服务器的当前时间的日期部分作为当前请求的账务时间(RTD)；
[0048] 处理模块：用于当检测到账户表中的RTD和数据库记录中的时间(TD)不一致时，以时间轴中最靠后的时间为准进行时间滚动；
[0049] 输出模块：用于汇总指定日期的账户金额，得到所述指定日期的期末余额。
[0050] 所述处理模块还包括：以时间轴中最靠后的时间为准进行时间滚动，包括：
[0051] 若RTD＝TD，则更新A；
[0052] 若RTD>TD，则进行处理：TD＝>LTD、RTD＝>TD、A＝>LA，并且更新A；
[0053] 若RTDRTD，并且更新A；
[0054] 其中，A表示所述账户的余额，LA表示所述账户在上日的余额，算符＝>表示：将算符左边参数的值放到右边的参数中。
[0055] 所述接收模块还包括，所述抓取业务服务器的当前时间的日期部分作为当前请求的账务时间(RTD)，包括：
[0056] 若检测到所述请求消息对应至少两个账户，则确定各个账户所在的节点；
[0057] 获取所确定的各个节点的业务服务器的当前时间的日期部分，并将所述各个节点的业务服务器的当前时间的日期部分中最早的，抓取作为所述RTD。
[0058] 进一步的，所述输出模块还包括，汇总指定日期的账户金额，得到所述指定日期的期末余额包括：
[0059] 当检测到指定日期D小于或等于任意一台业务服务器上的RTD时，判定处理失败，否则：
[0060] 若D＝TD，则以LA参与所述指定日期的期末余额的汇总；
[0061] 若D>TD，则以A参与所述指定日期的期末余额的汇总。
[0062] 本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉
本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以
权利要求的保护范围为准。
