CN111383084A

CN111383084A - 一种拍卖方法及***

Info

Publication number: CN111383084A
Application number: CN201811622447.7A
Authority: CN
Inventors: 李军浩; 王伟; 阎宗睿; 路希林; 韩世杰; 林琳; 陈霞; 巩仔明; 邱慧
Original assignee: Youxinpai Beijing Information Technology Co ltd
Current assignee: Hefei Youquan Information Technology Co ltd
Priority date: 2018-12-28
Filing date: 2018-12-28
Publication date: 2020-07-07

Abstract

本发明涉及一种拍卖方法，所述方法包括客户端发送竞拍请求，Nginx服务器将拍品静态资源请求的竞拍请求发送给静态资源服务器，将拍品服务请求的竞拍请求发送给controller服务器，Websocket服务器将拍品的竞拍信息推送给竞买人的客户端。本发明的拍卖方法和***，实现了竞价数据的实时响应，有效地保证价格数据的真实性和有效性。

Description

一种拍卖方法及***

技术领域

本发明涉及计算机技术领域，尤其涉及一种拍卖方法和***。

背景技术

网络拍卖(AuctionOnline)是利用互联网通信传输技术通过网络对拍品进行的一种在线物品交易。网络拍卖让商品所有者或某些权益所有人在其平台上独立开展竞价，其议价方式是采用了在线交易模式。

随着互联网通信技术的发展，网络拍卖越来越受到欢迎，而且目前出现了大量的在线竞价***。但是利用当前的在线竞价***进行拍卖的过程中，竞买人对拍品进行竞价时，如果各个竞买人出价信息不能即时同步，会造成竞买人的错误出价或者拍品成交错误，甚至出现流拍情况。因此，价格信息同步即时准确是拍卖流程的基础。

现有拍卖***一般直接采用多台应用服务负载均衡布局，拍卖过程中出价终端按照一定频率，如1s(秒)一次，实时轮询请求拍卖服务器，轮询查询实时价格及拍卖计时。而且实时轮询每秒产生过多的请求连接，会造成服务器请求压力加大，出现数据库处理超时，请求超时，价格不同步的情况。同时，还因负载服务器业务上线影响拍卖的情况。

为解决业务更新影响拍卖、实时出家不同步频繁的问题，需要采用新方法和架构来实现竞价数据的实时响应，保证价格数据的真实有效。

发明内容

针对现有技术中拍卖业务数据更新速度影响拍卖业务、实时出价同步差的问题，本发明公开了一种拍卖方法及其***。

一种拍卖方法，所述方法包括：

客户端发送竞拍请求；

Nginx服务器将拍品静态资源请求的竞拍请求发送给静态资源服务器，将拍品服务请求的竞拍请求发送给controller服务器；

Websocket服务器将拍品的竞拍信息推送给竞买人的客户端。

进一步地，Websocket服务器独立通过thrift和/或netty将拍品的竞拍信息推送给竞买人的客户端。

进一步地，所述拍品服务请求的竞拍请求包括竞拍注册请求。

进一步地，Zookeeper服务器接收所述注册请求，基于所述注册请求对用户状态、参数合法性、拍品状态、保证金中的一个或多个进行验证。

进一步地，Zookeeper服务器接收所述注册请求，基于所述注册请求依次对用户状态、参数合法性、拍品状态、保证金进行验证。

进一步地，用户状态、参数合法性、拍品状态、保证金中的一个或多个无法通过所述验证时，终止拍卖。

进一步地，Controller服务器接收竞价报价的竞拍请求，并将所示竞价报价的竞拍请求推送给客户端。

进一步地，接收到竞价报价的竞拍请求后，状态锁定设备将拍品锁定。

进一步地，所述拍品锁定后，所述controller服务器将所述拍品价格设置为所述拍品当前价格与当前竞价出价的总和。

进一步地，所述controller服务器将竞价报价发送给存储设备进行存储。

进一步地，所述存储设备为写存储设备。

进一步地，拍品成交后，controller服务器将成交后的拍品信息发送到关注列表。

进一步地，Controller服务器发送成交指令，以促成拍品的成交。

进一步地，Controller服务器设置拍卖出价倒计时。

进一步地，Controller服务器设置拍卖出价最低倒计时；在所述最低倒计时内有新的竞价报价，则重置所述最低倒计时。

进一步地，Controller服务器向客户端发送出价提醒消息。

进一步地，通过thrift发送所述竞拍信息。

进一步地，Web竞价***将java语言形成的竞拍信息利用thrift通过第一条推送路径推送给.net竞价***，和/或将java语言形成的竞拍信息利用thrift通过第二推送路径推送给websocket。

进一步地，Websocket服务器基于所述竞拍请求与所述客户端建立数据连接。

进一步地，客户端与推送服务的WebSocket连接断开或在预定时间内接收不到websocket的心跳数据时，客户端手动拉取以主动获取所述竞拍信息。

进一步地，客户端首先尝试用Http或Soap请求推送服务，获取价格信息，然后同时发起对推送服务新的WebSocket连接，如果WebSocket连接失败，所述客户端继续优先以Http/Soap短连接的方式请求价格信息，并再次尝试连接新的WebSocket，与推送服务建立连接。

进一步地，

客户端为移动终端或web端时，用Http请求推送服务；或，

客户端为PC端时，用Soap请求推送服务。

进一步地，Websocket从读取存储设备中获取所述竞拍信息。

进一步地，写存储设备将所述竞拍信息同步到读取存储设备。

进一步地，所述客户端发送拍卖下单请求，以上传拍品信息。

一种拍卖***，所述***包括：

客户端，用于发送竞拍请求；

Nginx服务器，用于将拍品静态资源请求的竞拍请求发送给静态资源服务器，和/或将拍品服务请求的竞拍请求发送给controller服务器；

Websocket服务器，用于将拍品的竞拍信息推送给客户端。

进一步地，所述Websocket服务器为独立设置的服务器，其能够通过thrift和/或netty将拍品的竞拍信息推送给客户端。

进一步地，所述拍卖***还包括Zookeeper服务器，其中，

所述Zookeeper服务器，用于基于注册请求对用户状态、参数合法性、拍品状态、保证金中的一个或多个进行验证；或用于基于所述注册请求依次对用户状态、参数合法性、拍品状态、保证金进行验证。

进一步地，所述拍卖***还包括Controller服务器，其中，

所述Controller服务器，用于接收竞价报价的竞拍请求，并将所述竞价报价的竞拍请求推送给客户端。

进一步地，所述拍卖***还包括状态锁定设备，其中

所述状态锁定，还用于在接收到所述竞价报价的竞拍请求后，将拍品锁定。

进一步地，所述controller服务器，还用于将锁定的所述拍品的拍品价格设置为所述拍品当前价格与当前出价的总和。

进一步地，所述controller服务器，还用于将竞价报价发送给存储设备进行存储。

进一步地，所述controller服务器，还用于将成交后的拍品信息发送到关注列表。

进一步地，所述Controller服务器，还用于发送促成拍品成交的成交指令。

进一步地，所述Controller服务器，还用于设置拍卖出价倒计时。

进一步地，Controller服务器，还用于设置拍卖出价最低倒计时，并在所述最低倒计时内有新的竞价报价时，能够重置所述最低倒计时。

进一步地，所述Controller服务器，还用于向竞买人的客户端发送出价提醒消息。

进一步地，所述客户端，能够手动拉取以主动获取所述竞拍信息。

进一步地，所述客户端，能够首先尝试用Http或Soap请求推送服务，获取价格信息，然后同时发起对推送服务新的WebSocket连接，如果WebSocket连接失败，继续优先以Http/Soap短连接的方式请求价格信息，并再次尝试连接新的WebSocket，与推送服务建立连接。

进一步地，所述拍卖***还包括写存储设备和读取存储设备，其中，

所述写存储设备，用于处理写数据请求；

所述读取存储设备，用于处理读数据请求。

进一步地，所述写存储设备，能够将竞拍信息同步到所述读取存储设备。

进一步地，所述防火墙与所述客户端和Nginx服务器之间。

进一步地，所述客户端，还用于发送拍卖下单请求，以上传拍品信息。

本发明的拍卖方法和***，实现了竞价数据的实时响应，有效地保证价格数据的真实性和有效性；进一步地，本发明的方法和***考虑了不同***的兼容性，多端语言通讯的问题，保证了客户端接受数据的有效性、及时性和正确性。本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所指出的结构来实现和获得。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了根据本发明实施例的拍卖方法基本流程图；

图2示出了根据本发明实施例的拍卖***层架构框图；

图3示出了根据本发明实施例的拍卖***架构结构图；

图4示出了根据本发明实施例的拍卖业务示例流程图；

图5示出了根据本发明实施例的拍卖竞价基本流程示意图；

图6示出了根据本发明实施例的竞拍出价基本流程示意图；

图7示出了根据本发明实施例的向用户推送的流程示意图；

图8示出了根据本发明实施例的用户主动获取竞价信息的流程示意图；

图9示出了根据本发明实施例的竞品信息单机推送流程示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地说明。显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1示出了根据本发明实施例的拍卖方法基本流程图，如图1所示，本发明实施例的拍卖方法，基本包括客户端发送竞拍请求，Nginx服务器将拍品静态资源请求的竞拍请求发送给静态资源服务器，将拍品服务请求的竞拍请求发送给controller服务器，Websocket服务器将拍品的竞拍信息推送给竞买人的客户端。

图2示出了根据本发明实施例的拍卖方法的***层架构框架，如图2所示，本发明实施例的这种层架构框架主要包括五层，从上到下依次为终端访问层、网络层、应用服务层、数据持久层。

客户端位于终端访问层中，客户端可以移动终端(例如ios***的终端或Android***的终端)、PC(个人电脑)等终端，移动终端中可以安装有拍卖APP(应用程序)，PC终端上可以通过浏览器等软件进行拍卖相关操作。

用户(例如拍卖人、竞买人、委托人或者买受人)使用web平台或移动终端等客户端作为访问终端，并通过域名访问拍卖平台。其首先经过网络层中的CDN(内容分发网络)中转，由CDN静态资源缓存的网络层将域名转化为一个真实的IP地址，这个IP地址指向ngnix代理或LVS(linux虚拟服务器集群)。

网络层中还设有多个节点(如图2所示的节点1、节点2、节点3等)，这些节点可以是负载应用在实际web网络的映射或CDN服务器的节点，其数据可以发送到应用服务层中。

应用服务层提供应用服务，主要包括服务器集群、应用集群、SOA业务服务等，含有了控制器、日志、队列、任务、搜索、流程、缓冲以及切库等基础组件。其中，应用服务器集群主要包括LVS(Linux虚拟服务器)、nginx(主要承载软件负载)、F5(主要承载硬件负载)，其提供对外服务；作为一种轻量级的Web服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器，Nginx在本发明实施例的拍卖***和拍卖流程中，提高了数据处理的并发能力。应用集群包含各类业务服务，其中应用服务运行在tomcat容器中。应用服务采用SpringMVC(模型(model)－视图(view)－控制器)架构模式，还采用了ORM(对象关系映射)，ORM能够实现面向对象编程语言里不同类型***的数据之间的转换。SOA业务服务包括通过ESB(企业服务总线)连接网络(dubbo、zookeeper)、和tomcat容器、MVC、ORM(对象关系映射)。

数据访问层包括数据库连接池(dbcp)、和Redis缓存和缓存连接池。单个应用的情况下，用户的请求从nginx到一个应用服务，这个服务运行在tomcat容器里，分为三层：MVC、Service、Dao(数据访问对象)。其中Dao为图2中的数据访问层。Dao连接应用服务层与数据持久层，数据持久层负责数据读写，由SqlServer主从库、Redis主从服务器构成。其中，主SqlServer、Redis为写库(负责写数据请求)，从SqlServer、Redis为读库(负责向其他设备提供数据请求)。本发明实施例中，拍卖过程中产生的竞拍信息(例如，竞价出价、出价时间、竞买人信息、卖方信息、竞品标识等)均写入到写库中(即写入到主SqlServer、Redis)，同时这些数据同步到读库中(即同步到备SqlServer、Redis)，以便于其他设备从读库中读取数据。本发明实施例的这种设计方式使得读写分离，有效地提高了***的处理效率。

因拍卖业务的需求，拍卖***需要每次校验用户登录合法性、用户状态、保证金余额等数据。这些数据的校验效率也会成为***瓶颈而影响整体的数据响应速度。本发明实施例中，将这部分校验功能服务化变为应用服务层中的dubbo服务。在数据校验过程中，可根据数据校验的工作量进行横向扩容，例如设置多个dubbo服务来进行数据校验，以减小主设备压力，便于释放服务器资源接受更多请求。

本发明实施例中，可以实现对拍卖流程的全程服务监控，服务监控从用户发出请求进到应用服务之后的所有范围，能够监控请求的状态及信息，服务监控与整个应用服务是完全解耦的。监控体系实现了***稳定性监控、接口性能监控、接口异常监控、业务数据流程监控的全面监控。对服务的监控过程中，可以进行预警。示例性地，监控拍卖***的请求流量，在达到一定流量时，启动预警。

本发明实施例中这种框架设计方式是一种基础平台组件化架构，实现db(数据库)、cache(缓存)、log(日志框架，包括所有项目的节点监控、实时控制台等)、util(开发过程中用到的工具方法的包)，能够更灵活地支持业务扩展；而且能够实现竞价业务分离，部分基础服务分离Dubbo化，以及实现推送服务推拉结合。这种设置方式还能够有效地实现容错和负载均衡。同时设置多级cache，一级redis缓存，二级ehcache缓存，将数据库采用主从设计，应用层读写分离，而且jekins(基于Java开发的一种持续集成工具)自动化部署，持续集成。

图3示出了根据上述框架结构设计的本发明实施例的架构结构图。以下基于该架构结构图结合其他附图对本发明实施例作进一步介绍。如图3所示，处于终端访问层的客户端可以有多种类型，例如IOS***的智能移动终端、Android***的智能移动终端、基于web的PC电脑终端等。

现有的拍卖***对拍卖过程中产生的各种竞拍请求(例如，注册请求、登录请求、竞价报价请求、获取拍品信息请求、报价信息发送请求、图片提供请求、卖方下单请求、终止拍卖请求等)，直接分发到拍卖***中的负载机。现有的这种***结构，对于静态资源请求和服务请求都会直接访问负载机，因此，每台负载机都需要部署站点所需要的静态资源和服务。这种情况下，每台负载机承担了静态资源和服务的所有请求。而在实际拍卖的通常情况下，请求静态资源的请求数量不低于请求服务的请求连接数，因此在较大的静态资源下载的情况下会占用较大的带宽，这将导致服务响应慢，超时情况会比较频繁。为此，本发明实施例中对拍卖***的***架构进行了优化设计。如图3所示，本发明实施例的拍卖***在应用服务层中采用了Nginx服务器来对用户(例如拍品的竞买人、委托人、买受人、第三方等)通过客户端发送的竞拍请求进行分发。对于拍卖业务，用户的这种竞拍请求主要有两种类型，第一种为静态资源请求，这种竞拍请求针对的数据的更新即时性较低，例如请求获取竞拍车辆等拍品的展示图片、视频等这种实时更新程度低的数据等；第二种为拍品服务请求，这种竞拍请求针对的数据的更新即时性较高，例如拍卖过程中各个竞买人的出价数据、及时终止拍卖等。

竞买人利用其客户端发出基于http的上述竞拍请求(例如对某款奥迪二手车进行竞买的竞拍请求)。该竞拍请求通过防火墙的检测后，进入到Nginx服务器。Nginx服务器对竞买人发送的上述竞拍请求按照上述两种类型进行区分，将静态资源请求导向静态资源服务器(例如图3中的静态页面服务器)，由静态资源服务器承担所有静态资源的请求流量；而将拍品服务请求导向用户请求服务器(例如图3中的controller(控制器))，用户请求服务器承载用户拍品服务请求。本发明实施例的这种对不同类型的竞拍请求分别交由不同的服务器处理的方式，实现了对于静态资源和服务请求流量的分发，保证了服务请求的及时响应不受静态资源的影响。

在线拍卖涉及的工作负荷较大、业务量较多，本发明实施例中，考虑到业务量会对服务器的处理负荷造成压力过大的问题，可以对静态资源服务器进行冗余设置，具体地可通过增加静态资源服务器的方式进行扩展，以降低单一静态资源服务器的处理负荷。同时，考虑到对用户请求的即时性要求较高的特点，也可以对用户请求服务器进行冗余设置，分别设置主用户请求服务器和一个或多个备用户请求服务器。

图4示出根据本发明实施例的拍卖业务示例流程图。如图4所示，竞品拍卖主要涉及买家(即竞买人)、拍卖业务人员、卖家以及作为拍卖平台的拍卖***等各方。

在拍品的竞买过程中，各方需要遵守一定的竞价规则。竞买人可通过买家客户端和/或拍卖平台web网站的交易大厅两种途径来参加拍卖。竞买人的竞价报价数据(包括出价价格、出价时间、出价频率、感兴趣的竞品、成交价等)可以在附图3的买家服务器中作记录。为了对感兴趣的拍品进行竞拍，竞买人须提前注册为交易***(也可以是上述拍卖***)的会员并且缴纳足够的保证金才能参加竞拍。竞价报价过程中，各个竞买人通过附图3中的实时报价服务器进行报价。

卖家可以通过附图3中的订单服务器下单，以将要拍卖的竞品发布到拍卖***中，便于竞买人查询。示例性地，卖家A要对其对某款奥迪二手车进行拍卖，其首先通过订单服务器下单，下单信息可以包括该奥迪车辆的型号、车辆所在地、车辆里程、购置时间、底价、加价幅度、卖家的身份信息等。卖家下单之后，订单服务器对该订单进行审核确认，例如审核车辆信息的真实性、卖家身份的真实性等。审核确认通过后，websocket服务器可以将该下单信息推送给竞买人的终端，以向竞买人展示，便于竞买人出价。

在竞拍拍卖之前中，各方(一般为交易***)可以指定拍卖的时间、场次和拍品等来组织拍卖活动。拍卖过程中，可以对多个拍品依次进行竞拍，对于拍品可以提前设置底价和/或保留价。其中，底价是开拍时的起拍价，保留价决定拍品在多少价位时才允许成交。可以对某个拍品的拍卖初始时间进行设置，例如将拍卖时间设置为30s(秒)，即竞买人要在30秒的时间内出价。竞品开拍后，每个拍品竞拍的初始时间为30s，并开始倒计时，竞买人在拍品起拍价(或者底价)的基础上进行加价。当竞买人出的最高价超过保留价并且不再有其他竞买人出价时，可以将该拍品的状态设置为成交状态；当拍品在30s时间内无竞买人出价或者竞买人最终的出价最高价未超过保留价时，可以将该拍品的状态设置为流拍状态。在当前拍品拍卖倒计时计为0时，拍卖***对拍品进行成交处理，如果买家出价最高价超过拍品保留价，拍品成交；反之，则拍品流拍。websocket推送服务给各终端推送成交信息。客户端接收到成交信息后，根据成交信息，进行显示。至此，对于当前拍品的竞拍结束。

此外，拍卖过程中，业务工作人员可以通过拍卖***及时保持与卖家或拍卖人的沟通，当竞买人最高价未超过保留价或超过一定值时，若卖家有意愿成交，可通过controller发送成交指令将拍品保留价切换到当前买家最高价或切换到竞买人的出价，以促进拍品成交。本发明实施例中，拍卖***还可以设置提醒功能，示例性地，在当前拍品距离保留价差一手出价时，***可以发送出价提醒消息来提醒竞买人，只差一手出价，以促进成交。拍卖***的上述设置功能可以在PC桌面端设置完成。

本发明实施例的拍卖方法和拍卖***，在买家参与拍卖后，可以通过拍卖***竞价，并且成交获得拍品；卖家通过拍卖***下单，可以将其拍品上拍；拍卖业务人员在拍卖过程中可以实时与卖家保持沟通，在卖家许可的情况下，通过成交设置功能促进成交，或者拍品价格距离保留价差一手出价时通过差一手功能提醒买家，催进成交。

本发明实施例中，对竞价过程中产生的即时性要求较高的信息(例如竞价过程中的价格数据、价格同步等)利用单独的websocket服务器进行推送。具体地，可以在应用服务层中设置单独的WebSocket请求服务器，其独立负责竞价报价的同步。同时，在本发明实施例的拍卖***中，还设置controller这种Http服务器，该controller对非高即时性请求(例如登录验证、各类字典接口、拍品列表、拍品详情等)进行响应。示例性地，要求在一定时间(例如1秒、100毫秒)之内作出相应的信息作为即时性要求较高的信息，不必然要求在一定时间之内作出相应的信息作为非高即时性要求较高的信息。

本发明实施例中WebSocket请求服务器的选用，使得服务器与客户端之间交换的标头信息很小，客户端与服务器之间都可以主动传送数据给对方，而且不用频繁创建TCP请求及销毁请求，这种方式减少了网络宽带资源的占用，同时也节省了服务器资源。

本发明实施例中，采用了WebSocket请求服务器实现了将现有WebService请求优化为WebSocket长连接。这种设计方式使得现有的每秒轮询的请求方式优化为服务器主动推送，并进一步具有以下优点：WebSocket长连接减少了客户端对服务器实时轮询造成的大量请求的压力；WebSocket请求服务器主动推送提高了终端价格同步的响应时间。而现有的方式，在同步价格时必须等到1s(秒)时发起请求，终端的响应时间>1s，这导致响应时间较长，极大影响客户体验，并会影响拍卖的正常运行。本发明实施例的WebSocket请求服务器主动推送，在任何时候，只要有出价信息就可以最快推送到终端，终端的响应间隔可以最快达到网络传输的时间，提高了数据更新速度并保证了竞价报价的同步。

图5示出了根据本发明实施例的拍卖竞价基本流程。如图5所示，拍品竞买过程前，每个竞买人通过各自的客户端进行拍卖注册。本发明实施例中图3的zookeeper服务器接收到竞买人的注册信息后，对用户状态等进行判断。示例性地，判断本次请求连接的session(会话)这类用户状态是否有效，其中，Session中一般保存用户登录成功时的用户账户名称、相关联金融账号、登录时间、登录是否超时等信息。

ZooKeeper在本发明实施例拍卖***的使用实现了对在拍卖流程中产生的各种数据封装，能够将简单易用的接口和性能高效、功能稳定的***提供给用户。

在用户状态正常时对参数(例如登录sesssion(会话)是否有效)合法性进行判断。参数合法时，对拍品状态(例如，拍品状态是否为正在拍卖)进行校验。对拍品状态校验通过后，对竞买用户的保证金(例如保证金是否足够)进行校验，以核实竞买人提交的保证金是否符合对拍品的竞价要求。在上述各步骤如果不通过则返回，并认定此次注册无效；上述各步骤都通过后进入竞价报价拍卖流程。本发明实施例中的上述校验、判断、核实等确认步骤均可以通过SOA(面向服务的架构)业务服务实现。

在对保证金的校验成功后，执行竞价报价事务。竞买人针对感兴趣的竞拍进行出价，出价成功后，买家服务器对该拍品进行加锁处理以对该拍品锁定。买家服务器对该拍品锁定后，修改当前拍品价格为拍品当前价格与此次出价的总和。示例性地，拍卖过程中拍品当前已经达到1800元，而此次出价为200，则总和为1800+200＝2000。同时将出价纪录写入数据库(例如图3中的sqlserver服务器和/或redis服务器)。本发明实施例中，对拍品的锁定保证了本次修改只作用于本次请求，防止并发的其他出价请求(例如其他竞买人的竞价报价请求)同时修改价格，造成加价错误。竞买人竞价报价成功后，controller异步更新缓存并将此拍品添加到出价用户关注列表里。

买家服务器可以作为一种状态锁定设备继续对拍品状态(例如拍品是否被拍得并成交、拍品是否被撤下)进行校验，以防止出现拍品出现不能拍卖、或者已经被其他竞买人竞得后还被继续拍卖的情况。同时，还对拍品的竞买报价等进行记录，例如***会纪录买家每次出价的纪录，包括出价用户id、出价时间、当前竞拍价、本次用户加价价格等***记录信息。

如图6示出了根据本发明实施例的竞拍出价基本流程。如图6所示，各个竞买人对目标竞品进行竞价报价，各个竞买人的竞价报价信息通过nginx服务器分发到控制器controller。controller的业务逻辑模块对接收到的竞价报价信息进行校验，以验证竞价报价信息的合法性。竞价报价信息的合法性验证通过后，将竞价报价信息发送给作为推送服务器的websocket服务器和redis服务器中。本发明实施例中，设置了竞价报价数据的校验过程，其通过对比用户的竞价数据与数据库中最新竞价数据来判断用户当前竞价操作是否为有效的。本发明实施例中，将通过校验的竞价数据写入数据库(例如sqlserver)，并同时更新缓存(例如redis)，有效地保证拍卖竞价数据的一致性及原子性，同一事物(对同一个拍品的同一次的拍卖)内所有操作同时成功或是同时失败，保证避免出现数据写时出现部分执行成功、部分失败的情况。

本发明实施例中，用户有效性、报价有效性和竞价报价消息是否为最新最即时消息等校验直接在请求路由的过程中还没到达服务中时校验，非有效的消息就直接返回，这样不用占用服务资源。

竞价报价过程中，拍品价格的同步至关重要，因此在本发明实施例中，利用Thrift和Netty通过WebSocket对拍品的价格信息进行推送。竞价报价信息经过nginx等设备被推送到手机端、Web端和PC端等客户端进行回显，以便于竞买人能够实时查看到目标竞品的出价报价信息。推送过程中，Websocket可以从读库中读取竞品的价格信息等所有信息，并进行推送。

Thrift的使用，实现了可扩展且跨语言的服务的开发，其能够提供以构建在C++、Java、Go，Python、PHP、Ruby、Erlang、Perl、Haskell、C#、Cocoa、JavaScript、Node、.js、Smalltalk、和OCaml这些编程语言间无缝结合的、高效的服务。

Netty利用了Java的高级网络的能力，隐藏其背后的复杂性而提供了易于使用的API的客户端/服务器框架，所以Netty作为一个Java网络编程框架在本发明实施例中，使得拍卖***中客户端、服务端的数据管理更加方便。图7示出了根据本发明实施例的向用户推送的流程示意图。如图7所示，竞买人或其他用户通过其终端发送带有拍品标识publishID参数的连接请求后，websocket向该终端反馈连接成功消息。此后，竞买人可以通过终端进行竞价报价，并且websocket服务器提供推送服务，将其他竞买人的竞价信息和拍卖计时信息推送给竞买人。

手机端、Web端和PC端等客户端接收到拍品的价格信息后，在其显示单元进行价格更新显示。如图7所示，对于竞品1，websocket会将最新竞价信息推送给终端，并在推送消息中包含当前拍卖倒计时剩余时间。为了提高拍品的竞品效率，本发明实施例中，还设置了倒计时功能，例如设置在预定时间段内进行出价，如果在预定时间段内没有出价，则以该预定时间段之前的出价为准作为最终的成交价格。示例性地，在计时时间为23秒时，推送竞价报价1000元，计时时间为20秒时，推送竞价报价1200元。本发明实施例中，通过websocket推送的方式，实现了只要有新的竞价报价就能够立即推送的目的，但是同样也可以设置为以预定的时间周期推送、在指定的时间推送。

在上述倒计时的基础上，本发明实施例还设置最低倒计时。如果在最低倒计时时间内有竞买人继续出价，则重置该最低倒计时。示例性地，本发明实施例中，对于拍品的出价时间设置在10秒内出价。如图7所示，在第四次竞价报价后，对拍品1的出价时间设置为10秒，在10秒内有竞买人出价为1800，则重置出价倒计时时间为10秒。在重置的10秒内，有竞买人继续出价为2000，则继续重置出价倒计时时间为10秒，直至拍品1的最终成交。进一步地，也可以在倒计时时间内设置出价次数以促进拍品的成交。

在拍品成交后，可以向用户终端推送拍品成交信息，成交信息例如包括竞买人信息、拍品价格信息、拍卖时长信息、拍品标识、拍品底价信息、拍品图片信息、拍品描述信息、拍品所在地等等。

本发明实施例中，对于拍品1的推送任务完成后，可以切换到拍品2的信息推送。对于拍品2的推送流程与拍品1的推送流程相同，在此不再赘述。

价格推送服务与终端通过WebSocket长连接进行价格信息同步，但在网络波动、网络瞬间断开、或单个推送连接阻塞的情况下，同步服务的长连接会断开或无响应，造成价格同步消息接收不到。为了应对这些情况，本发明实施例中设置了用户主动获取价格信息的方式，例如通过手动拉取获取价格信息进行价格同步。

图8示出了根据本发明实施例的用户主动获取竞价信息的流程示意图。如图8所示，拍品1竞拍到剩余18秒时，终端与推送服务的WebSocket连接终端断开，此时终端会首先尝试用Http/Soap请求推送服务，获取价格信息，然后同时发起对推送服务新的WebSocket连接，如果WebSocket连接失败，终端继续优先以Http/Soap短连接的方式请求价格信息，并再次尝试连接新的WebSocket，与推送服务建立连接。

建立WebSocket时，需要校验拍品标识PublishID，但是这种方式比较耗时，所以本发明实施例优先以Http/Soap做一个短连接拉取，保证拍品价格拉取的即时性。手机端和/或Web端以Http方式发起手动拉价请求(例如智能终端的用户手动下拉页面进行更新以发起拉价请求)，PC桌面端以Soap(WebService)方式发起拉价请求。该拉价请求可以包含拍品标识PublishID以便于明确针对的拍品。连接成功后，继续接收websocket发送的推送信息。

发起手动拉取时，本发明实施例中，可以以终端WebSocket断开连接的状态和超过预定时间(例如5秒)终端接收不到推送端WebSocket心跳包为准则。

进一步地，websocket服务器还将目标竞品的出价报价信息推送到sqlserver服务器和/或redis服务器中。为了向竞买人直观显示自己的出价信息，业务逻辑还将该竞买人的出价报价信息反馈给竞买人使用的报价终端。

对于竞品信息的推送，如图5所示，controller通过thrift、Netty向websocket服务器发送报价信息。因为拍卖***中，同一功能的应用工程都存在以.Net架构实现的应用和以Java架构实现的应用，其分别对应移动端和web端，所以本发明实施例还兼顾了旧***(兼容webservice***)，不同的***之间的通信使用thrift，其实现了跨***之间的数据通信。在竞拍过程中，竞买人、委托人、买受人等对信息获取的基本务需求是，当同一拍品有用户出价竞价成功，同时看这一拍品的所有用户都需看到实时的最高价及其他数据。

竞价入口一般分为移动端和web端，这两种终端分别对应.net应用接口及java应用接口。由对应终端进行数据校验，校验通过后开启竞价事务。竞价事务成功执行之后，由websocket通过thrift推送竞价信息，实现实时数据的流转。如图2所示，移动端与web端与服务端可以通过WebSocket长连接实现数据的互通。由于WebSocket这种推送端功能单一，所以适合独立出来。各终端通过对应的.net应用接口或java应用接口接收竞价推送消息，同时推送服务器会将缓存(例如redis服务器)中的数据更新为最新的数据。由于通过WebSocket长连接推送的数据有细微的差别所以实现了不同用户看到的数据的差异性。但基础数据是透明的，公开的，相同的。

图9示出了根据本发明实施例的竞品信息单机推送流程示意图，其示出了竞价报价成功后从买家服务器的出价服务到推送服务器(websocket服务器)的单机推送流程，该流程考虑了不同***的兼容性。如图9所示，竞价成功后，web竞价***将java语言形成的竞价信息利用thrift通过第一条推送路径推送给.net竞价***，将java语言形成的竞价信息利用thrift通过第二推送路径推送给websocket。.net竞价***在竞价成功后，或者在接收到web竞价***发送来的竞价信息后，同步推送给websocket。

因拍卖业务的实际需求，当同一拍品有用户出价竞价成功，同时关注这一拍品的所有用户都需看到实时的最高价及其他数据。因此，本发明实施例中，Websocket接收到竞价信息后，发送给缓存(例如redis)以对缓存中的数据进行更新，并通过thrift以长连接推送给用户的终端，例如通过thrift推送给用户手机的APP，以向用户展示，实现实时数据的流转。图5中也展示了不同***间竞价消息推送的流程结构。旧***在竞价过程中、成交后，记录竞价信息、竞价时间、保证金等竞价信息，通过将该竞价信息通过thrift异步推送给controller、客户端，并可以通知拍卖***的APP。本发明实施例中的设计方式，考虑了不同***的兼容性，例如现在有些拍卖网站及app服务端利用了C#语言，而有些***的服务端采用java语言进行***升级，新旧***之间要求具有较好的兼容性，以便于拍卖业务的接续及统一的性能扩展。

本发明实施例中，对最新的有效数据(例如，用户有效性、报价有效性和竞价报价消息是否为最新最即时消息等)，通过一定的数据封装(例如有效的出价消息将会封装成给java项目和net项目的)之后进行推送。相关服务器通过websocket长连接实现与客户端的通信。本发明实施例中选用WebSocket的原因是长连接建立一次后可复用通道进行通讯。可以节省***资源不必频繁的建立http请求通讯，推送的服务端可以在通道存在的任意时刻推送消息，服务端只需将推送过来的数据进行简单的解析即可。

如图6所示，Redis服务器接收到校验通过的出价报价信息后，将有效数据(例如，用户有效包括登录时效有效、登录状态不超时、用户保证金充足等；报价有效包括竞价报价的价格高于当前最高价等；、消息是即时的，即没有因网络原因成滞后的消息等)发送给sqlserver进行存储。本发明实施例中，为了对发送的数据实现确认，在redis服务器和sqlserver收到数据后会向数据的发送方反馈确认信息。例如，redis服务器接收到业务逻辑发送的报价信息后，向业务逻辑反馈数据已经接收到的确认信息；sqlserver服务器接收到redis发送的数据后，向redis服务器发送数据已经接收到的确认信息。

拍卖过程中，各个竞买人的加价信息会存储到redis缓存服务器中。同时，竞买过程中，为了向各方提供其关注的数据(例如，某些竞买人关注出价的速度、出价数值等数据)，将这些数据发送给相关方。

竞买人竞得拍品后，可以启动付款流程。示例性地，竞买人竞得上述奥迪二手车后，拍卖***中的用户财务服务器将扣除该奥迪二手车的价款，转让到卖家服务器中的卖家账户中。卖家服务器将该奥迪二手车过户到买家。所有的价款转账、过户等数据均可以发送到sqlserver服务器和redis服务器中。

为了进一步拍卖方法和***的可靠性，本发明实施例对拍卖***中的部分设备进行了冗余设置。如图3所示，对controller服务器设置主备服务器，在主controller服务器出现故障时，由备controller服务器替代主controller执行拍卖。为了提高查询效率，本发明实施例中，可以对zookeeper服务器、买家服务器、买家服务器、用户财务服务器、订单服务器、实时报价服务器、sqlserver、redis服务器进行主备设置，以提高***的冗余性能和数据处理效率，并可以在通主备设备进行负荷分担。

本发明中各个步骤之间并非必然紧密相连，除非特别声明，并不排除两个步骤之间还有其他步骤的情况，只要实现本发明的目的，均在本发明的范围之内。本发明所声称的***，可以由单个设备、多个设备、单个元件或多个元件构成。各单元、设备、***之间并不必然表示有线地、直接地连接，间接连接或者无线连接只要能够实现本发明的目的，均中本发明的范围内。

尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims

1.一种拍卖方法，所述方法包括：

客户端发送竞拍请求；

Websocket服务器将拍品的竞拍信息推送给竞买人的客户端。

2.根据权利要求1所述的拍卖方法，其中，

Websocket服务器独立通过thrift和/或netty将拍品的竞拍信息推送给竞买人的客户端。

3.根据权利要求1所述的拍卖方法，其中，

所述拍品服务请求的竞拍请求包括竞拍注册请求。

4.根据权利要求3所述的拍卖方法，其中，

Zookeeper服务器接收所述注册请求，基于所述注册请求对用户状态、参数合法性、拍品状态、保证金中的一个或多个进行验证。

5.根据权利要求3所述的拍卖方法，其中，

Zookeeper服务器接收所述注册请求，基于所述注册请求依次对用户状态、参数合法性、拍品状态、保证金进行验证。

6.根据权利要求4或5所述的拍卖方法，其中，

用户状态、参数合法性、拍品状态、保证金中的一个或多个无法通过所述验证时，终止拍卖。

7.根据权利要求1所述的拍卖方法，其中，

Controller服务器接收竞价报价的竞拍请求，并将所示竞价报价的竞拍请求推送给客户端。

8.根据权利要求7所述的拍卖方法，其中，

接收到竞价报价的竞拍请求后，状态锁定设备将拍品锁定。

9.根据权利要求8所述的拍卖方法，其中，

所述拍品锁定后，所述controller服务器将所述拍品价格设置为所述拍品当前价格与当前竞价出价的总和。

10.根据权利要求7-9任一所述的拍卖方法，其中，

所述controller服务器将竞价报价发送给存储设备进行存储。

11.根据权利要求10所述的拍卖方法，其中，

所述存储设备为写存储设备。

12.根据权利要求7所述的拍卖方法，其中，

拍品成交后，controller服务器成交后的拍品信息发送到关注列表。

13.根据权利要求7所述的拍卖方法，其中，

Controller服务器发送成交指令，以促成拍品的成交。

14.根据权利要求7所述的拍卖方法，其中，

Controller服务器设置拍卖出价倒计时。

15.根据权利要求14所述的拍卖方法，其中，

Controller服务器设置拍卖出价最低倒计时；在所述最低倒计时内有新的竞价报价，则重置所述最低倒计时。

16.根据权利要求7所述的拍卖方法，其中，

Controller服务器向客户端发送出价提醒消息。

17.根据权利要求1所述的拍卖方法，其中，

通过thrift发送所述竞拍信息。

18.根据权利要求1或17所述的拍卖方法，其中，

Web竞价***将java语言形成的竞拍信息利用thrift通过第一条推送路径推送给.net竞价***，和/或将java语言形成的竞拍信息利用thrift通过第二推送路径推送给websocket。

19.根据权利要求1所述的拍卖方法，其中，

Websocket服务器基于所述竞拍请求与所述客户端建立数据连接。

20.根据权利要求19所述的拍卖方法，其中，

客户端与推送服务的WebSocket连接断开或在预定时间内接收不到websocket的心跳数据时，客户端手动拉取以主动获取所述竞拍信息。

21.根据权利要求20所述的拍卖方法，其中，

客户端首先尝试用Http或Soap请求推送服务，获取价格信息，然后同时发起对推送服务新的WebSocket连接，如果WebSocket连接失败，所述客户端继续优先以Http/Soap短连接的方式请求价格信息，并再次尝试连接新的WebSocket，与推送服务建立连接。

22.根据权利要求21所述的拍卖方法，其中，

客户端为移动终端或web端时，用Http请求推送服务；或，

客户端为PC端时，用Soap请求推送服务。

23.根据权利要求1所述的拍卖方法，其中，

Websocket从读取存储设备中获取所述竞拍信息。

24.根据权利要求1、11或23所述的拍卖方法，其中，

写存储设备将所述竞拍信息同步到读取存储设备。

25.根据权利要求1所述的拍卖方法，其中，

所述客户端发送拍卖下单请求，以上传拍品信息。

26.一种拍卖***，所述***包括：

客户端，用于发送竞拍请求；

Websocket服务器，用于将拍品的竞拍信息推送给客户端。

27.根据权利要求26所述的拍卖***，其中，

所述Websocket服务器为独立设置的服务器，其能够通过thrift和/或netty将拍品的竞拍信息推送给客户端。

28.根据权利要求26所述的拍卖***，所述拍卖***还包括Zookeeper服务器，其中，

29.根据权利要求26所述的拍卖***，所述拍卖***还包括Controller服务器，其中，

30.根据权利要求29所述的拍卖***，所述拍卖***还包括状态锁定设备，其中

31.根据权利要求30所述的拍卖***，其中，

所述controller服务器，还用于将锁定的所述拍品的拍品价格设置为所述拍品当前价格与当前出价的总和。

32.根据权利要求29-31任一所述的拍卖***，其中，

所述controller服务器，还用于将竞价报价发送给存储设备进行存储。

33.根据权利要求29-31任一所述的拍卖***，其中，

所述controller服务器，还用于将成交后的拍品信息发送到关注列表。

34.根据权利要求29-31任一所述的拍卖***，其中，

所述Controller服务器，还用于发送促成拍品成交的成交指令。

35.根据权利要求29-31任一所述的拍卖***，其中，

所述Controller服务器，还用于设置拍卖出价倒计时。

36.根据权利要求35任一所述的拍卖***，其中，

Controller服务器，还用于设置拍卖出价最低倒计时，并在所述最低倒计时内有新的竞价报价时，能够重置所述最低倒计时。

37.根据权利要求29-31任一所述的拍卖***，其中，

所述Controller服务器，还用于向竞买人的客户端发送出价提醒消息。

38.根据权利要求26所述的拍卖***，其中，

所述客户端，能够手动拉取以主动获取所述竞拍信息。

39.根据权利要求26所述的拍卖***，其中，

所述客户端，能够首先尝试用Http或Soap请求推送服务，获取价格信息，然后同时发起对推送服务新的WebSocket连接，如果WebSocket连接失败，继续优先以Http/Soap短连接的方式请求价格信息，并再次尝试连接新的WebSocket，与推送服务建立连接。

40.根据权利要求26所述的拍卖***，所述拍卖***还包括写存储设备和读取存储设备，其中，

所述写存储设备，用于处理写数据请求；

所述读取存储设备，用于处理读数据请求。

41.根据权利要求40所述的拍卖***，其中，

所述写存储设备，能够将竞拍信息同步到所述读取存储设备。

42.根据权利要求26所述的拍卖***，所述***还包括防火墙，其中

所述防火墙与所述客户端和Nginx服务器之间。

43.根据权利要求26所述的拍卖***，其中，

所述客户端，还用于发送拍卖下单请求，以上传拍品信息。