专利名称：：交易数据处理方法及系统的制作方法
技术领域：
：本申请涉及计算机系统
技术领域：
，特别涉及一种交易数据处理方法及系统。
背景技术：
：现有的网络交易平台中，作为网络交易平台提供商，往往需要参与到网络交易涉及的资金流动过程中。例如淘宝网，推出的企业对用户(BusinesstoCustomer,B2C)以及用户对用户(CustomertoCustomer,C2C)的交易平台中，通过第三方支付软件支付宝来支持交易中间环节的资金流通。以C2C业务举例来说，作为普通用户的买家和卖家在交易进行过程中，买家需要首先将交易涉及的资金首先转入支付宝帐户中，卖家看到该笔资金转入支付宝账户中后，发送交易货物，待买家收到货物后，在淘宝网上确认收货，之后，先前转入支付宝帐户中的资金再转入卖家帐户中，从而完成交易。当然，B2B业务及B2C业务中，现有的一些交易平台也需要参与中间环节的资金流通过程。仍以支付宝在C2C业务中的应用来举例说明，交易中间环节中用于参与资金流通的支付宝内部帐户。由于众多交易的进行，通常该支付宝内部帐户中需要记载大量的交易明细，通常，该交易明细在账务记录中称之为分录。支付宝内部帐户的分录包括资金交易的双方的记录。下表l为关于支付宝内部帐户分录的示例。用户帐户支付宝内部帐户分录号交易单交易时用户帐用户帐支付宝支付宝内支付宝内部号间户ID户发生内部帐部帐户发帐户余额额户ID生额1用户1+101001+101102用户2-51001-51053...………...4<table>tableseeoriginaldocumentpage5</column></row><table>表l如表l,分录中的一方为支付宝内部帐户，另一方为用户帐户。例如分录l中，购买物品的用户1为支付宝充值10元人民币，则分录中的一条中记载用户帐户发生额为+10，支付宝内部帐户(如该帐户ID为0001)—方中记载支付宝内部帐户发生额+10,如果之前支付宝内部帐户余额为100,则分录l中支付宝帐户余额最终为110。再例如分录2中，卖出物品的用户2从支付宝中提取5元人民币，则分录中的一条中记载用户帐户发生额为-5，支付宝内部帐户一方中记载支付宝内部帐户发生额-5,之前支付宝内部帐户余额为110，则分录l中支付宝帐户余额最终为105。上述分录1和分录2中的交易单号、交易时间信息在这里作了省略，当然还可能包括其它条目，例如涉及的银行、银行流水号等相关信息，在这里也作了省略。现有技术中，在每次交易发生时，处理交易的计算机系统采取实时方式更新支付宝内部帐户。实际当中，发生的交易量非常巨大，涉及的用户也4艮多。而且，支付宝内部帐户一4殳是固定的，而用户帐户包括大量不同的帐户。大量不同帐户发起的交易，可能是并发的。而所述计算机系统对支付宝内部帐户的分录记载和余额更新，如果采用多线程并发处理，可能会给余额更新带来异常。例如，支付宝内部帐户余额为100元，同时有A用户的存款10元交易和B用户的存款5元交易并发执行，由线程1和线程2分别处理这两个交易。线程1和线程2同时获取支付宝内部帐户的余额，即都读取得到数值IOO,之后，线程I将IOO元与A用户存入的10元相加，即100+10,得到结果IIO,线程2将100元与B用户存入的5元相加，即100+5,得到结果105，之后，可能有两种情况。一种是线程1先将结果110写入支付宝内部帐户余额的存储单元中，线程2后将结果105写入支付宝内部帐户余额的存储单元中，而后写入的105会覆盖之前写入的110,因此，最终结果为105,而这个结果显然是不对的。另一种是线程2先将结果105写入支付宝内部帐户余额的存储单元中，线程1后将结果110写入支付宝内部帐户余额的存储单元中，而后写入的110会覆盖之前写入的105，因此，最终结果为IIO,这个结果显然也是不对的。可见，无论上述哪种方式，最终写入的结果都不正确。而正确的结果应当是100+10+5=115。出现这一异常结果的问题在于计算机系统允许对支付宝内部帐户余额中的值进行多线程并发处理。现有技术为了解决上述问题，采用了如图l流程所示的处理方式S101:交易平台计算机系统接收发来的大量交易请求。S102:交易平台计算机系统将接收到的交易请求排队。S103:交易平台计算机系统顺序处理排队的交易请求，并在处理一个交易请求的过程中，对支付宝内部帐户上锁。在处理一个交易请求的过程中，对支付宝内部帐户上锁，具体地讲，即在处理一个交易请求时，只允许当前所处理的交易请求对支付宝内部帐户的读写，而禁止其它交易请求对支付宝内部帐户的读写。现有技术上述方式的处理，可以避免前述可能出现异常结果的情况。例如，当前支付宝内部帐户余额为100元，即支付宝内部帐户余额的存储单元中的值为100，线程1需要做的处理为读取余额一将余额加10—更新余额，线程2需要做的处理为读取余额一将余额加5—更新余额。线程1和线程2顺序执行，则线程1执行时，对支付宝内部帐户余额存储单元的读写上锁，而只允许线程l的读写，则线程l的处理过程为读取100—执行100+10—更新为110。这样，线程l执行完毕后，支付宝内部帐户余额存储单元中的值更新为110，并且，对支付宝内部帐户进行解锁，以便后续其它线程可以继续对支付宝帐户执行处理。之后，线程2执行，在线程2执行过程中，对支付宝内部帐户余额存储单元的读写上锁，而只允许线程2的读写，线程2的处理过程为读取110—执行110+5—更新为115。这样，线程2执行完毕后，支付宝内部帐户余额存储单元中的值更新为115。可见，现有技术中上述处理方式解决了支付宝内部帐户可能出现异常结果的问题。但是，上述处理过程中，多个线程排队执行，且每个线程执行过程中，需要锁住内部帐户，这样，其它线程不得不顺序等待，则对于所有交易请求的处理，总的处理时间将延长。而当有大量交易请求时，长时间的交易数据的处理，会持续占用交易平台计算机系统的资源，从而导致交易平台计算机系统在一段期间内处理能力的下降。特别是如果在交易平台计算机系统本身负荷已较重的6情况下执行上述处理，交易平台计算机系统处理能力的下降会影响交易平台同时进行的其它业务的处理，从而降低客户的体验。
发明内容本申请中的实施例的目的是提供一种交易数据处理方法及系统，以降低对交易平台计算机系统处理能力的影响。为解决上述技术问题，本申请中的实施例提供一种交易数据处理方法及系统是这样实现的一种交易数据处理方法帐务管理方法，包括交易平台计算机系统接收用户端发来的交易请求；交易平台计算机系统记录所述交易的账务流水数据；交易平台计算机系统在预定的时间段内利用所述记录的账务流水数据更新集中帐户的余额。优选地，所述交易平台计算机系统记录所述交易的账务流水数据，包括交易平台计算机系统记录所述交易的账务流水数据于集中帐户的分录中；或，交易平台计算机系统记录所述交易的账务流水数据记录于一緩冲表中。优选地，所述交易平台计算机系统记录所述交易的账务流水数据于集中帐户的分录中，包括交易平台计算机系统记录所述交易的账务流水数据于集中帐户的单边分录中；或，交易平台计算机系统记录所述交易的账务流水数据于集中帐户的双边分录中。优选地，所述交易平台计算机系统在预定的时间段内利用所述记录的账务流水数据更新集中帐户的余额，包括交易平台计算机系统在预定的时间段内将所述记录的账务流水数据进行合并，并利用合并后的数据更新集中帐户的余额。优选地，所述交易平台计算机系统在预定的时间段内将所述记录的账务流水数据进行合并，包括交易平台计算机系统在预定的时间段内将所述记录的账务流水数据按照字段分组合并；相应地，所述更新集中帐户的余额包括利用分组合并后的数据更新所述集中帐户的余额。优选地，对于记录账务流水数据和在预定时间段执行更新梯:作分别采用不同的线程独立进行的情况，在进行所述更新集中帐户余额操作过程中，对所述集中账户加锁。一种交易数据处理系统，包括接收单元，用于接收用户端发来的交易请求；记录单元，用于记录所述交易的账务流水凄t据；时间段设置单元，用于设置预定时间段；更新单元，用于在预定的时间段内利用所述账务流水数据更新集中帐户的余额。优选地，所述的系统中，所述记录单元将所述交易的账务流水数据记录于集中帐户的单边分录中或双边分录中，或记录于以独立的緩沖表中。优选地，所述的系统中，还包括合并单元，用于在预定的时间段内将所述记录的账务流水数据合并；相应地，所述更新单元在预定的时间^:内利用合并的账务流水数据更新集中帐户的余额。优选地，所述的系统中，还包括分组单元，用于按照字段将所述记录的账务流水数据分组；相应地，所述合并单元在预定的时间段内将所述分组的账务流水数据合并。优选地，所述的系统中，还包括加锁单元，对于记录账务流水数据和在预定时间段执行更新操作分别采用不同的线程独立进行的情况，用于在进行所述更新集中帐户余额操作过程中，对所述集中账户加锁。由上述本申请实施例可见，交易平台计算机系统接收用户端发来的交易请求，记录所述交易的账务流水数据，在预定的时间段内利用所述记录的账务流水数据更新集中帐户的余额，这样，对于大量交易请求，可以选择在合适的时间段处理交易数据，从而避免由于处理交易数据占用繁忙时段交易平台计算机系统的资源，从而提升交易平台计算机系统在繁忙时间段的处理能力。特别是对于上述采用合并处理交易数据的方式，由于对集中帐户的余额仅更新较少的次数，这样可以有效缩短集中帐户余额的更新时间，从而可以提高处理效率以及交易平台计算机系统处理并发性事物的能力，当然也会提升客户的体验。图1为现有技术中交易数据处理方法的流程图2为本申请交易数据处理方法实施例的流程图；图3为本申请交易数据处理系统一实施例的框图；图4为本申请交易数据处理系统一实施例的框图；图5为本申请交易数据处理系统一实施例的框图。具体实施例方式为了使本
技术领域：
的人员更好地理解本申请方案，下面结合附图和实施方式对本申请实施例作进一步的详细说明。如前所述，支付宝内部帐户一般是固定的，而用户帐户包括大量不同的帐以下介绍本申请交易数据处理方法的第一实施例，图2示出了该实施例的流程，如图2所示S201:交易平台计算机系统接收用户端发来的交易请求。如前所述，交易平台计算机系统接收用户端发来的交易请求，一般包括大量的用户端发来的交易请求。而且，这些用户端往往是随机的。实际当中，以应用在淘宝网的支付宝交易平台计算机系统举例，往往在每个时间段内都收到成千上万(甚至更多)的用户发来的交易请求。这些大量的交易请求中，可以包括用户付款到支付宝内部帐户(如买家购买物品时先打款到支付宝帐户，以及用户为支付宝帐户充值)，用户从支付宝内部帐户提现(如卖家从支付宝帐户提现到银行卡，买家从支付宝帐户的退款中提现到银行卡)等。而交易平台计算机系统，正是用以处理这类大量交易请求的计算机系统。此外，所述交易平台计算机系统接收用户端发来的交易请求，可以是交易平台计算机系统直接接收用户端发来的交易请求，也可以是通过其它中间平台9处理后的交易请求，对于后者，例如可以是支付宝平台计算机系统接收经由淘宝网网站服务器处理一些必要信息后的交易请求。S202:交易平台计算机系统记录所述交易的账务流水数据。在网络交易平台发生众多交易的情况下，集中帐户一般用做资金的中转，且集中帐户的余额通常会保持较大的数额。仍以支付宝交易为例，支付宝交易平台计算机系统接收的大量交易请求后，并不是由支付宝交易平台计算机系统的即时处理即可使交易立刻达成，或者并不需要支付宝交易平台计算机系统的即时处理，而是可能还需要后续的过程，如卖家发货，发货后货物在物流的过程，以及买家收货过程。支付宝交易平台计算机系统一般还对交易限定交易时长，例如买家在付款到支付宝后，支付宝交易平台计算机系统会以买家付款时间为起点设定一段时间的交易时长，如15天的交易时长。这15天内，留作卖家发货、买家收货，买家确认等过程的时间。当然，还存在支付宝内部帐户退款到买家，买家或卖家从支付宝内部帐户中提现到银行帐户等的过程，也是需要由作为用户的买家或卖家提出提现申请后支付宝交易平台计算机系统才进一步处理。基于这一特点，集中帐户只需在一合理的时间段内做一次余额更新即可，而并不需要实时更新。但是，交易平台计算机系统接收到发来的交易请求后，需要记录所述交易的账务流水数据。所谓账务流水数据，是会计学领域公知的常识，其包括交易明细中一系列的发生额。仍如表l中所示，2个用户帐户的发生额+10,-5,所述账务流水数据包括该发生额+10，-5。所述交易平台计算机系统记录所述交易的账务流水数据，可以是记录于集中帐户的分录中，也可以是记录于一緩冲表中。所述记录于集中帐户的分录中，可以如下表2中所示，记录于双边分录中，即在分录的用户帐户和支付宝内部帐户都记载至少包括发生额的账务流水数据用户帐户支付宝内部帐户<table>tableseeoriginaldocumentpage11</column></row><table><table>tableseeoriginaldocumentpage12</column></row><table>表4此外，记录于一緩冲表中，可以如下表5中所示，该表中，利用一单独的緩冲表记录账务流水数据<table>tableseeoriginaldocumentpage12</column></row><table>表5上述仅记录于单边分录中的方式以及记录于緩冲表的方式，由于不需要像现有技术中那样在交易的双方都记录账务流水数据，因此还节省了大量的存储空间。事实上，当需要查询一方的账务流水数据时，可以通过查询对应另一方的账务流水数据实现。这样，通过S202，交易平台计算机系统记录了交易的账务流水数据。S203:交易平台计算机系统在预定的时间段内利用所述记录的账务流水数据更新集中帐户的余额。尽管交易平台计算机系统接收的交易请求数量巨大，但还是存在相对繁忙和空闲的时间段。例如，白天和晚上18点至23点的交易请求数量会明显大于凌晨。而对于逐条账务流水数据都更新余额的情况，由于基于每一条账务流水数据更新余额都需要花费一定的处理时间，因此，可以将这一工作设置在交易平台计算机系统相对空闲的时间段进行，从而可以减轻交易平台计算机系统的总体负荷。例如，在预定的凌晨2:00至2:30这相对空闲的30分钟内利用记录的账务流水数据更新集中帐户的余额。则在预定的时间段内利用所述记录的账务流水数据更新后的集中帐户余额可以如表6中所示<table>tableseeoriginaldocumentpage12</column></row><table><table>tableseeoriginaldocumentpage13</column></row><table>表6从表6中可见，对于记录的账务流水数据中的每一条，都对余额进行了更新。且表6为与前面表2对应的形式，当然，也可以是与前面表3、4分别对应的形式。而对于前述表5，可以将緩冲表中记录的账务流水数据插入到集中帐户的账务流水中，并在预定的时间段内利用所述账务流水数据更新集中帐户的余额。上述S203的方式，尽管选在交易平台计算机系统相对空闲的时间段进行，但是，由于仍是基于每一条账务流水数据更新余额，而基于每一条账务流水数据更新数据都需要花费一定的处理时间，因此，这样的方式，仅就更新数据来讲，仍占用交易平台计算机系统的较多资源。以下给出S203的一种优化的实现方式交易平台计算机系统在预定的时间段内将所述记录的账务流水数据进行合并，并利用合并后的数据更新集中帐户的余额。以下给出几个例子。例如表5中的緩冲表中的数据进行合并后如下表7所示<table>tableseeoriginaldocumentpage13</column></row><table>表7可见，緩沖表中的账务流水数据合并后的发生额最终为22。进而，可以利用合并后的发生额22更新集中帐户的数据，即将22与集中帐户的余额进行合并并更新。例如支付宝内部帐户的余额为100，与22合并后为122，进而，将122更新为支付宝内部帐户的最终余额。当然，对于表2、3、4中的方式，也可以先将账务流水数据进行合并，之后再利用合并后的账务流水数据更新集中帐户的余额，且这种方式与上述方式类似，在此不再赘述。这样的方式，由于预先将账务流水数据进行了合并，最终只利用合并后的发生额更新集中帐户的余额，也就是说，对集中帐户的余额，仅更新了一次，而不像S203前述的方式或现有技术中那样，对于每一条账务流水数据，都更新集中帐户的余额。显然地，这样的方式，即更新一次集中帐户余额的方式，可以有效缩短集中帐户余额的更新时间，从而可以提高处理效率以及交易平台计算机系统处理并发性事物的能力。上述方式中，也可以对集中帐户的分录按照用户帐户ID、交易时间，涉及的银行等字段分组合并，这样可能产生若干个分组合并后的发生额，对于集中帐户余额，对应地，可能需要若干次更新，但仍然大大低于现有方式中逐条分录都进行余额更新的方式。分组合并更新的方式，利于按照不同字段对不同类型业务的分组汇总，从而利于其它查询等的操作。在本申请上述实施例中，记录账务流水数据和在预定时间段执行更新操作，可以采用不同的线程独立进行。这样，在进行更新集中帐户余额操作时，可以对该账户加锁，以防止其它线程的重复处理。由上述本申请实施例可见，交易平台计算机系统接收用户端发来的交易请求，记录所述交易的账务流水数据，在预定的时间段内利用所述记录的账务流水数据更新集中帐户的余额，这样，对于大量交易请求，可以选择在合适的时间段处理交易数据，从而避免由于处理交易数据占用繁忙时段交易平台计算机系统的资源，从而提升交易平台计算机系统在繁忙时间段的处理能力。特别是对于上述采用合并处理交易数据的方式，由于对集中帐户的余额仅更新较少的次数，这样可以有效缩短集中帐户余额的更新时间，从而可以提高处理效率以及交易平台计算机系统处理并发性事物的能力，当然也会提升客户的体验。以下介绍本申请交易数据处理系统的实施例，图3示出了该系统实施例的框图，如图3中，该系统实施例可以包括接收单元31,用于接收用户端发来的交易请求；记录单元32，用于记录所述交易的账务流水数据；时间段设置单元33，用于设置预定时间段；更新单元34,用于在预定的时间段内利用所述账务流水数据更新集中帐户的余额。优选地，所述的系统中，所述记录单元32将所述交易的账务流水H据记录于集中帐户的单边分录中或双边分录中，或记录于以独立的緩冲表中。优选地，如图4所示，所述的系统中还可以包括合并单元35,用于在预定的时间段内将所述记录的账务流水数据合并；相应地，所述更新单元34在预定的时间段内利用合并的账务流水数据更新集中帐户的余额。优选地，如图5所示，所述的系统中还可以包括分组单元36,用于按照字段将所述记录的账务流水数据分组；相应地，所述合并单元35在预定的时间^艮内将所述分组的账务流水it据合并。优选地，如图5所示，所述的系统中还可以包括加锁单元37，对于记录单元32记录账务流水数据和更新单元34在预定时间段执行更新操作分别采用不同的线程独立进行的情况，用于在进行所述更新集中帐户余额操作过程中，对所述集中账户加锁。为了描述的方便，以上所述系统的各部分以功能分为各种单元分别描述。当然，在实施本发明时可以把各单元的功能在同一个或多个软件或硬件中实现。通过以上的实施方式的描述可知，本领域的4支术人员可以清楚地了解到本申请中的实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请中的实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请中的各个实施例或者实施例的某些部分所述的方法。本说明书中，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。本申请中的实施例可用于众多通用或专用的计算系统环境或配置中。例如个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本申请中的实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、凄t据结构等等。也可以在分布式计算环境中实践本申请中的实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。权利要求1、一种交易数据处理方法，其特征在于，包括交易平台计算机系统接收用户端发来的交易请求；交易平台计算机系统记录所述交易的账务流水数据；交易平台计算机系统在预定的时间段内利用所述记录的账务流水数据更新集中帐户的余额。2、根据权利要求1所述的方法，其特征在于，所述交易平台计算机系统记录所述交易的账务流水数据，包括交易平台计算机系统记录所述交易的账务流水数据于集中帐户的分录中；或，交易平台计算机系统记录所述交易的账务流水数据记录于一緩沖表中。3、根据权利要求2所述的方法，其特征在于，所述交易平台计算机系统记录所述交易的账务流水凝:据于集中帐户的分录中，包括交易平台计算机系统记录所述交易的账务流水数据于集中帐户的单边分录中；或，交易平台计算机系统记录所述交易的账务流水数据于集中帐户的双边分录中。4、根据权利要求2所述的方法，其特征在于，所述交易平台计算机系统在预定的时间段内利用所述记录的账务流水数据更新集中帐户的余额，包括交易平台计算机系统在预定的时间段内将所述记录的账务流水数据进行合并，并利用合并后的数据更新集中帐户的余额。5、根据权利要求1所述的方法，其特征在于，所述交易平台计算机系统在预定的时间段内将所述记录的账务流水数据进行合并，包括交易平台计算机系统在预定的时间段内将所述记录的账务流水数据按照字段分组合并；相应地，所述更新集中帐户的余额包括利用分组合并后的数据更新所述集中帐户的余额。6、根据权利要求1所述的方法，其特征在于，对于记录账务流水数据和在预定时间段执行更新操作分别采用不同的线程独立进行的情况，在进行所述更新集中帐户余额操作过程中，对所述集中账户加锁。7、一种交易数据处理系统，其特征在于，包括接收单元，用于接收用户端发来的交易请求；记录单元，用于记录所述交易的账务流水^:据；时间段设置单元，用于设置预定时间段；更新单元，用于在预定的时间段内利用所述账务流水数据更新集中帐户的余额。8、如权利要求7所述的系统，其特征在于，所述记录单元将所述交易的账务流水数据记录于集中帐户的单边分录中或双边分录中，或记录于以独立的緩冲表中。9、如权利要求7所述的系统，其特征在于，还包括合并单元，用于在预定的时间段内将所述记录的账务流水数据合并；相应地，所述更新单元在预定的时间段内利用合并的账务流水数据更新集中帐户的余额。10、如权利要求8所述的系统，其特征在于，还包括分组单元，用于按照字段将所述记录的账务流水数据分组；相应地，所述合并单元在预定的时间段内将所述分组的账务流水数据合并。11、如权利要求7所述的系统，其特征在于，还包括加锁单元，对于记录账务流水数据和在预定时间段执行更新操作分别采用不同的线程独立进行的情况，用于在进行所述更新集中帐户余额操作过程中，对所述集中账户加锁。全文摘要交易数据处理方法及系统。一种交易数据处理方法实施例，包括交易平台计算机系统接收用户端发来的交易请求；交易平台计算机系统记录所述交易的账务流水数据；交易平台计算机系统在预定的时间段内利用所述记录的账务流水数据更新集中帐户的余额。利用本发明，可以避免由于处理交易数据占用繁忙时段交易平台计算机系统的资源，从而提升交易平台计算机系统在繁忙时间段的处理能力。文档编号G06Q30/00GK101477667SQ20091000553公开日2009年7月8日申请日期2009年1月19日优先权日2009年1月19日发明者于新林申请人:阿里巴巴集团控股有限公司