一种抽签预约方法及装置与流程

本申请涉及网络技术领域，特别涉及一种抽签预约方法及装置。

背景技术：

随着网络技术和智能终端的飞速发展，人们希望随时随地能从互联网中获取信息和服务。特别是债券或股票往往采用秒杀模式，大量用户同时并发访问购买，而部分用户通过抢单软件进行强购买，不仅给系统造成巨大的压力，同时，又造成普通用户很难抢购到想要购买的产品，不但降低了用户的买卖体验，也降低了用户购买产品的成功率。

技术实现要素：

有鉴于此，本申请提供一种抽签预约方法及装置，以解决现有技术中由于产品开盘的瞬间进行抢购，导致系统压力过大，购买成功率低，用户体验差的问题。

具体地，本申请是通过如下技术方案实现的：

第一方面提供一种抽签预约方法，所述方法包括：

获取参加同期抽签预约活动的可售对象；

确定所述可售对象的抽签预约活动信息，所述抽签预约活动信息包括：开始预约时间和开始撮合时间；

将所述可售对象的抽签预约信息通过页面展示给用户；

在所述预约时间内接收所述用户购买所述可售对象的多个预约单，其中， 多个所述预约单均为未中签预约单；

在达到所述撮合时间时，从多个所述预约单中随机抽取一条未中签预约单，并撮合抽取到的所述未中签预约单和对应的可售对象；

对撮合后的所述未中签预约单进行下订单，其中，下订单后的预约单为中签预约单；

在所述网页上显示已下订单的用户。

可选的，所述在所述开始预约时间内接收所述用户购买所述对象的多个预约单，包括：

在所述开始预约时间内通过页面表单的方式接收所述用户购买所述对象的多个预约单。

可选的，所述在达到所述开始撮合时间时，从多个所述预约单中随机抽取一条未中签预约单，并撮合抽取到的所述未中签预约单和对应的可售对象，包括：

在达到所述开始撮合时间时，将所有参加抽签预约活动的可售对象以列表的方式加载到内存中，以及将多个未中签的所述预约单分别以列表的方式加载到内存中；

从可售对象列表中顺序取出一条可售对象记录；

根据所述可售对象记录判断取出的所述可售对象是否还有可售库存；

如有可售库存，则从内存中获取未中签的预约单列表；

从所述未中签的预约单列表中随机抽取一条未中签预约单；

在所述未中签的所述预约单列表中删除随机抽取到的未中签预约单。

可选的，所述在达到所述开始撮合时间时，从多个所述预约单中随机抽取一条未中签预约单，并撮合抽取到的所述未中签预约单和对应的可售对象，还包括：

判断可售对象列表是否为空，如果不为空，则所述从可售对象列表中顺序取出一条可售对象记录的步骤。

可选的，还包括：

对中签的所述预约单进行活动管控和活动守护。

第二方面提供一种抽签预约装置，所述装置包括：

获取单元，用于获取参加同期抽签预约活动的可售对象；

确定单元，用于确定所述可售对象的抽签预约活动信息；所述抽签预约活动信息包括：开始预约时间和开始撮合时间；

展示单元，用于将所述可售对象的抽签预约信息通过页面展示给用户；

接收单元，用于在所述开始预约时间内接收所述用户购买所述可售对象的多个预约单，其中，多个所述预约单均为未中签预约单；

撮合单元，用于在达到所述开始撮合时间时，从多个所述预约单中随机抽取一条未中签预约单，撮合抽取到的所述未中签预约单和对应的可售对象，对撮合后的所述未中签预约单进行下订单，其中，下订单后的预约单为中签预约单；

显示单元，用于在所述网页上显示已下订单的用户。

可选的，所述接收单元，具体用于在所述开始预约时间内通过页面表单的方式接收所述用户购买所述对象的多个预约单。

可选的，所述撮合单元包括：

加载单元，用于在达到所述开始撮合时间时，将所有参加抽签预约活动的可售对象以列表的方式加载到内存中，以及将多个未中签的所述预约单分别以列表的方式加载到内存中；

提取单元，用于从可售对象列表中顺序取出一条可售对象记录；

第一判断单元，用于根据所述可售对象记录判断取出的所述可售对象是否还有可售库存；

获取子单元，用于在所述第一判断单元判断所述可售对象有可售库存时，从内存中获取未中签的预约单列表；

抽取单元，用于从所述获取子单元获取的所述未中签的预约单列表中随机抽取一条未中签预约单；

删除单元，用于在所述未中签的所述预约单列表中删除随机抽取到的未 中签预约单。

可选的，所述撮合单元还包括：

第二判断单元，用于判断可售对象列表是否为空；

所述提取单元，还用于在所述第二判断单元判断所述可售对象列表不为空时，从所述可售对象列表中顺序取出一条可售对象记录。

可选的，还包括：管理单元，用于对中签的所述预约单进行活动管控和活动守护。

本申请实施例中，将可售对象的抽签预约信息展示给用户，所有用户通过预约方式进行购买，中签用户是系统随机抽取的。这不但降低了系统压力，还增强了购买用户的公平性，同时也提高了用户购买的成功几率和用户购买满意度。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

图1是本申请实施例提供的一种抽签预约方法的流程图；

图2是本申请实施例提供的一种抽签预约方法中抽签撮合的流程图；

图3是本申请实施例提供的一种抽签预约单的状态示意图；

图3a是本申请实施例提供的一种抽签预约活动结束处理的流程图；

图4是本申请实施例提供的抽签预约装置所在设备的一种硬件结构图；

图5是本申请实施例提供的一种抽签预约装置的结构示意图；

图6是本申请实施例提供的一种抽签预约装置的应用实例图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方 式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

请参阅图1，为本申请实施例示出的一种抽签预约方法的流程图；所述方法包括：

步骤101：获取参加同期抽签预约活动的可售对象；

该步骤中，系统(即后台服务器等)接收到各机构通过文件的形式发送的可售对象(比如，某某股票，债券等可售产品)，并记录该可售对象的入库的时间。

步骤102：确定所述可售对象的抽签预约活动信息，所述抽签预约活动信息包括：开始预约时间和开始撮合时间；

系统在获取可售对象后，按照接收管理员发送的信息设置该可售对象的抽签预约活动信息，所述抽签预约活动信息包括：开始预约时间和开始撮合时间；当然并不限于此，还可以是应用包括其他参数，比如，结束预约时间，结束撮合时间等，本实施例不作限制。也就是说，管理员通过后台查询到需要设置的可售产品，然后输入可售产品的相关活动信息，该相关活动信息可以包括开始预约时间和开始撮合时间，即设置抽签预约活动信息。

步骤103：将所述可售对象的抽签预约信息通过页面展示给用户；

系统在设置抽签预约活动信息后，并设置在开始预约时间前将该可售对象的抽签预约信息通过页面展示给用户，以便于用户查看该页面上显示抽签预约活动。

步骤104：在所述开始预约时间内接收所述用户购买所述可售对象的多个预约单，其中，多个所述预约单均为未中签预约单；

该步骤中，在抽签预约活动到了开始预约时间时，用户可以在页面上看到这个抽签预约活动的详细信息，并通过页面表单的方式输入金额来参加活动。即系统接收到多个用户购买所述可售对象的多个预约单，其中，多个所述预约单均为未中签预约单。

其中，该实施例中，在所述开始预约时间内可以通过页面表单的方式接收所述用户购买所述对象的多个预约单，当然，也可以通过其他的方式接收多个预约单。

步骤105：在达到所述撮合时间时，从多个所述预约单中随机抽取一条未中签预约单，并撮合抽取到的所述未中签预约单和对应的可售对象；

对于上述用户购买可售对象的多个预约单，到了抽签开始时间，用户不能参加抽签预约活动，而由系统自动随机抽取用户的预约单，并自动撮合抽取到的预约单和活动产品。

需要说明的，该实施例中的随机抽取，还可以通过摇号抽取的方式来实现。

步骤106：对撮合后的所述未中签预约单进行下订单，其中，下订单后的预约单为中签预约单；

系统对撮合后的所述未中签预约单调用订单系统接口进行下订单，其中，下订单后的预约单为中签预约单。

步骤107：在所述网页上显示已下订单的用户。

抽签结束，系统生成中奖名单在该页面上公布，即公开中签名单。

本申请实施例中，将可售对象的抽签预约信息展示给用户，所有用户通过预约方式进行购买，中签用户是系统随机抽取的。这不但降低了系统压力， 还增强了购买用户的公平性，同时也提高了用户购买的成功几率和用户购买满意度。

可选的，在另一实施例中，该实施例在上述实施例的基础上，所述方法还可以包括：对中签的所述预约单进行活动管控和活动守护，其中，

活动管控，就是管控活动的开始到结束的一整套生命周期,活动开始的时候会向撮合中心发送消息，通知撮合中心开启一个抽签撮合的市场等待抽签开始；活动结束后会向该撮合中心发送消息，通知撮合中心来关闭这个活动抽签撮合的市场，关闭所有没有中签的预约单，然后，向发送短信通知抽奖结果，生成pdf格式的中奖名单。

活动守护，就是定期捞取由于系统间通信异常或者超时没有结果回执的订单去交易系统查询订单的真实状态。

还请参阅图2，为本申请实施例提供的一种抽签预约方法中抽签撮合的流程图，该实施例为上述图1中步骤105的具体细化，所述方法包括：

步骤201：在达到所述开始撮合时间时，将所有参加抽签预约活动的可售对象以列表的方式加载到内存中，以及将多个未中签的所述预约单分别以列表的方式加载到内存中；

步骤202：判断可售对象列表是否为空，如果为空，执行步骤209；否则，执行步骤203；

步骤203：从可售对象列表中顺序取出一条可售对象记录；

步骤204：根据所述可售对象记录判断取出的所述可售对象是否还有可售库存，如果有，执行步骤205；否则，执行步骤210；

步骤205：从内存中获取未中签的预约单列表；

步骤206：判断未中签的预约单列表是否为空，如果为空，则执行步骤209；否则，执行步骤207：

步骤207：从所述未中签的预约单列表中随机抽取一条未中签预约单；

其中，可以采用jdk1.6里java.util.random的nextlnt方法从所述未中签的预约单列表中随机抽取一条未中签预约单，当然，也可以采用其他方法， 只要能保证交易完整数据的方法都可以。

步骤208：在所述未中签的所述预约单列表中删除随机抽取到的未中签预约单，返回步骤204；

步骤209：结束抽签；

步骤210：从可售对象列表中删除取出的所述可售对象的记录，返回步骤202。

该实施例中的抽签预约单的状态之间的变化示意图如图3所示，由图3可知，

initial：表示新建立预约单并且可以抽签的状态；

success：表示预约单已经中签并且交易成功的状态；

cancel：表示用户取消了预约单的状态，这种状态下的预约单不参与抽签；

close：表示活动结束之后没有中签的预约单的状态；

sys_close：表示由于后台系统出错连续三次下单都出错预约单被关闭的状态；

user_close：表示由于用户的原因，包括余额不足，账户被冻结，账户被加入黑名单等原因导致的下单失败被关闭的状态。

由图3可知，对于建立的预约单，处于可以抽签状态(initial)，如果预约单中签，则从可以抽签状态可以转变成交易成功的状态，此时的预约单的状态为(success)，当然，如果用户取消预约单，该预约单的状态转变成取消状态(cancel)；如果该预约单没有中签，则该预约单转变成没有中签的状态(close)；另外，预约单中签后，如果系统连续三次下单都出错预约单被关闭，此时预约单的状态为被关闭状态(sys_close)；如果余额不足，账户被冻结，账户被加入黑名单等原因导致的下单失败被关闭的状态为user_close。

本申请实施例中，可售产品的购买通过抽签撮合的方式实现，而不是进行抢购。这不但降低了系统压力，还增强了用户购买产品的公平性，同时也 提高了用户购买的成功几率以及用户购买满意度。

在上述所有实施例中，当抽签预约活动结束后，所述方法还可以包括活动结束处理过程，其流程图如图3a所述，其各个步骤涉及到的执行主体分别以活动结束定时任务模块，产品服务模块：活动服务模块，预约单服务模块，交易服务模块，文件服务模块，短信服务模块，撮合时长服务模块为例，在实际应用中并不限于此，其具体的过程包括：

步骤301：系统中的活动结束定时任务模块通过产品服务模块查询活动所有对象(即产品)超过设定时间(比如10分钟等)没有被锁定的库存；

步骤302：活动结束定时任务模块然后根据查询结果计算并判断活动已成交金额是否等于所有参加活动的产品金额，如果相同，则视为活动结束；

步骤303：如果活动没有结束，则活动结束定时任务模块调用交易服务器模块同步所有预约单的交易状态，并判断活动是否结束；

步骤304：如果活动结束定时任务模块判断活动结束，则调用文件服务模块生成pdf版的中签名单；

步骤305：活动结束定时任务模块调用短信服务模块向用户发送中签通知短息；

步骤306：活动结束定时任务模块调用活动服务模块将该活动的状态标记为结束状态；

步骤307：活动结束定时任务模块通过预约单服务模块取消所有未中签的预约单；

步骤308：活动结束定时任务模块通过产品服务器修改未卖完产品信息开放主动购买；

步骤309：活动结束定时任务模块通过调用撮合市场服务模块更新撮合市场活动状态为停止(st0pped)状态。

与前述抽签预约方法的实施例相对应，本申请还提供了抽签预约装置的实施例。

本申请抽签预约装置的实施例可以应用在设备上。装置实施例可以通过 软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本申请提供的一种抽签预约装置所在设备的一种硬件结构图，除了图4所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的设备通常根据该设备的实际功能，还可以包括其他硬件，对此不再赘述。

请参考图5，为本申请实施例提供的一种抽签预约装置的结构示意图，所述装置包括：获取单元51，确定单元52，展示单元53，接收单元54，撮合单元55和显示单元56，其中，

获取单元51，用于获取参加同期抽签预约活动的可售对象；

确定单元52，用于确定所述可售对象的抽签预约活动信息；所述抽签预约活动信息包括：开始预约时间和开始撮合时间；

展示单元53，用于将所述可售对象的抽签预约信息通过页面展示给用户；

接收单元54，用于在所述开始预约时间内接收所述用户购买所述可售对象的多个预约单，其中，多个所述预约单均为未中签预约单；

其中，接收单元54，具体用于在所述开始预约时间内通过页面表单的方式接收所述用户购买所述对象的多个预约单。

撮合单元55，用于在达到所述开始撮合时间时，从多个所述预约单中随机抽取一条未中签预约单，撮合抽取到的所述未中签预约单和对应的可售对象，对撮合后的所述未中签预约单进行下订单，其中，下订单后的预约单为中签预约单；

显示单元56，用于在所述网页上显示已下订单的用户。

可选的，所述撮合单元55包括：加载单元，提取单元，第一判断单元，获取子单元，抽取单元和删除单元(图中未示)，其中，

加载单元，用于在达到所述开始撮合时间时，将所有参加抽签预约活动的可售对象以列表的方式加载到内存中，以及将多个未中签的所述预约单分 别以列表的方式加载到内存中；

提取单元，用于从可售对象列表中顺序取出一条可售对象记录；

第一判断单元，用于根据所述可售对象记录判断取出的所述可售对象是否还有可售库存；

获取子单元，用于在所述第一判断单元判断所述可售对象有可售库存时，从内存中获取未中签的预约单列表；

抽取单元，用于从所述获取子单元获取的所述未中签的预约单列表中随机抽取一条未中签预约单；

删除单元，用于在所述未中签的所述预约单列表中删除随机抽取到的未中签预约单。

所述撮合单元还包括：第二判断单元(图中未示)，其中，

所述第二判断单元，用于判断可售对象列表是否为空；

所述提取单元，还用于在所述第二判断单元判断所述可售对象列表不为空时，从所述可售对象列表中顺序取出一条可售对象记录。

可选的，所述装置还可以包括：管理单元，用于对中签的所述预约单进行活动管控和活动守护。其中，活动管控和活动守护具体详见上述，在此不再赘述。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

还请参阅图6，为本申请实施例提供的一种抽签预约装置的应用实例图，包括：活动展区模块61、参加活动模块62、开户模块63、活动设置模块64、抽签撮合模块65、下单模块66、活动管控模块67和活动守护模块68，其中，各个模块通过系统总线连接(图中未示)，

活动展示模块61，用于在活动页面上展示部分内容，包括进行中的活动，历时活动信息的展示等；

参加活动模块62，用于通过页面表单的方式，提示用户参加活动，表单需要用户输入预约金额，表单提交时，系统会校验用户账户余额(比如余额 宝金额)是否大于等于预约金额；

开户模块63，用于在用户参加活动时，如果活动需要用户开户，则展示开户页面给用户，并引导用户去开户；

活动设置模块64，用于在接收到后台操作员的指令时，在后台设置活动，即后台操作员在后台设置活动；

抽签撮合模块65，用于通过随机算法撮合活动产品和活动预约单；其具体的撮合过程详见上述，在此不再赘述。其中，随机算法，只要能保证交易完整性的随机算法均可。

下单模块66，用于对撮合成功的预约单调用订单系统接口下单；其下单后的预约单为中签预约单；

活动管控模块67，用于管控活动的开始到结束的一整套生命周期，活动开始的时候会发送消息出来通知撮合中心开启一个抽签撮合的市场等待抽签开始；活动结束后会发送消息通知撮合中心来关闭这个活动抽签撮合的市场，关闭所有没有中签的预约单，发送短信通知抽奖结果，生成pdf格式的中奖名单；

活动守护模块68，用于定期捞取由于系统间通信异常或者超时没有结果回执的订单去交易系统查询订单的真实状态。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。