CN107038617A - 支付订单的预创建方法及装置 - Google Patents

支付订单的预创建方法及装置 Download PDF

Info

Publication number
CN107038617A
CN107038617A CN201710038512.0A CN201710038512A CN107038617A CN 107038617 A CN107038617 A CN 107038617A CN 201710038512 A CN201710038512 A CN 201710038512A CN 107038617 A CN107038617 A CN 107038617A
Authority
CN
China
Prior art keywords
order
paid
order number
database
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201710038512.0A
Other languages
English (en)
Other versions
CN107038617B (zh
Inventor
谢清
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced Nova Technology Singapore Holdings Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to CN201710038512.0A priority Critical patent/CN107038617B/zh
Publication of CN107038617A publication Critical patent/CN107038617A/zh
Application granted granted Critical
Publication of CN107038617B publication Critical patent/CN107038617B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请涉及互联网支付领域，尤其涉及一种支付订单的预创建方法及装置，在一种支付订单的预创建方法中，支付系统在接收到商户系统发送的订单创建请求时，创建相应的预支付订单，并将该预支付订单存储在第一数据库中。之后，当满足预设的数据同步条件时，将第一数据库中的预支付订单同步至第二数据库中。也即本申请中，在创建预支付订单之后，将该预支付订单存储在第一数据库中，从而可以避免传统技术中，将预支付订单存储在缓存中而可能会造成预支付订单丢失的问题。此外，在同步前后，预支付订单都是存储在数据库中的，也即可以通过相同的逻辑来实现同步前后预支付订单的操作，从而可以降低设计成本以及复杂度。

Description

支付订单的预创建方法及装置
技术领域
本申请涉及互联网支付领域，尤其涉及一种支付订单的预创建方法及装置。
背景技术
传统技术中，支付系统在根据商户系统发送的订单创建请求，创建预支付订单后，将该预支付订单存储在缓存中。在对上述预支付订单执行相应的操作(如，支付结果处理或者关闭)之后，当预支付订单处于终态时，将预支付订单更新为正式支付订单，并将正式支付订单存储在数据库中。然而，由于缓存为非持久性存储，存在断电丢失和老数据被新数据替换的可能，因此上述方法会存在预支付订单丢失的问题。此外，上述方法中向缓存中存储数据与向数据库中存储数据为两种完全不同的方案，需要通过两套完全不同的逻辑来实现，这增加了设计成本和设计复杂度。
发明内容
本申请描述了一种支付订单的预创建方法及装置，可以提高创建的支付订单的可靠性。
第一方面，提供了一种支付订单的预创建方法，包括：
接收商户系统发送的订单创建请求，所述订单创建请求包括订单数据；
根据所述订单数据，生成预支付订单，所述预支付订单包含第一订单号，所述第一订单号是优先根据买家用户标识确定的；
将所述预支付订单存储在第一数据库中；
当满足预设的数据同步条件时，将所述第一数据库中的预支付订单同步至第二数据库中。
第二方面，提供了一种支付订单的预创建装置，包括：
接收单元，用于接收商户系统发送的订单创建请求，所述订单创建请求包括订单数据；
生成单元，用于根据所述接收单元接收的所述订单数据，生成预支付订单，所述预支付订单包含第一订单号，所述第一订单号是优先根据买家用户标识确定的；
存储单元，用于将所述生成单元生成的所述预支付订单存储在第一数据库中；
同步单元，用于当满足预设的数据同步条件时，将所述第一数据库中的预支付订单同步至第二数据库中。
本申请提供的支付订单的预创建方法及装置，支付系统在接收到商户系统发送的订单创建请求时，创建相应的预支付订单，并将该预支付订单存储在第一数据库中。之后，当满足预设的数据同步条件时，将第一数据库中的预支付订单同步至第二数据库中。也即本申请中，在创建预支付订单之后，将该预支付订单存储在第一数据库中，从而可以避免传统技术中，将预支付订单存储在缓存中而可能会造成预支付订单丢失的问题。此外，在同步前后，预支付订单都是存储在数据库中的，也即可以通过相同的逻辑来实现同步前后预支付订单的操作，从而可以降低设计成本以及复杂度。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1为本申请提供的支付订单的预创建方法的应用场景示意图；
图2本申请一种实施例提供的支付订单的预创建方法流程图；
图3为本申请提供的预支付订单的同步方法流程图；
图4为本申请提供的预支付订单的操作流程图；
图5为本申请另一种实施例提供的支付订单的预创建装置示意图。
具体实施方式
下面结合附图，对本申请的实施例进行描述。
图1为本申请提供的支付订单的预创建方法的应用场景示意图，图1中，商户系统(如，淘宝网、天猫等)可以接收用户的下单请求，并根据该下单请求，生成相应的订单数据。其中，该订单数据可以包括：商户标识(identifier，id)、商户订单号、商品信息以及交易金额等。此外，该订单数据还可以包括买家用户标识(简称：买家id)等。商户系统在生成相应的订单数据之后，可以向支付系统(如，支付宝等)发送订单创建请求，该订单创建请求可以包括上述订单数据。支付系统在接收到订单数据之后，可以根据订单数据，生成预支付订单。具体地，当订单数据包括买家id时，支付系统可以先根据买家id确定第一订单号，之后再根据第一订单号和订单数据生成预支付订单；当订单数据不包括买家id时，支付系统可以先根据预设的用户标识确定第一订单号，之后再根据第一订单号、预设的用户标识以及订单数据生成预支付订单。可以理解的是，本申请的预支付订单包含的第一订单号可以是根据买家用户标识确定，也可以是根据预设的用户标识确定。因为预设的用户标识并非是实际的买家用户标识，所以将上述过程中生成的支付订单称为“预支付订单”，上述第一订单号可以称为“预支付订单号”。
图1中，支付系统在生成预支付订单之后，可以将该预支付订单存储在第一数据库(也称预创建库)中。在对上述预支付订单执行相应的操作(如，支付结果处理或者关闭)之后，当预支付订单处于终态时，将预支付订单同步至第二数据库(也称正式库)中。此处，第一数据库和第二数据库可以具有相同的表结构，也即该两个数据库可以具有相同的字段内容，从而本申请可以通过相同的逻辑来实现向不同的数据库中存储预支付订单，由此，可以降低设计成本以及复杂度。
图2本申请一种实施例提供的支付订单的预创建方法流程图。所述方法的执行主体可以为具有处理能力的设备：服务器或者系统或者装置，如，图1中的支付系统，如图2所示，所述方法具体包括：
步骤210，接收商户系统发送的订单创建请求。
此处的商户系统可以是指任一可以购买商品的电子商务网站，如，淘宝网或者天猫等。具体地，用户可以通过商户系统浏览商品，并执行下单操作。在接收到用户执行下单操作的操作指令时，商户系统可以生成订单数据。该订单数据可以包括：商户id、商户订单号、商品信息以及交易金额等。此外，在用户已登录支付系统的情况下，该订单数据还可以包括买家用户标识(简称：买家id)等。
在生成订单数据之后，商户系统可以向支付系统发送订单创建请求。该订单创建请求可以包括上述订单数据。
步骤220，根据订单数据，生成预支付订单。
此处的预支付订单可以包含第一订单号，其中，第一订单号是优先根据买家用户标识确定的。
支付系统在接收到商户系统发送的订单创建请求之后，也即在获取到订单数据之后，可以判断订单数据是否包括买家用户标识。若订单数据包括买家用户标识，则可以根据买家用户标识，确定第一订单号。在一种实现方式中，可以结合买家用户标识以及预设规则，确定第一订单号。在确定第一订单号之后，可以根据第一订单号以及订单数据，生成预支付订单。可以理解的是，生成的预支付订单可以包含上述第一订单号、买家用户标识以及商户id、商户订单号、商品信息以及交易金额等信息。
若订单数据不包括买家用户标识，则可以根据预设的用户标识，确定第一订单号。此处的预设的用户标识可以是预先设置的网关账号，其与买家用户标识具有相同的特征：如，均由预设数量的字符或者数字构成。同样的，支付系统可以结合预设的用户标识以及预设规则，来确定第一订单号。在确定第一订单号之后，根据第一订单号、预设的用户标识以及订单数据，生成预支付订单。可以理解的是，生成的预支付订单可以包含上述第一订单号、预设的用户标识以及商户id、商户订单号、商品信息以及交易金额等信息。
需要说明的是，上述结合买家用户标识/预设的用户标识以及预设规则，确定第一订单号的过程为传统常规技术，在此不复赘述。
在一个例子中，上述第一订单号可以由35位数字构成。由于该第一订单号被称为“预支付订单号”，所以其可以具有与正式订单号(如，下文中的第二订单号)不同的标识信息，如，第一订单号具有第一标识信息(如，0)，第二订单号具有第二标识信息(如，1)。在一种实现方式中，可以将第一订单号的第20位设为1，而将第二订单号的第20位设为1，以此来区分上述第一订单号与第二订单号。
步骤230，将预支付订单存储在第一数据库中。
此处的第一数据库可以是根据待存储的预支付订单所包含的信息设计的。在一个例子中，第一数据库的表结构可以表1所示。
表1
预支付订单号 标识信息 商户id 商户订单号 商品信息 交易金额
需要说明的是，表1中字段“预支付订单号”的内容为第一订单号。字段“标识信息”的内容可以是买家用户标识，也可以是预设的用户标识。可以理解的是，表1中各字段的内容即可构成预支付订单。
当然，表1只是一种示例性说明，在实际应用中，表1中还可以包括其它字段，比如，交易时间，操作日志以及冻结解冻记录等，本申请对此不作限定。
步骤240，当满足预设的数据同步条件时，将第一数据库中的预支付订单同步至第二数据库中。
上述预设的数据同步条件可以包括：预支付订单的状态为终态等。在一个例子中，当对预支付订单执行支付结果处理或者关闭等操作时，该预支付订单的状态为终态。
需要说明的是，本申请中，第二数据库可以与第一数据库具有相同的表结构，也即第二数据库的表结构也可以如表1所示。在第二数据库与第一数据库具有相同的表结构的情况下，上述步骤230与步骤240就可以通过相同的逻辑来实现。从而可以避免传统技术中，需要通过不同的逻辑来实现向缓存(以key_value的形式存储数据)中缓存预支付订单以及向数据库中存储更新后的预支付订单而造成的设计成本高、设计复杂度大的问题。此外，当第二数据库与第一数据库具有相同的表结构时，还可以提高支付订单的预创建效率。
举例来说，在对预支付订单执行支付结果处理操作之后，支付系统可以获取到处理结果信息。在获取到该处理结果信息之后，支付系统可以将预支付订单的状态切换为终态，从而满足了预设的数据同步条件。在满足预设的数据同步条件时，可以先对预支付订单进行更新，之后再将更新后的预支付订单存储到第二数据库中，其具体可以通过如图3所示的各步骤来实现：
步骤310，获取买家用户标识。
该买家用户标识可以包含在上述处理结果信息中，此外，还可以包含在商户系统向支付系统发送的关闭指令中。
步骤320，对第一数据库执行锁定操作。
在一个例子中，可以通过“LOCK”指令来实现对第一数据库的锁定操作。
步骤330，从执行锁定操作后的第一数据库中读取预支付订单。
以第一数据库如表1所示为例来说，可以从表1中读取各字段的内容。
步骤340，根据买家用户标识，确定第二订单号。
此处，可以结合步骤310中获取的买家用户标识以及预设规则，来确定第二订单号。其确定过程可参考传统支付订单中订单号的生成过程，在此不复赘述。需要说明的是，此处的第二订单号具有与上述第一订单号不同的标识信息，该第二订单号可以称为“正式订单号”。
步骤350，根据买家用户标识以及第二订单号，更新预支付订单。
其中，更新预支付订单的过程可以为：将从表1中读取的字段“标识信息”的内容替换为步骤310中获取的买家用户标识，且将从表1中读取的字段“预支付订单”的内容更新为步骤340中确定的第二订单号。可以理解的是，更新后的预支付订单即为实实在在的支付订单，因此，更新后的预支付订单也可以称为“正式支付订单”。
步骤360，将更新后的预支付订单存储到第二数据库中。
也即将正式支付订单存储到第二数据库中。
步骤370，保存第一订单号与第二订单号的对应关系。
在一种实现方式中，上述第一订单号与第二订单号的对应关系可以存储在映射表中，该映射表的表结构可以如表2所示。
表2
商户id 商户订单号 第一订单号 第二订单号
需要说明的是，该映射表可以是第一数据库中的其它表结构。具体地，上述字段“商户id”、“商户订单号”以及“第一订单号”的内容可以是在将预支付订单存储在第一数据库的过程中写入表1的，而字段“第二订单号”的内容则可以是在步骤370之后写入表1的。
此外，图3中，步骤310-步骤330可以由第一事务执行，而步骤340-步骤360可以由第二事务执行，由此来提高预支付订单同步的效率。
可选地，在将第一数据库中的预支付订单同步至第二数据库之后，还可以对上述预支付订单执行如下操作：支付结果处理操作、关闭操作、冻结操作以及解冻操作等。其操作流程可以如图4所示：
步骤410，接收订单操作请求。
此处的订单操作请求可以是由支付系统内部发起，也可以是从商户系统接收的。其可以包括目标订单号，其中，该目标订单号的定义同上述第一订单号或者第二订单号的定义相同，在此不复赘述。
步骤420，当目标订单号与第二订单号相匹配时，根据目标订单号，从第二数据库中读取对应的预支付订单并执行相应的操作。
此处，目标订单号与第二订单号相匹配可以包括：目标订单号与第一订单的标识位具有相同的标识信息，如，目标订单号的标识位(如，第20位)为1。在目标订单号与第二订单号相匹配时，说明该目标订单号是根据实际的买家用户标识确定的，因此，可以直接从二数据库中读取对应的预支付订单并执行相应的操作。
步骤430，当目标订单号与第一订单号相匹配时，根据目标订单号，从第一订单号与第二订单号的对应关系中查找对应的第二订单号。
步骤440，若查找到第二订单号，则根据第二订单号，从第二数据库中读取对应的预支付订单并执行相应的操作。
步骤450，若查找不到第二订单号，则根据目标订单号，从第一数据库中读取对应的预支付订单并执行相应的操作。
同理，目标订单号与第一订单号相匹配可以包括：目标订单号与第二订单的标识位具有相同的标识信息，如，目标订单号的标识位(如，第20位)为0。在目标订单号与第一订单号相匹配时，则可以先从表2中查找对应的第二订单号。若查找到第二订单号，则说明已将预支付订单从第一数据库同步至第二数据库，因此，可以根据第二订单号从第二数据库中读取对应的预支付订单并执行相应的操作。而若查找不到第二订单号，则说明还未将预支付订单从第一数据库同步至第二数据库，因此，只能根据目标订单号从第一数据库中读取对应的预支付订单并执行相应的操作。
从图4各步骤可以看出，在将预支付订单从第一数据库同步至第二数据库，且建立第一订单号与第二订单号的对应关系之后，所有的操作请求均会路由至第二数据库，为减小数据库容量成本，在业务低峰期可以开启调度任务删除第一数据库中的预支付订单。
此外，本申请的技术方案还可以克服传统技术的如下缺点：
1)无法保证事务的原子性的问题。举例来说，当将预支付订单存储在缓存中时，对预支付订单执行冻结操作的操作流程如下：a，接收冻结订单操作请求，该请求包括预支付订单号。b，判断缓存中是否存在预支付订单号对应的正式订单号。c，如果存在，则从数据库中加载正式支付订单，并对正式支付订单执行冻结操作。d，如果不存在，则从缓存中获取预支付订单。e，更新预支付订单的状态为冻结状态。f，生成冻结单。g，将预支付订单和冻结单保存于缓存中。h，更新消费记录，显示预支付订单已冻结。在上述冻结操作的操作流程中，由于步骤g和步骤h由不同的事务执行，因此当步骤g执行成功，而步骤h执行失败时，无法同时执行回滚操作。从而会造成预支付订单已冻结成功，但消费记录中显示预支付订单未冻结的问题，由此会大大影响用户的体验。
2)无法有效的解决并发问题。传统技术中，对于预支付订单的操作(包括冻结操作、解冻操作、关闭操作、支付结果处理操作等)，都需要首先判断缓存中是否存在预支付订单号对应的正式订单号，因此缓存中预支付订单号与正式订单号的对应关系为并发共享资源，然而并没有合适的方案可以对该共享资源进行加锁控制以避免并发问题。
与上述支付订单的预创建方法对应地，本申请实施例还提供的一种支付订单的预创建装置，如图5所示，该装置包括：
接收单元501，用于接收商户系统发送的订单创建请求，该订单创建请求包括订单数据。
生成单元502，用于根据接收单元501接收的订单数据，生成预支付订单，该预支付订单包含第一订单号，第一订单号是优先根据买家用户标识确定的。
可选地，生成单元502具体可以用于：
判断订单数据是否包括买家用户标识。
若订单数据包括买家用户标识，则根据买家用户标识，确定第一订单号；并根据第一订单号以及订单数据，生成预支付订单。
若订单数据不包括买家用户标识，则根据预设的用户标识，确定第一订单号；并根据第一订单号、预设的用户标识以及订单数据，生成预支付订单。
存储单元503，用于将生成单元502生成的预支付订单存储在第一数据库中。
同步单元504，用于当满足预设的数据同步条件时，将第一数据库中的预支付订单同步至第二数据库中。
可选地，同步单元504具体可以用于：
获取买家用户标识。
对第一数据库执行锁定操作。
从执行锁定操作后的第一数据库中读取预支付订单。
根据买家用户标识，确定第二订单号。
根据买家用户标识以及第二订单号，更新预支付订单。
将更新后的预支付订单存储到第二数据库中，并保存第一订单号与所述第二订单号的对应关系。
可选地，该装置还可以包括：读取单元505和查找单元506。
接收单元501，还用于接收订单操作请求，该订单操作请求包括目标订单号。
读取单元505，用于当接收单元501接收的目标订单号与第二订单号相匹配时，根据目标订单号，从第二数据库中读取对应的预支付订单并执行相应的操作。
查找单元506，用于当目标订单号与第一订单号相匹配时，根据目标订单号，从第一订单号与第二订单号的对应关系中查找对应的第二订单号。
读取单元505，还用于若查找到所述第二订单号，则根据第二订单号，从第二数据库中读取对应的预支付订单并执行相应的操作。
读取单元505，还用于若查找不到第二订单号，则根据目标订单号，从第一数据库中读取对应的预支付订单并执行相应的操作。
可选地，该装置还可以包括：
删除单元507，用于删除第一数据库中的预支付订单。
本申请实施例装置的各功能模块的功能，可以通过上述方法实施例的各步骤来实现，因此，本申请提供的装置的具体工作过程，在此不复赘述。
本申请提供的支付订单的存储装置，接收单元501接收商户系统发送的订单创建请求。生成单元502根据订单数据，生成预支付订单。存储单元503将预支付订单存储在第一数据库中。当满足预设的数据同步条件时，同步单元504将第一数据库中的预支付订单同步至第二数据库中。由此，可以提高支付订单存储的可靠性。
需要说明的是，本申请实施例提供的支付订单的存储装置可以是图1的支付系统中的一个功能模块。
本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。
以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。

Claims (10)

1.一种支付订单的预创建方法，其特征在于，包括：
接收商户系统发送的订单创建请求，所述订单创建请求包括订单数据；
根据所述订单数据，生成预支付订单，所述预支付订单包含第一订单号，所述第一订单号是优先根据买家用户标识确定的；
将所述预支付订单存储在第一数据库中；
当满足预设的数据同步条件时，将所述第一数据库中的预支付订单同步至第二数据库中。
2.根据权利要求1所述的方法，其特征在于，所述根据所述订单数据，生成预支付订单，包括：
判断所述订单数据是否包括所述买家用户标识；
若所述订单数据包括所述买家用户标识，则根据所述买家用户标识，确定所述第一订单号；并根据所述第一订单号以及所述订单数据，生成所述预支付订单；
若所述订单数据不包括所述买家用户标识，则根据所述预设的用户标识，确定所述第一订单号；并根据所述第一订单号、所述预设的用户标识以及所述订单数据，生成所述预支付订单。
3.根据权利要求1所述的方法，其特征在于，所述将所述第一数据库中的预支付订单同步至第二数据库中，包括：
获取买家用户标识；
对所述第一数据库执行锁定操作；
从执行锁定操作后的第一数据库中读取所述预支付订单；
根据所述买家用户标识，确定第二订单号；
根据所述买家用户标识以及所述第二订单号，更新所述预支付订单；
将更新后的预支付订单存储到所述第二数据库中，并保存所述第一订单号与所述第二订单号的对应关系。
4.根据权利要求3所述的方法，其特征在于，还包括：
接收订单操作请求，所述订单操作请求包括目标订单号；
当所述目标订单号与所述第二订单号相匹配时，根据所述目标订单号，从所述第二数据库中读取对应的预支付订单并执行相应的操作；
当所述目标订单号与所述第一订单号相匹配时，根据所述目标订单号，从所述第一订单号与所述第二订单号的对应关系中查找对应的第二订单号；
若查找到所述第二订单号，则根据所述第二订单号，从所述第二数据库中读取对应的预支付订单并执行相应的操作；
若查找不到所述第二订单号，则根据所述目标订单号，从所述第一数据库中读取对应的预支付订单并执行相应的操作。
5.根据权利要求3所述的方法，其特征在于，还包括：
删除所述第一数据库中的所述预支付订单。
6.一种支付订单的预创建装置，其特征在于，包括：
接收单元，用于接收商户系统发送的订单创建请求，所述订单创建请求包括订单数据；
生成单元，用于根据所述接收单元接收的所述订单数据，生成预支付订单，所述预支付订单包含第一订单号，所述第一订单号是优先根据买家用户标识确定的；
存储单元，用于将所述生成单元生成的所述预支付订单存储在第一数据库中；
同步单元，用于当满足预设的数据同步条件时，将所述第一数据库中的预支付订单同步至第二数据库中。
7.根据权利要求6所述的装置，其特征在于，所述生成单元具体用于：
判断所述订单数据是否包括所述买家用户标识；
若所述订单数据包括所述买家用户标识，则根据所述买家用户标识，确定所述第一订单号；并根据所述第一订单号以及所述订单数据，生成所述预支付订单；
若所述订单数据不包括所述买家用户标识，则根据所述预设的用户标识，生成所述第一订单号；并根据所述第一订单号、所述预设的用户标识以及所述订单数据，生成所述预支付订单。
8.根据权利要求6所述的装置，其特征在于，所述同步单元具体用于：
获取买家用户标识；
对所述第一数据库执行锁定操作；
从执行锁定操作后的第一数据库中读取所述预支付订单；
根据所述买家用户标识，确定第二订单号；
根据所述买家用户标识以及所述第二订单号，更新所述预支付订单；
将更新后的预支付订单存储到所述第二数据库中，并保存所述第一订单号与所述第二订单号的对应关系。
9.根据权利要求8所述的装置，其特征在于，还包括：读取单元和查找单元；
所述接收单元，还用于接收订单操作请求，所述订单操作请求包括目标订单号；
所述读取单元，用于当所述接收单元接收的所述目标订单号与所述第二订单号相匹配时，根据所述目标订单号，从所述第二数据库中读取对应的预支付订单并执行相应的操作；
所述查找单元，用于当所述目标订单号与所述第一订单号相匹配时，根据所述目标订单号，从所述第一订单号与所述第二订单号的对应关系中查找对应的第二订单号；
所述读取单元，还用于若查找到所述第二订单号，则根据所述第二订单号从所述第二数据库中读取对应的预支付订单并执行相应的操作；
所述读取单元，还用于若查找不到所述第二订单号，则根据所述目标订单号从所述第一数据库中读取对应的预支付订单并执行相应的操作。
10.根据权利要求8所述的装置，其特征在于，还包括：
删除单元，用于删除所述第一数据库中的所述预支付订单。
CN201710038512.0A 2017-01-19 2017-01-19 支付订单的预创建方法及装置 Active CN107038617B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710038512.0A CN107038617B (zh) 2017-01-19 2017-01-19 支付订单的预创建方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710038512.0A CN107038617B (zh) 2017-01-19 2017-01-19 支付订单的预创建方法及装置

Publications (2)

Publication Number Publication Date
CN107038617A true CN107038617A (zh) 2017-08-11
CN107038617B CN107038617B (zh) 2021-06-29

Family

ID=59530989

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710038512.0A Active CN107038617B (zh) 2017-01-19 2017-01-19 支付订单的预创建方法及装置

Country Status (1)

Country Link
CN (1) CN107038617B (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109241110A (zh) * 2018-08-24 2019-01-18 北京京东尚科信息技术有限公司 订单管理方法及系统、电子设备、存储介质
CN109308653A (zh) * 2018-10-16 2019-02-05 翟红鹰 避免客户端访问服务器拥堵的方法、终端及存储介质

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005071138A (ja) * 2003-08-26 2005-03-17 Bank Of Tokyo-Mitsubishi Ltd 資金移動管理システム
CN101162517A (zh) * 2006-10-11 2008-04-16 中国民生银行股份有限公司 基于订单的支付信息处理方法
CN101414375A (zh) * 2008-12-15 2009-04-22 阿里巴巴集团控股有限公司 利用中间平台进行网上交易的系统及网上交易方法
CN101533495A (zh) * 2009-04-15 2009-09-16 候万春 一种订单与支付分离的安全支付系统和安全支付方法
JP2010244155A (ja) * 2009-04-02 2010-10-28 Shin Nikkei Co Ltd 防犯センサ付きサッシの発注・受注・納品システム
CN102902812A (zh) * 2012-10-22 2013-01-30 飞天诚信科技股份有限公司 一种数据库远程同步的实现方法
US8645222B1 (en) * 2009-03-20 2014-02-04 Jpmorgan Chase Bank, N.A. System and methods for mobile ordering and payment
CN104299135A (zh) * 2014-09-27 2015-01-21 武钢集团昆明钢铁股份有限公司 一种在线支付系统与方法
CN104331501A (zh) * 2014-11-19 2015-02-04 广东花生信息科技有限公司 一种多平台的数据更新方法
CN106204000A (zh) * 2016-07-05 2016-12-07 康存乐付保数据科技（上海）有限公司 一种服务消费支付信息处理方法及系统

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005071138A (ja) * 2003-08-26 2005-03-17 Bank Of Tokyo-Mitsubishi Ltd 資金移動管理システム
CN101162517A (zh) * 2006-10-11 2008-04-16 中国民生银行股份有限公司 基于订单的支付信息处理方法
CN101414375A (zh) * 2008-12-15 2009-04-22 阿里巴巴集团控股有限公司 利用中间平台进行网上交易的系统及网上交易方法
US8645222B1 (en) * 2009-03-20 2014-02-04 Jpmorgan Chase Bank, N.A. System and methods for mobile ordering and payment
JP2010244155A (ja) * 2009-04-02 2010-10-28 Shin Nikkei Co Ltd 防犯センサ付きサッシの発注・受注・納品システム
CN101533495A (zh) * 2009-04-15 2009-09-16 候万春 一种订单与支付分离的安全支付系统和安全支付方法
CN102902812A (zh) * 2012-10-22 2013-01-30 飞天诚信科技股份有限公司 一种数据库远程同步的实现方法
CN104299135A (zh) * 2014-09-27 2015-01-21 武钢集团昆明钢铁股份有限公司 一种在线支付系统与方法
CN104331501A (zh) * 2014-11-19 2015-02-04 广东花生信息科技有限公司 一种多平台的数据更新方法
CN106204000A (zh) * 2016-07-05 2016-12-07 康存乐付保数据科技（上海）有限公司 一种服务消费支付信息处理方法及系统

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
张成远: "《http://www.100ec.cn/detail--6126492.html》", 27 September 2013 *
曾超宇等: "《Redis在高速缓存系统中的应用》", 《微型机与应用》 *
朱亚兴等: "《基于Redis+MySQL+MongoDB 存储架构应用》", 《微型机与应用》 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109241110A (zh) * 2018-08-24 2019-01-18 北京京东尚科信息技术有限公司 订单管理方法及系统、电子设备、存储介质
CN109308653A (zh) * 2018-10-16 2019-02-05 翟红鹰 避免客户端访问服务器拥堵的方法、终端及存储介质
CN109308653B (zh) * 2018-10-16 2022-04-22 牡丹国际商品交易中心有限公司 避免客户端访问服务器拥堵的方法、终端及存储介质

Also Published As

Publication number Publication date
CN107038617B (zh) 2021-06-29

Similar Documents

Publication Publication Date Title
CN109359222B (zh) 数据存储方法及系统、设备和存储介质
CN109542980B (zh) 一种区块链的数据处理方法、装置、设备及介质
US7383289B2 (en) Updating and maintaining data in a multi-system network using asynchronous message transfer
CN108664650B (zh) 一种区块链网络的事务处理方法、装置、设备及存储介质
US10459978B2 (en) Distributed graph processing system that support remote data read with proactive bulk data transfer
CN107766080B (zh) 事务消息处理方法、装置、设备及系统
US9507821B2 (en) Mail indexing and searching using hierarchical caches
US20110202744A1 (en) Hashing with hardware-based reorder using duplicate values
US20160080383A1 (en) Recovery from rolling security token loss
WO2022121346A1 (zh) 钱包找回方法、设备和存储介质
CN109716324A (zh) 存储器内数据库中的直接表关联
CN106326499B (zh) 一种数据处理方法及装置
CN110737682A (zh) 一种缓存操作方法、装置、存储介质和电子设备
KR102172903B1 (ko) 블록체인 기술 기반 데이터 베이스 관리 시스템
US8782375B2 (en) Hash-based managing of storage identifiers
US20160335371A1 (en) System and method for querying graphs distributed over multiple machines
CN108108486A (zh) 一种数据表查询方法、装置、终端设备及存储介质
US10289345B1 (en) Contention and metadata write amplification reduction in log structured data storage mapping
US20110264991A1 (en) Method and System for Management of Electronic Mail Communication
CN107038617A (zh) 支付订单的预创建方法及装置
JPWO2020152893A1 (ja) 改ざん検知性を有するデータ管理システム
US10942892B2 (en) Transport handling of foreign key checks
CN112445783A (zh) 一种用于数据库更新的方法、装置和服务器
US8533398B2 (en) Combination based LRU caching
US8856946B2 (en) Security filter for context-based data gravity wells

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1241535

Country of ref document: HK

TA01 Transfer of patent application right

Effective date of registration: 20200925

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Applicant after: Innovative advanced technology Co.,Ltd.

Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Applicant before: Advanced innovation technology Co.,Ltd.

Effective date of registration: 20200925

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Applicant after: Advanced innovation technology Co.,Ltd.

Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands

Applicant before: Alibaba Group Holding Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20240222

Address after: Guohao Times City # 20-01, 128 Meizhi Road, Singapore

Patentee after: Advanced Nova Technology (Singapore) Holdings Ltd.

Country or region after: Singapore

Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Patentee before: Innovative advanced technology Co.,Ltd.

Country or region before: United Kingdom

TR01 Transfer of patent right