CN106599169B - 网络交易中购买请求的处理方法和处理装置 - Google Patents

网络交易中购买请求的处理方法和处理装置 Download PDF

Info

Publication number
CN106599169B
CN106599169B CN201611131369.1A CN201611131369A CN106599169B CN 106599169 B CN106599169 B CN 106599169B CN 201611131369 A CN201611131369 A CN 201611131369A CN 106599169 B CN106599169 B CN 106599169B
Authority
CN
China
Prior art keywords
information
purchase
purchased
limited
database
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.)
Active
Application number
CN201611131369.1A
Other languages
English (en)
Other versions
CN106599169A (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.)
Beijing Qihoo Technology Co Ltd
Original Assignee
Beijing Qihoo Technology Co 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 Beijing Qihoo Technology Co Ltd filed Critical Beijing Qihoo Technology Co Ltd
Priority to CN201611131369.1A priority Critical patent/CN106599169B/zh
Publication of CN106599169A publication Critical patent/CN106599169A/zh
Application granted granted Critical
Publication of CN106599169B publication Critical patent/CN106599169B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • 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
    • G06Q30/0637—Approvals

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明提供了网络交易中购买请求的处理方法和处理装置，该方法包括：接收包含用户标识信息和待购买信息的购买请求；查询缓存数据库中是否存在与用户标识信息和待购买信息对应的已购买信息和限制购买信息；基于所述已购买信息，判断所述购买请求是否匹配所述限制购买信息；若判断所述购买请求匹配所述限制购买信息，则拒绝所述购买请求。基于本发明的技术方案实现了对用户购买促销商品的限制，避免如促销商品的销售量超过商家的预定促销商品销售量、促销商品的销售时间与商家的预定促销时段不相符合等情况给商家造成经济损失的状况。

Description

网络交易中购买请求的处理方法和处理装置
技术领域
本发明涉及计算机领域，具体而言，本发明涉及一种网络交易中购买请求的处理方法和一种网络交易中购买请求的处理装置。
背景技术
随着互联网的发展，电子商务也得到了相应的快速发展，给人们的生活带了许多的便利，特别是网络购物的普及，使其逐渐成为人们生活中的一种新兴消费模式，人们可以不受时间和地点的限制，对商品进行购买；而商家也同样可以不受时间和地点的限制，对商品进行销售。
在网络购物中，商家为了提高商品的销售量和商品的推广度，会对商品开展大量的促销活动，来促进用户对该商品的购买，以实现对该商品的推广。
为了保证商家的商品销售利益以及避免恶意用户大量购买促销商品，再将该促销商品以高价转售给其他用户，损害其他用户的购买该促销商品的权益，商家通常会对该促销商品设置限制购买措施，例如，对每个用户购买该促销商品的数量和次数进行限制，在预置促销商品销售量的前提下，保证更多的用户能够买到该促销商品。
在现有技术中，一般利用事务性数据库，比如，mysql数据库，来处理用户的待购买的促销商品订单，以实现对用户购买该促销商品的限制。但是事务性数据库在处理用户的待购买的促销商品订单时，存在处理过程复杂、处理时间较长的问题，且一旦该数据库出现问题，该促销商品的限制购买就无法再被处理，从而导致用户无法购买该促销商品，造成用户的购买体验度较差。故，如何保证良好的用户购买体验度，是解决上述问题的关键。
发明内容
为克服上述技术问题或者至少部分地解决上述技术问题，特提出以下技术方案：
本发明的实施例提出了一种网络交易中购买请求的处理方法，包括：
接收包含用户标识信息和待购买信息的购买请求；
查询缓存数据库中是否存在与用户标识信息和待购买信息对应的已购买信息和限制购买信息；
基于已购买信息，判断购买请求是否匹配限制购买信息；
若判断购买请求匹配限制购买信息，则拒绝购买请求。
优选地，该方法还包括：
若缓存数据库中不存在已购买信息，则直接判断购买请求是否匹配限制购买信息。
优选地，该方法还包括：
若缓存数据库中不存在限制购买信息，则从待购买信息求中获取最新限制购买信息以作为限制购买信息。
优选地，该方法还包括：
从购买请求中获取最新限制购买信息并与缓存数据库中的限制购买信息进行比较；
若比较结果显示两者不同，则以最新限制购买信息更新缓存数据库中的限制购买信息。
优选地，该方法还包括：
判断已购买信息是否有效，若否，则清除已购买信息，直接判断购买请求是否匹配限制购买信息。
优选地，基于已购买信息，判断购买请求是否匹配限制购买信息的步骤，具体包括：
当满足以下任一判断条件时，则判断购买请求匹配限制购买信息：
当已购买信息中的已购买次数与待购买信息中的待购买次数之和大于限制购买信息中的限购次数；或
当已购买信息中的已购买数量与待购买信息中的待购买数量之和大于限制购买信息中的限购数量。
优选地，若购买请求不匹配限制购买信息，该方法还包括：
将用户标识信息、待购买信息和限制购买信息相关联地存储到缓存数据库中，并允许购买请求。
优选地，该方法还包括：
基于预定周期，将缓存数据库中的信息存储至磁盘数据库。
其中，缓存数据库包括Redis数据库、memcached数据库、FastDB数据库中的任一项。
本发明的实施例提出了另一种网络交易中购买请求的处理装置，包括：
接收模块，用于接收包含用户标识信息和待购买信息的购买请求；
查询模块，用于查询缓存数据库中是否存在与用户标识信息和待购买信息对应的已购买信息和限制购买信息；
第一判断模块，用于基于已购买信息，判断购买请求是否匹配限制购买信息；
第一执行模块，用于若判断购买请求匹配限制购买信息，则拒绝购买请求。
优选地，该装置还包括：
第二判断模块，用于若缓存数据库中不存在已购买信息，则直接判断购买请求是否匹配限制购买信息。
优选地，该装置还包括：
第一获取模块，用于若缓存数据库中不存在限制购买信息，则从待购买信息求中获取最新限制购买信息以作为限制购买信息。
优选地，该装置还包括：
第二获取模块，用于从购买请求中获取最新限制购买信息并与缓存数据库中的限制购买信息进行比较；
比较模块，用于若比较结果显示两者不同，则以最新限制购买信息更新缓存数据库中的限制购买信息。
优选地，该装置还包括：
第二执行模块，用于判断已购买信息是否有效，若否，则清除已购买信息，直接判断购买请求是否匹配限制购买信息。
优选地，第一判断模块，用于当满足以下任一判断条件时，则判断购买请求匹配限制购买信息：
当已购买信息中的已购买次数与待购买信息中的待购买次数之和大于限制购买信息中的限购次数；或
当已购买信息中的已购买数量与待购买信息中的待购买数量之和大于限制购买信息中的限购数量。
优选地，若购买请求不匹配限制购买信息，该装置还包括：
第一存储模块，用于将用户标识信息、待购买信息和限制购买信息相关联地存储到缓存数据库中，并允许购买请求。
优选地，该装置还包括：
第二存储模块，用于基于预定周期，将缓存数据库中的信息存储至磁盘数据库。
其中，缓存数据库包括Redis数据库、memcached数据库、FastDB数据库中的任一项。
本发明的技术方案中，基于用户标识信息和待购买信息，查询缓存数据库中是否存在与用户标识信息和待购买信息对应的已购买信息和限制购买信息；并基于存在的已购买信息，判断当用户的购买请求与限制购买信息匹配时；则拒绝用户的购买请求，实现对用户购买促销商品的限制；避免如促销商品的销售量超过商家的预定促销商品销售量、促销商品的销售时间与商家的预定促销时段不相符合等情况的发生，从而给商家带来经济损失；同时，还可以避免恶意用户大量购买该促销商品，使得该促销商品销售量超过预定促销商品销售量，导致其他用户无法正常购买该促销商品，造成销售不公平的情况发生。此外，由于通过缓存数据库查询已购买信息和限制购买信息，能够快速找到该已购买信息和限制购买信息，使得用户能够快速地对促销商品进行购买；即使事务性数据库出现故障问题，也不会影响缓存数据库对促销商品的限制购买的处理过程，用户依然可以对该促销商品进行购买，从而保证了良好的用户体验。
本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为本发明的一个实施例的网络交易中购买请求的处理方法的流程示意图；
图2为本发明的具体实施例的基于最新限制购买信息更新缓存数据库中的限制购买信息的流程示意图；
图3为本发明的另一个实施例的网络交易中购买请求的处理装置的结构框架示意图。
具体实施方式
下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。
本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。
图1为本发明一个实施例的网络交易中购买请求的处理方法的流程示意图。
步骤S101：接收包含用户标识信息和待购买信息的购买请求；步骤S102：查询缓存数据库中是否存在与用户标识信息和待购买信息对应的已购买信息和限制购买信息；步骤S103：基于已购买信息，判断购买请求是否匹配限制购买信息；步骤S104：若判断购买请求匹配限制购买信息，则拒绝购买请求。
本发明的技术方案中，基于用户标识信息和待购买信息，查询缓存数据库中是否存在与用户标识信息和待购买信息对应的已购买信息和限制购买信息；并基于存在的已购买信息，判断当用户的购买请求与限制购买信息匹配时；则拒绝用户的购买请求，实现对用户购买促销商品的限制；避免如促销商品的销售量超过商家的预定促销商品销售量、促销商品的销售时间与商家的预定促销时段不相符合等情况的发生，从而给商家带来经济损失；同时，还可以避免恶意用户大量购买该促销商品，使得该促销商品销售量超过预定促销商品销售量，导致其他用户无法正常购买该促销商品，造成销售不公平的情况发生。此外，由于通过缓存数据库查询已购买信息和限制购买信息，能够快速找到该已购买信息和限制购买信息，使得用户能够快速地对促销商品进行购买；即使事务性数据库出现故障问题，也不会影响缓存数据库对促销商品的限制购买的处理过程，用户依然可以对该促销商品进行购买，从而保证了良好的用户体验。
以下针对各个步骤的具体实现做进一步的说明：
需要说明的是，本实施例的执行主体是服务器。
步骤S101：接收包含用户标识信息和待购买信息的购买请求。
其中，用户标识信息包括但不限于：用户ID名称、用户手机号码。
待购买信息包括但不限于：待购买商品信息和本次待购买信息；待购买商品信息包括但不限于：商品库存信息，如待购买商品库存数量；商品属性信息，如待购买商品颜色、尺寸等；商品标识信息，如待购买商品编号、待购买商品名称等；限制购买信息，如限制购买次数、限制购买数量、限制购买日期等。本次待购买信息包括但不限于：待购买商品数量、待购买时间、待购买商品颜色、待购买商品价格等。
例如，业务服务器接收到客户端发送的购买请求，并解析该购买请求，获取其中的用户标识信息、待购买商品信息和本次待购买信息；如，用户ID名称“user”、商品编号“001”、商品名称“手机N4S”、商品库存数量“20个”、商品颜色“灰色”、限制购买日期“2016年11月11日-2016年11月17日、限制购买次数“2次”，即，一个用户只能购买2次手机N4S、限制购买数量“5个”，即，一个用户只能购买5个手机N4S”、待购买数量“2个”、待购买时间“2016年11月11日”、待购买商品颜色“灰色”、待购买商品价格“999元”。
需要说明的是，对于限制购买次数和限制购买数量的具体意义可以有多种定义方式，上述举例中的具体意义仅为举例，在此不做限定。如，限制购买次数和限制购买数量的具体意义由商家设置为，一个用户ID每天可以购买2次手机N4S、一个用户ID每天可以购买5个手机N4S等；且限制购买次数和限制购买数量的具体意义会包括于购买请求一起由客户端发送至服务器，服务器会对其具体意义进行获取，再进行下述步骤的判断。
步骤S102：查询缓存数据库中是否存在与用户标识信息和待购买信息对应的已购买信息和限制购买信息。
其中，缓存数据库包括Redis数据库、memcached数据库、FastDB数据库中的任一项。
已购买信息包括但不限于：已购买商品标识信息，如，已购买商品编号、已购买商品名称等；已购买数量、已购买商品颜色、已购买次数、已购买商品价格。
限制购买信息包括但不限于：限制购买次数、限制购买数量、限制购买日期。
例如，业务服务器查询Redis数据库中是否存在与用户ID名称“user”和商品编号“001”、商品名称“手机N4S”对应的已购买次数、已购买数量、限制购买次数、限制购买数量和限制购买日期的信息。
步骤S103：基于已购买信息，判断购买请求是否匹配限制购买信息。
具体地，基于已购买信息，判断购买请求是否匹配限制购买信息的步骤，具体包括：当满足以下任一判断条件时，则判断购买请求匹配限制购买信息：当已购买信息中的已购买次数与待购买信息中的待购买次数之和大于限制购买信息中的限购次数；或当已购买信息中的已购买数量与待购买信息中的待购买数量之和大于限制购买信息中的限购数量。
例如，基于步骤S102业务服务器查询到redis数据库中存在该用户ID名称“user”、商品编号“001”、商品名称“手机N4S”、限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”和限制购买数量“5个”，对应的该用户ID名称“user”、商品编号“001”、商品名称“手机N4S”、限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”和限制购买数量“5个”的已购买次数“1次”和已购买数量“4个”。基于该用户ID名称“user”的已购买次数“1次”、已购买数量“4个”、待购买数量“2个”，可知，已购买次数与待购买次数之和为2次，等于限制购买次数；不满足该判断条件，则继续判断下一个判断条件，已购买数量“4个”与待购买数量“2个”之和为6个，大于限制购买数量“5个”，则满足该判断条件，判断该购买请求匹配限制购买信息。
步骤S104：若判断购买请求匹配限制购买信息，则拒绝购买请求。
例如，当已购买数量“4个”与待购买数量“2个”之和为6个，大于限制购买数量“5个”，则判断该购买请求匹配限制购买信息条件，则业务服务器拒绝该用户的购买请求。
具体地，该方法还包括：若缓存数据库中不存在已购买信息，则直接判断购买请求是否匹配限制购买信息。
例如，基于步骤S102业务服务器查询到redis数据库中不存在该用户ID名称“user”、商品编号“001”、商品名称“手机N4S”、限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”和限制购买数量“5个”，对应的已购买信息，即该用户ID名称“user”从未在该限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”、限制购买数量“5个”条件下，购买过商品编号“001”、商品名称“手机N4S”的商品；则直接判断该购买请求中的商品编号“001”的商品名称“手机N4S”的商品待购买数量“2个”是否匹配限制购买信息：限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”、限制购买数量“5个”；由于该用户ID名称“user”是第一次购买该商品，即购买次数为1次，小于限制购买次数“2次”，同时本次商品待购买数量为“2个”，小于限制购买次数量“5个”，故判断该购买请求不匹配限制购买信息，则业务服务器允许该用户的购买请求。
具体地，该方法还包括：判断已购买信息是否有效，若否，则清除已购买信息，直接判断购买请求是否匹配限制购买信息。
例如，基于步骤S102业务服务器查询到redis数据库中存在该用户ID名称“user”、商品编号“001”和商品名称“手机N4S”，对应的该用户ID名称“user”、商品编号“001”、商品名称“手机N4S”的已购买次数“1次”和已购买数量“4个”；则基于该已购买信息的限制购买信息是否过期，判断该已购买信息是否有效，若该已购买信息的限制购买信息为：限制购买日期“2016年10月1日-2016年10月7日”、限制购买次数“2次”、限制购买数量“5个”，其中的限制购买日期“2016年10月1日-2016年10月7日与本次限制购买日期“2016年11月11日-2016年11月17日相比，已过期；则判断该已购买信息的限制购买信息过期，直接判断该购买请求是否匹配限制信息。
需要说明的是，直接判断该购买请求是否匹配限制信息的具体步骤已在上述实施例中进行阐述，在此就不再赘述。
具体地，该方法还包括：若缓存数据库中不存在限制购买信息，则从待购买信息求中获取最新限制购买信息以作为限制购买信息。
例如，基于步骤S102业务服务器查询到redis数据库中不存在该用户ID名称“user”、商品编号“001”、商品名称“手机N4S”，对应的已购买信息；则从待购买请求中获取最新限制购买信息：限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”、限制购买数量“5个”，作为存储至redis数据库中的限制购买信息。
具体地，该方法如图2所示，还包括：从购买请求中获取最新限制购买信息并与缓存数据库中的限制购买信息进行比较；若比较结果显示两者不同，则以最新限制购买信息更新缓存数据库中的限制购买信息。
例如，基于步骤S102业务服务器查询到redis数据库中存在该用户ID名称“user”、商品编号“001”、商品名称“手机N4S”，对应的限制购买信息：限制购买日期“2016年10月1日-2016年10月7日”、限制购买次数“2次”、限制购买数量“5个”，与从购买请求中获取到的最新限制购买信息：限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”、限制购买数量“5个”，进行比较；比较结果为两个购买限制信息不同，则将最新购买信息：限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”、限制购买数量“5个”，更新缓存数据库中的限制购买信息。
由于redis数据库是Key-Value数据库，其存储形式也是Key-Value的存储形式，故将最新限制购买信息更新redis数据库中的限制购买信息，即为：
Figure BDA0001176213940000101
需要说明的是，上述Uid为用户ID user id；Cid为商品编号commodity id；pld为限制购买日期purchase limit date；plt为限制购买次数purchase limit time；pln为限制购买数量purchase limit number；此外，key-value的存储形式有很多种，在此只选择其中一种可能的格式作为示例表明其存储形式，对于其他key-value存储形式同样可以对该最新限制购买信息进行存储，在此就不再赘述。
具体地，若购买请求不匹配限制购买信息，该方法还包括：将用户标识信息、待购买信息和限制购买信息相关联地存储到缓存数据库中，并允许购买请求。
例如，当该购买请求不匹配限制购买信息，则业务服务器允许该用户的购买请求时，同时，服务器将用户ID名称“user”、商品编号“001”、待购买数量“2个”、限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”、限制购买数量“5个”相关联地存储到redis数据库中。
其中，当redis数据库中不存在与本次待购买信息和本次限制购买信息相对应的该用户的已购买信息和限制购买信息，则将用户标识信息、本次待购买信息和本次限制购买信息直接存储到redis数据库中，其存储至redis数据库的格式如下：
Figure BDA0001176213940000111
当redis数据库中存在与本次待购买信息和本次限制购买信息相对应的该用户的已购买信息和限制购买信息，则将待购买信息与redis数据库中的相对应的已购买信息进行数据叠加，即：将该用户ID名称“user”的待购买数量“2个”与已购买数量“3个”进行数据叠加，本次购买次数“1次”与已购买次数“1次”进行数据叠加，再存储到redis数据库中，其中，该用户的已购买信息和限制购买信息在redis数据库中的存储格式为：
Figure BDA0001176213940000112
将待购买信息与redis数据库中的相对应的已购买信息进行数据叠加，并存储至数据库的格式如下：
Figure BDA0001176213940000121
需要说明的是，上述Uid为用户ID user id；Cid为商品编号commodity id；pt为购买次数purchase time；pn为购买数量purchase number；pld为限制购买日期purchaselimit date；plt为限制购买次数purchase limit time；pln为限制购买数量purchaselimit number；此外，key-value的存储形式有很多种，在此只选择其中一种可能的格式作为示例表明其存储形式，对于其他key-value存储形式同样可以对该上述相应信息进行存储，在此就不再赘述。
具体地，该方法还包括：基于预定周期，将缓存数据库中的信息存储至磁盘数据库。
例如，每隔十分钟，将redis数据库中的信息存储至硬盘数据库中，如mysql数据库。
图3为本发明的另一个实施例的网络交易中购买请求的处理装置的结构框架示意图。
接收模块301，接收包含用户标识信息和待购买信息的购买请求；查询模块302，查询缓存数据库中是否存在与用户标识信息和待购买信息对应的已购买信息和限制购买信息；第一判断模块303，基于已购买信息，判断购买请求是否匹配限制购买信息；第一执行模块304，若判断购买请求匹配限制购买信息，则拒绝购买请求。
以下针对各个模块的具体实现做进一步的说明：
接收模块301，接收包含用户标识信息和待购买信息的购买请求。
其中，用户标识信息包括但不限于：用户ID名称、用户手机号码。
待购买信息包括但不限于：待购买商品信息和本次待购买信息；待购买商品信息包括但不限于：商品库存信息，如待购买商品库存数量；商品属性信息，如待购买商品颜色、尺寸等；商品标识信息，如待购买商品编号、待购买商品名称等；限制购买信息，如限制购买次数、限制购买数量、限制购买日期等。本次待购买信息包括但不限于：待购买商品数量、待购买时间、待购买商品颜色、待购买商品价格等。
例如，业务服务器的接收模块301接收到客户端发送的购买请求，并解析该购买请求，获取其中的用户标识信息、待购买商品信息和本次待购买信息；如，用户ID名称“user”、商品编号“001”、商品名称“手机N4S”、商品库存数量“20个”、商品颜色“灰色”、限制购买日期“2016年11月11日-2016年11月17日、限制购买次数“2次”，即，一个用户只能购买2次手机N4S、限制购买数量“5个”，即，一个用户只能购买5个手机N4S”、待购买数量“2个”、待购买时间“2016年11月11日”、待购买商品颜色“灰色”、待购买商品价格“999元”。
需要说明的是，对于限制购买次数和限制购买数量的具体意义可以有多种定义方式，上述举例中的具体意义仅为举例，在此不做限定。如，限制购买次数和限制购买数量的具体意义由商家设置为，一个用户ID每天可以购买2次手机N4S、一个用户ID每天可以购买5个手机N4S等；且限制购买次数和限制购买数量的具体意义会包括于购买请求一起由客户端发送至服务器，服务器会对其具体意义进行获取，再进行下述步骤的判断。
查询模块302，查询缓存数据库中是否存在与用户标识信息和待购买信息对应的已购买信息和限制购买信息。
其中，缓存数据库包括Redis数据库、memcached数据库、FastDB数据库中的任一项。
已购买信息包括但不限于：已购买商品标识信息，如，已购买商品编号、已购买商品名称等；已购买数量、已购买商品颜色、已购买次数、已购买商品价格。
限制购买信息包括但不限于：限制购买次数、限制购买数量、限制购买日期。
例如，业务服务器的查询模块302查询Redis数据库中是否存在与用户ID名称“user”和商品编号“001”、商品名称“手机N4S”对应的已购买次数、已购买数量、限制购买次数、限制购买数量和限制购买日期的信息。
第一判断模块303，基于已购买信息，判断购买请求是否匹配限制购买信息。
具体地，第一判断模块303，当满足以下任一判断条件时，则判断购买请求匹配限制购买信息：当已购买信息中的已购买次数与待购买信息中的待购买次数之和大于限制购买信息中的限购次数；或当已购买信息中的已购买数量与待购买信息中的待购买数量之和大于限制购买信息中的限购数量。
例如，基于查询模块302查询到redis数据库中存在该用户ID名称“user”、商品编号“001”、商品名称“手机N4S”、限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”和限制购买数量“5个”，对应的该用户ID名称“user”、商品编号“001”、商品名称“手机N4S”、限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”和限制购买数量“5个”的已购买次数“1次”和已购买数量“4个”。基于该用户ID名称“user”的已购买次数“1次”、已购买数量“4个”、待购买数量“2个”，第一判断模块303可判断，已购买次数与待购买次数之和为2次，等于限制购买次数；不满足该判断条件，则继续判断下一个判断条件，已购买数量“4个”与待购买数量“2个”之和为6个，大于限制购买数量“5个”，则满足该判断条件，判断该购买请求匹配限制购买信息。
第一执行模块304，若判断购买请求匹配限制购买信息，则拒绝购买请求。
例如，当已购买数量“4个”与待购买数量“2个”之和为6个，大于限制购买数量“5个”，则判断该购买请求匹配限制购买信息条件，则业务服务器中的第一执行模块304拒绝该用户的购买请求。
具体地，该装置还包括：第二判断模块，若缓存数据库中不存在已购买信息，则直接判断购买请求是否匹配限制购买信息。
例如，基于查询模块302查询到redis数据库中不存在该用户ID名称“user”、商品编号“001”、商品名称“手机N4S”、限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”和限制购买数量“5个”，对应的已购买信息，即该用户ID名称“user”从未在该限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”、限制购买数量“5个”条件下，购买过商品编号“001”、商品名称“手机N4S”的商品；则直接判断该购买请求中的商品编号“001”的商品名称“手机N4S”的商品待购买数量“2个”是否匹配限制购买信息：限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”、限制购买数量“5个”；由于该用户ID名称“user”是第一次购买该商品，即购买次数为1次，小于限制购买次数“2次”，同时本次商品待购买数量为“2个”，小于限制购买次数量“5个”，故判断该购买请求不匹配限制购买信息，则第二判断模块允许该用户的购买请求。
具体地，该装置还包括：第二执行模块，判断已购买信息是否有效，若否，则清除已购买信息，直接判断购买请求是否匹配限制购买信息。
例如，基于查询模块302查询到redis数据库中存在该用户ID名称“user”、商品编号“001”和商品名称“手机N4S”，对应的该用户ID名称“user”、商品编号“001”、商品名称“手机N4S”的已购买次数“1次”和已购买数量“4个”；则基于该已购买信息的限制购买信息是否过期，判断该已购买信息是否有效，若该已购买信息的限制购买信息为：限制购买日期“2016年10月1日-2016年10月7日”、限制购买次数“2次”、限制购买数量“5个”，其中的限制购买日期“2016年10月1日-2016年10月7日与本次限制购买日期“2016年11月11日-2016年11月17日相比，已过期；则判断该已购买信息的限制购买信息过期，第二执行模块直接判断该购买请求是否匹配限制信息。
需要说明的是，直接判断该购买请求是否匹配限制信息的具体步骤已在上述实施例中进行阐述，在此就不再赘述。
具体地，该装置还包括：第一获取模块，若缓存数据库中不存在限制购买信息，则从待购买信息求中获取最新限制购买信息以作为限制购买信息。
例如，基于查询模块302查询到redis数据库中不存在该用户ID名称“user”、商品编号“001”、商品名称“手机N4S”，对应的已购买信息；第一获取模块则从待购买请求中获取最新限制购买信息：限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”、限制购买数量“5个”，作为存储至redis数据库中的限制购买信息。
具体地，该装置还包括：第二获取模块，从购买请求中获取最新限制购买信息并与缓存数据库中的限制购买信息进行比较；比较模块，若比较结果显示两者不同，则以最新限制购买信息更新缓存数据库中的限制购买信息。
例如，第二获取模块基于查询模块302查询到redis数据库中存在该用户ID名称“user”、商品编号“001”、商品名称“手机N4S”，对应的限制购买信息：限制购买日期“2016年10月1日-2016年10月7日”、限制购买次数“2次”、限制购买数量“5个”，与从购买请求中获取到的最新限制购买信息：限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”、限制购买数量“5个”，进行比较；比较结果为两个购买限制信息不同，比较模块则将最新购买信息：限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”、限制购买数量“5个”，更新缓存数据库中的限制购买信息。
由于redis数据库是Key-Value数据库，其存储形式也是Key-Value的存储形式，故将最新限制购买信息更新redis数据库中的限制购买信息，即为：
Figure BDA0001176213940000161
需要说明的是，上述Uid为用户ID user id；Cid为商品编号commodity id；pld为限制购买日期purchase limit date；plt为限制购买次数purchase limit time；pln限制购买数量为purchase limit number；此外，key-value的存储形式有很多种，在此只选择其中一种可能的格式作为示例表明其存储形式，对于其他key-value存储形式同样可以对该最新限制购买信息进行存储，在此就不再赘述。
具体地，若购买请求不匹配限制购买信息，该装置还包括：第一存储模块，将用户标识信息、待购买信息和限制购买信息相关联地存储到缓存数据库中，并允许购买请求。
例如，当该购买请求不匹配限制购买信息，则业务服务器中的第一存储模块允许该用户的购买请求时，同时，将用户ID名称“user”、商品编号“001”、待购买数量“2个”、限制购买日期“2016年11月11日-2016年11月17日”、限制购买次数“2次”、限制购买数量“5个”相关联地存储到redis数据库中。
其中，当redis数据库中不存在与本次待购买信息和本次限制购买信息相对应的该用户的已购买信息和限制购买信息，则将用户标识信息、本次待购买信息和本次限制购买信息直接存储到redis数据库中，其存储至redis数据库的格式如下：
Figure BDA0001176213940000171
当redis数据库中存在与本次待购买信息和本次限制购买信息相对应的该用户的已购买信息和限制购买信息，则将待购买信息与redis数据库中的相对应的已购买信息进行数据叠加，即：将该用户ID名称“user”的待购买数量“2个”与已购买数量“3个”进行数据叠加，本次购买次数“1次”与已购买次数“1次”进行数据叠加，再存储到redis数据库中，其中，该用户的已购买信息和限制购买信息在redis数据库中的存储格式为：
Figure BDA0001176213940000172
Figure BDA0001176213940000181
将待购买信息与redis数据库中的相对应的已购买信息进行数据叠加，并存储至数据库的格式如下：
Figure BDA0001176213940000182
需要说明的是，上述Uid为用户ID user id；Cid为商品编号commodity id；pt为购买次数purchase time；pn为购买数量purchase number；pld为限制购买日期purchaselimit date；plt为限制购买次数purchase limit time；pln为限制购买数量purchaselimit number；此外，key-value的存储形式有很多种，在此只选择其中一种可能的格式作为示例表明其存储形式，对于其他key-value存储形式同样可以对该上述相应信息进行存储，在此就不再赘述。
该装置还包括：第二存储模块，基于预定周期，将缓存数据库中的信息存储至磁盘数据库。
例如，每隔十分钟，将redis数据库中的信息存储至硬盘数据库中，如mysql数据库。
本技术领域技术人员可以理解，本发明包括涉及用于执行本申请中所述操作中的一项或多项的设备。这些设备可以为所需的目的而专门设计和制造，或者也可以包括通用计算机中的已知设备。这些设备具有存储在其内的计算机程序，这些计算机程序选择性地激活或重构。这样的计算机程序可以被存储在设备(例如，计算机)可读介质中或者存储在适于存储电子指令并分别耦联到总线的任何类型的介质中，所述计算机可读介质包括但不限于任何类型的盘(包括软盘、硬盘、光盘、CD-ROM、和磁光盘)、ROM(Read-Only Memory，只读存储器)、RAM(Random Access Memory，随即存储器)、EPROM(Erasable ProgrammableRead-Only Memory，可擦写可编程只读存储器)、EEPROM(Electrically ErasableProgrammable Read-Only Memory，电可擦可编程只读存储器)、闪存、磁性卡片或光线卡片。也就是，可读介质包括由设备(例如，计算机)以能够读的形式存储或传输信息的任何介质。
本技术领域技术人员可以理解，可以用计算机程序指令来实现这些结构图和/或框图和/或流图中的每个框以及这些结构图和/或框图和/或流图中的框的组合。本技术领域技术人员可以理解，可以将这些计算机程序指令提供给通用计算机、专业计算机或其他可编程数据处理方法的处理器来实现，从而通过计算机或其他可编程数据处理方法的处理器来执行本发明公开的结构图和/或框图和/或流图的框或多个框中指定的方案。
本技术领域技术人员可以理解，本发明中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本发明中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本发明中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。
以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (16)

1.一种网络交易中购买请求的处理方法，包括：
接收包含用户标识信息和待购买信息的购买请求；所述待购买信息包括限制购买信息；
查询缓存数据库中是否存在与用户标识信息和待购买信息对应的已购买信息和限制购买信息；
基于所述已购买信息，判断所述购买请求是否匹配所述限制购买信息；
若判断所述购买请求匹配所述限制购买信息，则拒绝所述购买请求；
若所述缓存数据库中不存在所述限制购买信息，则从所述待购买信息中获取最新限制购买信息以作为所述限制购买信息。
2.根据权利要求1所述的方法，其中，还包括：
若所述缓存数据库中不存在所述已购买信息，则直接判断所述购买请求是否匹配所述限制购买信息。
3.根据权利要求1所述的方法，其中，还包括：
从所述购买请求中获取最新限制购买信息并与所述缓存数据库中的所述限制购买信息进行比较；
若比较结果显示两者不同，则以所述最新限制购买信息更新所述缓存数据库中的所述限制购买信息。
4.根据权利要求1-3中任一项所述的方法，其中，还包括：
判断所述已购买信息是否有效，若否，则清除所述已购买信息，直接判断所述购买请求是否匹配所述限制购买信息。
5.根据权利要求1所述的方法，其中，所述基于所述已购买信息，判断所述购买请求是否匹配所述限制购买信息的步骤，具体包括：
当满足以下任一判断条件时，则判断所述购买请求匹配所述限制购买信息：
当所述已购买信息中的已购买次数与所述待购买信息中的待购买次数之和大于所述限制购买信息中的限购次数；或
当所述已购买信息中的已购买数量与所述待购买信息中的待购买数量之和大于限制购买信息中的限购数量。
6.根据权利要求1-3、5中任一项所述的方法，其中，若所述购买请求不匹配所述限制购买信息，所述方法还包括：
将所述用户标识信息、所述待购买信息和所述限制购买信息相关联地存储到所述缓存数据库中，并允许所述购买请求。
7.根据权利要求1-3、5中任一项所述的方法，其中，还包括：
基于预定周期，将所述缓存数据库中的信息存储至磁盘数据库。
8.根据权利要求1-3、5中任一项所述的方法，其中，所述缓存数据库包括Redis数据库、memcached数据库、FastDB数据库中的任一项。
9.一种网络交易中购买请求的处理装置，包括：
接收模块，用于接收包含用户标识信息和待购买信息的购买请求；所述待购买信息包括限制购买信息；
查询模块，用于查询缓存数据库中是否存在与用户标识信息和待购买信息对应的已购买信息和限制购买信息；
第一判断模块，用于基于所述已购买信息，判断所述购买请求是否匹配所述限制购买信息；
第一执行模块，用于若判断所述购买请求匹配所述限制购买信息，则拒绝所述购买请求；
第一获取模块，用于若所述缓存数据库中不存在所述限制购买信息，则从所述待购买信息中获取最新限制购买信息以作为所述限制购买信息。
10.根据权利要求9所述的装置，其中，还包括：
第二判断模块，用于若所述缓存数据库中不存在所述已购买信息，则直接判断所述购买请求是否匹配所述限制购买信息。
11.根据权利要求9所述的装置，其中，还包括：
第二获取模块，用于从所述购买请求中获取最新限制购买信息并与所述缓存数据库中的所述限制购买信息进行比较；
比较模块，用于若比较结果显示两者不同，则以所述最新限制购买信息更新所述缓存数据库中的所述限制购买信息。
12.根据权利要求9-11中任一项所述的装置，其中，还包括：
第二执行模块，用于判断所述已购买信息是否有效，若否，则清除所述已购买信息，直接判断所述购买请求是否匹配所述限制购买信息。
13.根据权利要求9所述的装置，其中，所述第一判断模块，用于当满足以下任一判断条件时，则判断所述购买请求匹配所述限制购买信息：
当所述已购买信息中的已购买次数与所述待购买信息中的待购买次数之和大于所述限制购买信息中的限购次数；或
当所述已购买信息中的已购买数量与所述待购买信息中的待购买数量之和大于限制购买信息中的限购数量。
14.根据权利要求9-11、13中任一项所述的装置，其中，若所述购买请求不匹配所述限制购买信息，所述装置还包括：
第一存储模块，用于将所述用户标识信息、所述待购买信息和所述限制购买信息相关联地存储到所述缓存数据库中，并允许所述购买请求。
15.根据权利要求9-11、13中任一项所述的装置，其中，还包括：
第二存储模块，用于基于预定周期，将所述缓存数据库中的信息存储至磁盘数据库。
16.根据权利要求9-11、13中任一项所述的装置，其中，所述缓存数据库包括Redis数据库、memcached数据库、FastDB数据库中的任一项。
CN201611131369.1A 2016-12-09 2016-12-09 网络交易中购买请求的处理方法和处理装置 Active CN106599169B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201611131369.1A CN106599169B (zh) 2016-12-09 2016-12-09 网络交易中购买请求的处理方法和处理装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611131369.1A CN106599169B (zh) 2016-12-09 2016-12-09 网络交易中购买请求的处理方法和处理装置

Publications (2)

Publication Number Publication Date
CN106599169A CN106599169A (zh) 2017-04-26
CN106599169B true CN106599169B (zh) 2021-02-05

Family

ID=58598760

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611131369.1A Active CN106599169B (zh) 2016-12-09 2016-12-09 网络交易中购买请求的处理方法和处理装置

Country Status (1)

Country Link
CN (1) CN106599169B (zh)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107316136A (zh) * 2017-06-19 2017-11-03 广州市升龙灯光设备有限公司 一种舞台灯授权方法、电子设备及存储介质
CN107451906A (zh) * 2017-08-18 2017-12-08 首媒科技（北京）有限公司 商品限购方法及系统
CN107679973A (zh) * 2017-10-28 2018-02-09 广州云魔企业管理有限公司 一种酒吧夜店互动平台和方法
CN107730366B (zh) * 2017-10-30 2021-06-11 北京博瑞彤芸科技股份有限公司 一种支付订单管理的信息处理方法
CN109767241B (zh) * 2018-12-19 2021-09-07 深圳优启科技有限公司 一种新零售购物分销方法、系统、计算机设备及存储介质
CN111506445A (zh) * 2020-04-21 2020-08-07 北京思特奇信息技术股份有限公司 一种基于redis缓存的防止商品重复恶意订购方法及系统
CN112184363A (zh) * 2020-09-07 2021-01-05 珠海格力电器股份有限公司 一种购物信息处理方法、装置、设备及介质
CN112801641B (zh) * 2021-02-05 2023-09-19 广州聚汇信息技术有限公司 支付网关限购控制方法及其装置、设备与介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104809621A (zh) * 2015-05-14 2015-07-29 苏州海博智能系统有限公司 产品售卖的监管系统、终端监管方法和中心监管方法
CN105139191A (zh) * 2015-09-15 2015-12-09 联动优势电子商务有限公司 一种获取订单信息的方法及设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9697561B2 (en) * 2013-03-15 2017-07-04 W.W. Grainger, Inc. Systems and methods for administering customer purchasing processes

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104809621A (zh) * 2015-05-14 2015-07-29 苏州海博智能系统有限公司 产品售卖的监管系统、终端监管方法和中心监管方法
CN105139191A (zh) * 2015-09-15 2015-12-09 联动优势电子商务有限公司 一种获取订单信息的方法及设备

Also Published As

Publication number Publication date
CN106599169A (zh) 2017-04-26

Similar Documents

Publication Publication Date Title
CN106599169B (zh) 网络交易中购买请求的处理方法和处理装置
US20180096349A1 (en) Distributed electronic ledger with metadata
US20130246212A1 (en) System and method for providing mobile device trade-in value quotations and comparisons against other mobile devices
US20190236601A1 (en) Enhanced merchant identification using transaction data
US20130246211A1 (en) System and method for providing mobile device trade in value quotations
US11734745B2 (en) System and method for generating geographic zone information for consumers
CA2611621A1 (en) Dynamic aggregation of payment transactions
US20160019613A1 (en) Method and apparatus for calculating a transaction quality score of a merchant
CN113312527B (zh) 采购数据处理方法、装置、计算机设备和存储介质
US20170039605A1 (en) Method and system for providing a personalised customer service from a physical provider of goods or services
US20150186909A1 (en) Method and system for consumer tracking using geolocation
US20140358741A1 (en) Method and system for showrooming detection
JP6872269B2 (ja) インターネットショッピングモール管理方法
JP6486527B1 (ja) 判定装置、判定方法、及びプログラム
CN110390555A (zh) 一种多平台集成互联网商城系统及分销方法
CN115760300A (zh) 一种基于标签管理销售品的实现方法及系统
CN114596147A (zh) 数据对账方法、装置、计算机设备和存储介质
CN112801761A (zh) 商品推荐方法、计算设备和计算机可读存储介质
JP6886183B2 (ja) 顧客属性推定システム及び顧客属性推定方法
US20160110785A1 (en) Systems and methods for sale redemption
Peštek et al. CUSTOMER ATTITUDES TOWARDS E-COMMERCE: CASE OF BOSNIA AND HERZEGOVINA
WO2013068378A1 (en) Method for processing an electronic payment certificate
WO2017109896A1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
KR102350467B1 (ko) 통합 금융 서비스를 제공하는 방법 및 시스템
US20220292579A1 (en) System and Method for Green Procurement

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
GR01 Patent grant
GR01 Patent grant