本申请涉及互联网技术领域，特别涉及一种订单处理方法、交易系统及服务器。
背景技术：
随着互联网技术的不断发展，诞生了越来越多的在线旅游平台。这些在线旅游平台例如可以包括携程网、去哪儿网、驴妈妈旅游网、途牛网等等。在这些在线旅游平台中，一部分在线旅游平台对其销售的资源并不享有实际的控制权。例如，在线旅游平台销售的资源可以是门票、机票、酒店空床位等等。然而，门票、机票或者酒店空床位这些资源的实际控制方并非是在线旅游平台，而是对应的景点、航空公司或者酒店。
目前，资源的实际控制方通常会在多个在线旅游平台中同时销售固定的资源。例如，航空公司目前可以出售100张机票，那么该航空公司可以同时在去哪儿网、携程网、驴妈妈旅游网等在线旅游平台同时销售这100张机票。
目前，这些对资源不具备实际控制权的在线旅游平台在销售资源时，通常有两种销售方式。一种方式是当用户在在线旅游平台下达订单后，在线旅游平台可以通过资源的控制方提供的接口，去资源的控制方处查询该资源实际剩余的库存量。当实际剩余的库存量足够时，便可以从剩余的库存量中锁定一部分资源，在用户付款之后便可以将锁定的这部分资源发送给用户。这种方式的缺陷在于：资源的控制方提供的接口性能不是很理想，在线旅游平台在调用接口时需要等待较长时间才能获得当前剩余的库存量。这样不仅会降低资源销售的效率，也会直接导致用户等待订单确认的时间比较久。
另一种方式是每当资源控制方的库存量发生变动时，资源控制方便通过在线旅游平台提供的接口，对在线旅游平台中的库存量进行改动，以使得在线旅游平台中剩余的库存量与资源控制方实际剩余的库存量一致。这样，当用户进行下单时，在线旅游平台只需查看本地剩余的库存量，便可以及时地获知当前实际剩余的库存量是否充足。这种方式可以在用户下单时立即给用户反馈购买成功或者购买失败，解决了第一种方式中销售效率低的问题。然而这种方法存在一个新的问题：在线旅游平台接口的调用频率和次数通常是有限制的，一旦资源控制方调用接口过于频繁或者调用接口的次数达到上限，便无法及时对在线旅游平台中的库存量进行更新。这就导致在线旅游平台中显示还有充足的资源库存量，但实际上资源控制方已经销售完所有的资源了。这样的话，用户在下单并且付款之后，在线旅游平台无法给用户提供相应的资源，这无疑会极大地影响用户的购买体验。
由上可见，现有技术中在线旅游平台在销售资源时，通常存在销售效率低的问题。此外，当用户在付款后无法获取相应资源时，在线旅游平台便形成了“超卖”的现象，这样会被用户投诉，给在线旅游平台带来较大的损失。
技术实现要素：
本申请实施方式的目的是提供一种订单处理方法、交易系统及服务器，能够改善现有技术中销售效率低，以及容易形成“超卖”现象的问题。
为实现上述目的，本申请实施方式提供一种订单处理方法，应用于业务服务器，所述业务服务器上存储有资源的虚拟库存，所述虚拟库存用于记录商家服务器提供的资源数量，且所述虚拟库存的库存量根据商家服务器实际提供的资源数量进行更新，所述订单处理方法包括：接收订单请求，所述订单请求中包括资源预订数量；确认所述虚拟库存是否满足所述资源预订数量；在满足时，利用所述虚拟库存中的资源来处理所述订单请求，并向所述订单请求的发送方反馈成功信息；所述成功信息用于表示所述订单请求成功预定了所述资源预订数量个资源。
为实现上述目的，本申请实施方式还提供一种业务服务器，所述服务器包括：网络通信端口、处理器、存储器，其中：所述网络通信端口，用于进行网络数据通信；所述存储器，用于存储虚拟库存；所述处理器，用于控制所述网络通信端口接收订单请求，所述订单请求中包括资源预订数量；确认所述虚拟库存是否满足所述资源预订数量；在满足时，利用所述虚拟库存中的资源来处理所述订单请求，并控制所述网络通信端口向所述订单请求的发送方反馈成功信息；所述成功信息用于表示所述订单请求成功预定了所述资源预订数量个资源。
为实现上述目的，本申请实施方式还提供一种交易系统，所述系统包括：资源处理服务器、业务服务器、商家服务器，其中，所述业务服务器存储虚拟库存，所述商家服务器存储实际库存，所述虚拟库存的库存量根据商家服务器的实际库存的库存量进行更新；所述资源处理服务器向所述业务服务器发出订单请求；所述订单请求中包括资源预订数量；所述业务服务器接收订单请求，所述订单请求中包括资源预订数量；确认所述虚拟库存是否满足所述资源预订数量；在满足时，利用所述虚拟库存中的资源来处理所述订单请求，并向所述订单请求的发送方反馈成功信息；所述成功信息用于表示所述订单请求成功预定了所述资源预订数量个资源。
为实现上述目的，本申请实施方式还提供一种订单处理方法，所述订单处理方法包括：向业务服务器发出订单请求；所述订单请求中包括资源预订数量；所述资源预订数量用于所述业务服务器根据虚拟库存判断是否可以生成订单；接收所述业务服务器反馈的订单信息；所述订单信息表示所述虚拟库存满足所述资源预订数量；向客户端发送所述订单信息。
为实现上述目的，本申请实施方式还提供一种资源处理服务器，包括网络通信端口和处理器，其中：所述网络通信端口，用于进行网络数据通信；所述处理器，用于控制所述网络通信端口向业务服务器发出订单请求；所述订单请求中包括资源预订数量；所述资源预订数量用于所述业务服务器根据虚拟库存判断是否可以生成订单；控制所述网络通信端口接收所述业务服务器反馈的订单信息；所述订单信息表示所述虚拟库存满足所述资源预订数量；控制所述网络通信端口向客户端发送所述订单信息。
本申请实施方式提供的一种订单处理方法、交易系统及服务器，通过在资源处理服务器和商家服务器之间增加业务服务器，并且将业务服务器和商家服务器中的库存量进行同步，从而能够直接通过业务服务器和资源处理服务器完成与用户的交易过程。业务服务器在处理订单请求时，可以避免与商家服务器进行查询的操作，从而能够保证商家服务器不会由于过多地接收到查询请求而导致的响应慢、负载高等问题，这样便可以提高资源销售效率，并且解决了“超卖”的问题。
附图说明
为了更清楚地说明本申请实施方式或现有技术中的技术方案，下面将对实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施方式提供的一种订单处理的方法流程图；
图2为本申请实施方式中交易流程的示意图；
图3为本申请实施方式提供的一种业务服务器的结构示意图；
图4为本申请实施方式提供的一种订单处理方法流程图；
图5为本申请实施方式提供的一种资源处理服务器的结构示意图；
图6为本申请实施方式提供的一种交易系统的示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施方式中的附图，对本申请实施方式中的技术方案进行清楚、完整地描述，显然，所描述的实施方式仅仅是本申请一部分实施方式，而不是全部的实施方式。基于本申请中的实施方式，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施方式，都应当属于本申请保护的范围。
现有的在线旅游平台进行资源销售的系统架构，通常包括资源处理服务器和商家服务器。其中，所述资源处理服务器可以是在线旅游平台的后台服务器，在所述资源处理服务器中，可以存储在线旅游平台中的各项数据。例如，所述资源处理服务器中可以包括各个资源的库存量、用户的订单信息、各个资源的物流信息等。所述资源处理服务器可以与用户的客户端进行数据交互。例如，用户在客户端中加载某个资源的页面时，资源处理服务器可以将该页面中待显示的价格信息、库存信息等发送至所述客户端，以在客户端中完成页面显示的过程。用户在客户端中下达订单后，所述资源处理服务器可以接收客户端发来的订单信息，并对所述订单信息进行处理。
所述商家服务器可以是资源控制方的后台服务器。所述资源控制方例如可以是航空公司、酒店、景点等对资源具备实际控制权的单位。在所述商家服务器中可以存储资源的实际剩余库存。所述商家服务器可以接收资源处理服务器发来的资源获取请求，并响应于该资源获取请求，将一定数量的资源锁定并分配给资源处理服务器。例如，资源处理服务器发来的资源获取请求中可以包括资源的请求数量，那么所述商家服务器在验证了所述资源处理服务器的权限后，便可以从剩余的库存中，将与所述请求数量等量的资源分配给所述资源处理服务器，从而完成对这部分资源的销售。
在本实施方式中，以上或者以下描述的服务器，均可以为一个具有数据运算、存储功能以及网络交互功能的电子设备；也可以为运行于该电子设备中，为数据处理、存储和网络交互提供支持的软件。
在本实施方式中并不具体限定所述服务器的数量。所述服务器可以为一个服务器，还可以为几个服务器，或者，若干服务器形成的服务器集群。
在本实施方式中，所述服务器可以为在线旅游平台的业务服务器，所述业务服务器中可以存储与在线旅游平台相关的数据。例如，所述业务服务器中可以保存在线旅游平台中用户的注册信息、在在线旅游平台中销售的资源的库存以及在线旅游平台在运行时产生的日志等。
在本实施方式中，以上或者以下描述的客户端可以是用于浏览在线旅游平台并可以在在线旅游平台上进行资源购买的电子设备。具体地，所述客户端例如可以是台式电脑、平板电脑、笔记本电脑、智能手机、数字助理、智能可穿戴设备、导购终端、具有网络访问功能的电视机等。或者，所述客户端也可以为能够运行于上述电子设备中的软件。具体的，所述客户端可以为电子设备中的浏览器，所述浏览器中可以加载在线旅游平台提供的访问入口。所述在线旅游平台例如可以是携程网、去哪儿网、驴妈妈旅游网、途牛网等，所述访问入口可以是上述在线旅游平台的首页。所述客户端还可以为在线旅游平台提供的在智能终端中运行的应用。例如，所述应用可以为手机携程等。
在本申请实施方式中，可以在所述商家服务器和所述资源处理服务器之间，设置业务服务器，所述业务服务器可以与多个商家服务器或者与多个资源处理服务器进行连接。例如，多个在线旅游平台中均在销售由航空公司提供的100张机票以及由旅游景点提供的50张门票。所述航空公司的业务服务器以及所述旅游景点的业务服务器均可以与所述业务服务器建立连接。同时，这多个在线旅游平台的后台服务器也均与所述业务服务器建立连接。这样，通过所述业务服务器，资源控制方的信息可以同时在多个资源销售方共享。
在本实施方式中，业务服务器在与商家服务器和资源处理服务器进行数据交互时，可以通过在商家服务器和资源处理服务器中安装应用的方式来实现。例如，在各个在线旅游平台的后台服务器上均可以安装共享应用，该共享应用的后台服务器便可以是所述业务服务器。该共享应用可以被资源处理服务器中的程序进行调用，从而可以通过该共享应用，实时地与业务服务器进行数据交换。同样地，在商家服务器中也可以安装共享应用，并通过调用安装的共享应用，实时地与业务服务器进行数据交换。
请参阅图1和图2，本申请实施方式提供一种订单处理方法，该方法的执行主体可以是所述业务服务器，所述业务服务器上存储有资源的虚拟库存，所述虚拟库存用于记录商家服务器提供的资源数量，且所述虚拟库存的库存量根据商家服务器实际提供的资源数量进行更新，所述方法可以包括以下步骤。
s1：接收订单请求，所述订单请求中包括资源预订数量。
在本实施方式中，用户通过客户端在在线旅游平台中选择了目标资源后，可以同时选择目标资源的数量，从而可以通过点击购买按键的方式向资源处理服务器发送订单下达指令。
在本实施方式中，所述订单下达指令中通常可以包括用户标识、资源标识以及资源预订数量。其中，所述用户标识可以是用户的账号，该账号可以是用户在在线旅游平台中预先注册的，也可以是在线旅游平台自动分配给用户的游客账号。所述资源标识可以是用户欲购买的资源在在线旅游平台中的编号。所述资源预订数量可以是用户欲购买的资源的数量。
在本实施方式中，当资源处理服务器接收到用户客户端发来的订单下达指令后，需要确认当前是否有充足的资源能够满足用户的订单需求。与现有技术中不同的是，在本实施方式中所述资源处理服务器并非直接向商家服务器查询当前剩余的实际库存，而是向所述业务服务器发送订单请求。
在本实施方式中，所述订单请求可以是按照预设规则进行编写的字符串。其中，所述预设规则可以是符合网络通信协议的规则。例如，所述订单请求可以是按照http协议进行编写的字符串。所述预设规则可以限定订单请求中的各个组成部分以及各个组成部分之间的排列顺序。例如，所述订单请求中可以依次包括请求类型、源ip地址、目标ip地址。其中，所述请求类型可以是查询类型，每个类型均可以对应一个预设的关键字。例如查询类型对应的关键字可以是query。所述源ip地址可以填写所述资源处理服务器的ip地址，所述目标ip地址可以填写所述业务服务器的ip地址。
在本实施方式中，所述订单请求中通常还可以包括资源预订数量，所述资源预订数量可以是用户在购买资源的过程中确定的。当然，在实际应用场景中，如果所述业务服务器中存在多种类型的资源的信息，那么在所述订单请求中还可以包括资源标识。这样，通过所述资源标识和所述资源预订数量，所述业务服务器便可以准确获知当前待确定的资源以及待确定的资源数量。
在本实施方式中，所述业务服务器和所述资源处理服务器之间可以通过网络传输协议进行数据通信。所述网络传输协议例如可以包括tcp/ip协议、ftp协议、http协议、imap协议等。具体地，所述业务服务器和所述资源处理服务器之间进行通信的数据可以根据数据类型的不同，采用不同的网络传输协议。例如，对于邮件数据而言，可以采用smtp协议；对于页面数据而言，可以采用http协议。通常，各个协议可以与网络通信端口相绑定。例如，所述网络通信端口可以是负责进行web数据通信的80号端口，也可以是负责进行ftp数据通信的21号端口，还可以是负责进行邮件数据通信的25号端口。这样，所述业务服务器接收订单请求的方式可以包括通过与所述订单请求的数据类型相对应的网络通信端口，接收资源处理服务器发来的订单请求。
s2：确认所述虚拟库存是否满足所述资源预订数量。
在本实施方式中，所述业务服务器中可以具备资源的虚拟库存。所述业务服务器中的初始虚拟库存可以是在商品发布时录入至业务服务器中的。例如，航空公司拟出售100张机票，那么在航空公司的商家服务器中发布了100张机票后，可以将该100张机票的库存量录入业务服务器中，从而使得业务服务器具备了初始虚拟库存。
在本实施方式中，所述虚拟库存还可以与商家服务器中的实际库存进行同步，这样，所述业务服务器中的虚拟库存便可以与所述商家服务器中的实际库存保持一致。
在本实施方式中，所述虚拟库存与商家服务器中的实际库存进行同步的方式可以包括业务服务器按照预设周期向商家服务器发送库存量同步请求，并接收所述商家服务器反馈的包含当前实际库存的同步信息，从而可以根据将虚拟库存修改为所述同步信息中的当前实际库存。具体地，所述预设周期可以根据资源的类型和/或当前的时间段进行设置。当所述资源的类型属于热门资源类型时，资源的销售速度通常比较快，此时，为了能够使得业务服务器中的虚拟库存与商家服务器中的实际库存保持一致，所述预设周期可以设置得偏短。例如所述预设周期可以设置为2s。此外，还可以根据各个在线旅游平台销售资源的历史记录，确定销售速度较快的时间段。在销售速度较快的时间段(例如节假日前夕)，可以将所述预设周期设置得偏短。当然，除了资源类型和当前时间段，在实际应用场景中还可以根据其它因素灵活地调整所述预设周期，或者可以将所述预设周期设置为固定值。
在本实施方式中，所述虚拟库存与商家服务器中的实际库存进行同步的方式还可以包括业务服务器按照预设周期与商家服务器预先提供的通信地址进行交互，以查询所述商家服务器中当前的实际库存，并将虚拟库存修改为查询得到的实际库存。所述通信地址可以是所述商家服务器在网络中的ip地址，也可以是所述商家服务器的对应的域名，所述域名经过域名解析系统可以解析得到所述商家服务器在网络中的ip地址。这样，业务服务器在需要进行库存量同步时，可以向所述通信地址发送同步指令。所述同步指令中可以包括所述业务服务器的通信地址。这样，在所述商家服务器接收到所述同步指令后，可以响应于该同步指令，向所述业务服务器的通信地址反馈自身当前的实际库存。具体地，所述同步指令例如可以是http协议中的request报文。在所述request报文中，可以包括源ip地址和目的ip地址，所述源ip地址可以是所述业务服务器的ip地址，所述目的ip地址可以是所述商家服务器的ip地址。这样，在商家服务器接收到所述同步指令后，便可以获知业务服务器的ip地址，从而可以将自身的实际库存发送至所述业务服务器。此外，在本实施方式中，在所述商家服务器中可以预先存储所述业务服务器的ip地址。这样，在商家服务器接收到业务服务器发来的同步指令后，便可以根据本地存储的所述业务服务器的ip地址，向所述业务服务器反馈自身当前的实际库存。
在本实施方式中，业务服务器接收到资源处理服务器发来的订单请求时，可以确认所述虚拟库存是否满足所述资源预订数量，而不需要再向商家服务器发送资源数量的查询请求。在本实施方式中，业务服务器可以采用分布式或者集群式的方式进行部署，这样，在处理订单请求时，能够具备较高的处理效率。业务服务器在处理订单请求时，可以避免与商家服务器进行查询的操作，从而能够保证商家服务器不会由于过多地接收到查询请求而导致的响应慢、负载高等问题。这样，相比于现有技术中每个订单请求均需要与商家服务器发生通信的方式，本申请的技术方案能够减缓商家服务器的压力，从而提高了订单请求处理的效率。
在本实施方式中，确认所述虚拟库存是否满足所述资源预订数量可以包括将所述资源预订数量与所述虚拟库存的库存量进行对比。当所述资源预订数量小于或者等于所述虚拟库存的库存量时，则表明当前具备足够的资源提供给用户，则可以表示所述虚拟库存满足所述资源预订数量；而当所述资源预订数量大于所述虚拟库存的库存量时，则表明所述虚拟库存不满足所述资源预订数量，无法提供足够的资源给用户。
s3：在满足时，利用所述虚拟库存中的资源来处理所述订单请求，并向所述订单请求的发送方反馈成功信息；所述成功信息用于表示所述订单请求成功预定了所述资源预订数量个资源。
在本实施方式中，当满足时，表明当前具备足够的资源提供给用户，此时可以利用所述虚拟库存中的资源来处理所述订单请求，并向所述订单请求的发送方反馈成功信息。所述订单请求的发送方可以是所述资源处理服务器。当然，在一些具体应用场景中，用户的客户端可以与业务服务器直接进行交互，这样，所述订单请求的发送方便可以是用户的客户端。
在本实施方式中，利用所述虚拟库存中的资源来处理所述订单请求可以指根据所述订单请求中的资源预订数量，在所述虚拟库存中进行减量操作。其中，所述减量操作可以指从虚拟库存中扣除一部分的资源数量，使得虚拟库存减少。进行减量操作的目的在于，能够为发送订单请求的用户锁定一部分的资源，这些锁定的资源便可以是进行减量操作的资源。锁定的资源在一定时长内只可以被发送订单请求的用户独占，而无法提供给其它用户。这样，通过减量操作的方式，便可以实时地更改业务服务器中的虚拟库存，从而避免同一份资源同时提供给多个用户。
在本实施方式中，在利用所述虚拟库存中的资源来处理所述订单请求之后，可以在虚拟库存中锁定与所述资源预订数量等量的资源，并将锁定的资源从虚拟库存中扣除。在锁定资源时，可以在虚拟库存中随机锁定一部分的资源或者按照编号顺序锁定一部分的资源。例如，当资源为相同大小的空床位时，用户在下达订单时可以提供空床位的数量。这样，业务服务器在锁定空床位时，可以在虚拟库存中随机锁定与用户的订单请求中限定的空床位数量等量的空床位。此外，在锁定资源时，还可以根据订单请求中限定的资源编号进行锁定。所述资源编号可以用来唯一表征各个资源。例如，所述资源编号可以是电影票的座位号、机票的座位号、客房的房间号等。这样，业务服务器在锁定资源时，可以在虚拟库存中锁定与订单请求中的资源编号相同的资源。在本实施方式中，所述成功信息可以用于表示订单请求成功预定了所述资源预订数量个资源。所述成功信息中可以包括预定的资源信息以及提示信息。所述预定的资源信息可以包括预定的资源数量以及资源编号。例如，预定的资源可以为机票，成功信息中可以包括机票的数量，也可以包括各个机票的座位号。所述提示信息可以是预先编辑的文字模板，用于在用户的客户端中进行显示。所述提示信息例如可以为“您已成功预定”，在该提示信息后可以填充相应的预定的资源信息。例如，所述预定的资源信息可以为“2张车票，座位号分别为8排9座和8排10座”。这样，反馈给订单请求发送方的成功信息便可以为“您已成功预定2张车票，座位号分别为8排9座和8排10座”。当然，在实际应用场景中，所述成功信息中还可以包含预定的资源的更多细节。例如，所述成功信息中还可以包括电影票的厅号、开映时间、结束时间；还可以包括机票的航站楼、航班号、起飞时间和降落时间等。
在本申请一个实施方式中，所述业务服务器可以与多个商家服务器进行连接。这样，所述业务服务器中可以存储不同类别的资源。例如，所述业务服务器中可以存储机票、酒店空房、景点门票等。为了区分不同的资源，在本实施方式中，所述业务服务器中不同类别的资源可以通过资源标识进行区分。所述资源的类别例如可以包括机票、车票、景点门票以及酒店空房中的至少一种。所述资源标识可以是分配给各个资源的唯一标识。通过资源标识可以确定对应的资源。这样，在所述订单请求中可以包括资源标识。业务服务器在接收到订单请求后，可以根据其中包含的资源标识来确定资源的类别。例如可以确定用户需要订机票还是酒店空房。这样，在确认所述虚拟库存是否满足所述资源预订数量时，可以在所述虚拟库存中读取所述资源标识对应的资源的数量，然后可以确认所述资源标识对应的资源的数量是否大于或者等于所述资源预订数量。当大于或者等于时，便可以生成相应的订单。
在本申请一个实施方式中，虚拟库存中的资源可以与多个资源标签进行绑定。所述资源标签可以是用于表征资源的属性的字符串。所述资源的属性例如可以包括时间、地理位置、房型、舱型中的至少一种。例如，对于机票而言，其绑定的资源标签可以反映其起飞时间、起飞地点、中转地点、降落地点、经济舱还是头等舱等属性。这样，在确认所述虚拟库存是否满足所述资源预订数量时，可以在所述虚拟库存中读取所述至少一个资源标签对应的资源的数量，然后可以确认所述至少一个资源标签对应的资源的数量是否大于或者等于所述资源预订数量。当大于或者等于时，便可以生成相应的订单。
在本申请一个实施方式中，当所述虚拟库存不满足所述资源预订数量时，可以向所述订单请求的发送方反馈交易失败信息。其中，所述虚拟库存不满足所述资源预订数量可以包括所述资源预订数量大于所述虚拟库存的库存量。当所述资源预订数量大于所述虚拟库存的库存量时，则表明目前的库存量不能够满足用户订单中的资源预订数量，从而可以向用户反馈交易失败信息。
在本申请一个实施方式中，在从所述虚拟库存中扣除所述资源预订数量个资源之后，还可以以下步骤。
s4：向商家服务器发送库存变动信息；所述库存变动信息附带所述资源预订数量；所述库存变动信息用于所述商家服务器针对其存储的实际库存进行减量操作。
在本实施方式中，当业务服务器中进行减量操作后，业务服务器的虚拟库存会发生变化。此时，为了保证实际的库存数量能够同步更新，可以向商家服务器发送库存变动信息，以提醒所述商家服务器修改当前的实际库存。其中，所述库存变动信息中可以附带所述资源预订数量。具体地，所述业务服务器可以通过发送http报文的方式或者通过调用所述商家服务器的接口的方式，向所述商家服务器发送所述库存变动信息。这样，在所述商家服务器接收到所述库存变动信息时，便可以在当前剩余的库存量中减去所述资源预订数量。例如，商家服务器中和业务服务器中同步的机票库存量均为28张，若当前业务服务器响应于订单请求，在虚拟库存中对3张机票进行了减量操作，那么便可以将业务服务器中的机票库存量修改为25张。同时，业务服务器可以向商家服务器发送包含3张机票的库存变动信息，从而让商家服务器将实际库存修改为25张。
由上可见，所述库存变动信息可以用于所述商家服务器针对其存储的实际库存进行减量操作。所述减量操作可以指从实际库存中扣除一部分的资源数量，使得实际库存减少。进行减量操作的目的在于，能够将业务服务器为用户预定的资源从实际库存中去除，从而避免同一份资源同时提供给多个用户。
在本实施方式中，所述商家服务器针对其存储的实际库存进行减量操作的方式可以包括在实际库存中扣除与所述资源预订数量等量的资源。具体地，如果各个资源彼此之间都是可以替代的，那么在扣除资源时，可以在实际库存中随机扣除一部分的资源或者按照编号顺序扣除一部分的资源。例如，当资源为相同大小的空床位时，用户在下达订单时仅需提供空床位的数量。这样，商家服务器在扣除空床位时，可以在实际库存中随机扣除与库存变动信息中限定的空床位数量等量的空床位。然而，如果各个资源彼此之间不可替代，那么在扣除资源时，可以根据库存变动信息中限定的资源编号进行扣除。所述资源编号可以用来唯一表征各个资源。例如，所述资源编号可以是电影票的座位号、机票的座位号、客房的房间号等。这样，商家服务器在扣除资源时，可以在实际库存中扣除与库存变动信息中的资源编号相同的资源。
在本申请一个实施方式中，所述虚拟库存的库存量根据商家服务器实际提供的资源数量进行更新时，可以包括以下子步骤。
s5：接收所述商家服务器发送的库存同步信息；所述库存同步信息附带所述商家服务器进行所述减量操作后的实际库存。
在本实施方式中，业务服务器可以是分布式或者集群式的部署方式，因此在同一时刻可以有多个服务器在处理不同在线旅游平台的资源处理服务器发来的订单请求。这样，每个订单请求均可以引起商家服务器中实际库存的变化。为了使得每个业务服务器中的虚拟库存与实际库存保持同步，业务服务器可以接收所述商家服务器发送的库存同步信息。所述库存同步信息可以附带所述商家服务器进行所述减量操作后的实际库存。
在本实施方式中，所述库存同步信息可以是商家服务器按照预设周期向业务服务器发送的库存量同步请求，所述库存量同步请求中可以包括所述商家服务器进行所述减量操作后的实际库存。当然，所述库存同步信息的产生方式还可以包括业务服务器按照预设周期向所述商家服务器发送库存量同步请求，响应于该库存量同步请求，所述商家服务器向所述业务服务器反馈携带进行减量操作后的实际库存的库存量同步信息。具体地，所述预设周期可以根据资源的类型和/或当前的时间段进行设置。当所述资源的类型属于热门资源类型时，资源的销售速度通常比较快，此时，为了能够使得业务服务器中的虚拟库存与商家服务器中进行减量操作后的实际库存保持一致，所述预设周期可以设置得偏短。例如所述预设周期可以设置为2s。此外，还可以根据各个在线旅游平台销售资源的历史记录，确定销售速度较快的时间段。在销售速度较快的时间段(例如节假日前夕)，可以将所述预设周期设置得偏短。当然，除了资源类型和当前时间段，在实际应用场景中还可以根据其它因素灵活地调整所述预设周期，或者可以将所述预设周期设置为固定值。
在本实施方式中，所述库存同步信息还可以由业务服务器按照预设周期与商家服务器预先提供的通信地址进行交互得到。所述通信地址可以是所述商家服务器在网络中的ip地址，也可以是所述商家服务器的对应的域名，所述域名经过域名解析系统可以解析得到所述商家服务器在网络中的ip地址。这样，业务服务器在需要进行库存量同步时，可以向所述通信地址发送同步指令。所述同步指令中可以包括所述业务服务器的通信地址。这样，在所述商家服务器接收到所述同步指令后，可以响应于该同步指令，向所述业务服务器的通信地址反馈自身当前的实际库存。具体地，所述同步指令例如可以是http协议中的request报文。在所述request报文中，可以包括源ip地址和目的ip地址，所述源ip地址可以是所述业务服务器的ip地址，所述目的ip地址可以是所述商家服务器的ip地址。这样，在商家服务器接收到所述同步指令后，便可以获知业务服务器的ip地址，从而可以将自身的当前库存量发送至所述业务服务器。此外，在本实施方式中，在所述商家服务器中可以预先存储所述业务服务器的ip地址。这样，在商家服务器接收到业务服务器发来的同步指令后，便可以根据本地存储的所述业务服务器的ip地址，向所述业务服务器反馈自身当前的实际库存。
需要说明的是，当与业务服务器相连的商家服务器的数量为至少两个时，所述业务服务器还可以通过统一的接口平台接收各个商家服务器发来的库存同步信息。在所述统一的接口平台中，可以存储各个商家服务器的ip地址。其中，每个商家服务器的ip地址可以与商家服务器的标识相关联。这样，所述统一的接口平台接收来自各个商家服务器发来的库存同步信息时，可以根据发送库存同步信息的发送方的ip地址，确定出商家服务器的标识。这样，所述统一的接口平台便可以调用业务服务器的接口，从而将业务服务器中与发送库存同步信息的商家服务器相对应的虚拟库存进行同步。
s6：根据所述减量操作后的实际库存修改所述虚拟库存。
在本实施方式中，业务服务器在接收到商家服务器发来的库存同步信息后，便可以根据所述库存同步信息中的实际库存修改所述虚拟库存。具体地，业务服务器可以提取所述库存同步信息中的实际库存，然后将虚拟库存修改为所述实际库存。在进行库存量修改时，业务服务器可以将虚拟库存删除，并重新写入提取的所述实际库存。此外，业务服务器还可以逐一对比提取的实际库存与虚拟库存中的每个资源，并将所述实际库存中不包含的资源从虚拟库存中删除。
在本申请一个实施方式中，还可以提供存储有商品库存的资源处理服务器，所述业务服务器可以不用一直主动更新所述资源处理服务器中的商品库存。这样处理的目的在于，如果当前剩余的实际库存还比较充足，那么在资源处理服务器中的库存量可以不必十分精确，从而可以不用给资源处理服务器的接口施加过多负载。例如，当前实际剩余的机票库存量为100张，表明当前的机票还比较充足。因此，尽管在资源处理服务器中的库存量为130张(用户在在线旅游平台中看到的剩余机票数也为130)，此时也没有必要将资源处理服务器中的库存量更新为100张。不过，当剩余的实际库存较少时，则可以将资源处理服务器中的库存量进行实时更新。具体地，在本实施方式中，在所述业务服务器中的虚拟库存发生更改后，所述业务服务器可以将虚拟库存的当前库存量与阈值进行对比。若所述业务服务器中当前的库存量低于所述阈值时，所述业务服务器可以向所述商家服务器发送库存补充提示，并将所述资源处理服务器中的库存量修改为所述当前库存量。
在本实施方式中，所述阈值可以是根据销售的资源的类型和/或当前的时间段进行预先设置的。当所述资源的类型属于热门资源类型时，资源的销售速度通常比较快，此时，所述阈值可以设置得偏大。这样，能够及时在在线旅游平台中显示实际剩余的库存量，以提醒用户尽快购买。此外，还可以根据各个在线旅游平台销售资源的历史记录，确定销售速度较快的时间段。在销售速度较快的时间段(例如节假日前夕)，可以将所述阈值设置得较大。当然，除了资源类型和当前时间段，在实际应用场景中还可以根据其它因素灵活地调整所述阈值，或者可以将所述阈值设置为固定值。
在本实施方式中，在所述业务服务器中当前库存量低于所述阈值时，表明当前实际剩余的库存量已经不多了。此时为了能够保证正常销售，可以向所述商家服务器发送库存补充提示，以提醒资源控制方在商家服务器中增加资源的库存量。此外，所述业务服务器可以向所述资源处理服务器发送库存量修改提示，以使得所述资源处理服务器将商品库存修改为所述当前库存量。这样，在用户刷新在线旅游平台的页面时，便可以查看到经过修改的实际剩余库存量。
在本实施方式中，所述业务服务器在与资源处理服务器进行数据交互时，可以通过在资源处理服务器中安装应用的方式来实现。例如，在各个在线旅游平台的后台服务器上均可以安装共享应用，该共享应用的后台服务器便可以是所述业务服务器。由于该共享应用位于所述资源处理服务器中，从而可以直接调用所述资源处理服务器的操作系统中的api(applicationprogramminginterface，应用程序编程接口)，从而对所述资源处理服务器中存储的库存量进行修改。
在本申请一个实施方式中，当资源处理服务器接收到用户客户端发来的订单下达指令时，可以预先将所述订单下达指令中的资源预订数量与本地的库存量进行对比。当所述资源预订数量小于或者等于所述资源处理服务器的商品库存时，表明当前实际剩余的库存量有可能可以满足用户的订单。此时，所述资源处理服务器可以再向所述业务服务器发送包含所述资源预订数量的订单请求。
在本实施方式中，如果所述资源预订数量大于所述资源处理服务器的商品库存时，则表明连所述资源处理服务器本地的库存量都已经无法满足用户的订单，此时则可以直接向所述用户客户端返回交易失败信息。
在本实施方式中，这样处理用户的订单下达指令的依据在于，当实际剩余的库存量比较充足时，资源处理服务器中的库存量不会与业务服务器中的库存量实时同步，此时如果所述资源预订数量小于或者等于所述资源处理服务器的商品库存时，表明当前实际剩余的库存量有可能可以满足用户的订单。具体能否满足则需要进一步地将所述资源预订数量与业务服务器的虚拟库存进行对比。通过上述内容可知，资源处理服务器中的库存量通常会大于或者等于业务服务器中的库存量，这样，如果所述资源预订数量大于所述资源处理服务器的商品库存，那么所述资源预订数量也会大于所述业务服务器中的虚拟库存，从而可以直接通过资源处理服务器向用户客户端返回交易失败信息，无需再去业务服务器中进行确认。
在一个具体应用场景中，航空公司需要销售100张机票，在两个在线旅游平台中可以销售这100张机票。在这两个在线旅游平台各自的后台服务器中库存量均可以是100张。同时，在航空公司的商家服务器中以及业务服务器中的库存量也同样是100张。业务服务器每5s可以与商家服务器同步一次库存量。当一个用户在其中一个在线旅游平台上购买3张机票时，可以通过该在线旅游平台的后台服务器向业务服务器发送订单请求，该订单请求中包含的资源预订数量为3。此时，业务服务器可以确定当前剩余的库存量能够满足用户订单的需求，因此可以向资源处理服务器发送交易成功的提示信息。同时，所述业务服务器将自身的虚拟库存修改为97，并且向商家服务器发送库存变动信息。商家服务器接收到库存变动信息后，也可以将库存量修改为97。同时，在该在线旅游平台的后台服务器中可以生成提供给用户的订单，同时可以将自身的库存量也修改为97。此时，在另一个在线旅游平台上又有一个用户购买了3张机票，此时按照同样的流程，在本次交易过后，商家服务器和业务服务器中的库存量均为94张，而这两个在线旅游平台中的库存量均为97张。在该场景中，在业务服务器中设置的阈值为20张，由此可见当前剩余的实际库存还相当充足，因此可以不对在线旅游平台的资源处理服务器中的库存量进行修改。只有当剩余的实际库存低于20张时，才在每次交易之后，实时更新在线旅游平台的资源处理服务器中的库存量。
请参阅图3，本申请还提供一种业务服务器，所述服务器包括：网络通信端口100、处理器200以及存储器300。
其中，所述网络通信端口100，用于进行网络数据通信。
所述存储器200，用于存储虚拟库存；
所述处理器300，用于控制所述网络通信端口100接收订单请求，所述订单请求中包括资源预订数量；确认所述虚拟库存是否满足所述资源预订数量；在满足时，利用所述虚拟库存中的资源来处理所述订单请求，并控制所述网络通信端口100向所述订单请求的发送方反馈成功信息；所述成功信息用于表示所述订单请求成功预定了所述资源预订数量个资源。
在本实施方式中，所述网络通信端口100可以是与不同的通信协议进行绑定，从而可以发送或接收不同数据的虚拟端口。例如，所述网络通信端口可以是负责进行web数据通信的80号端口，也可以是负责进行ftp数据通信的21号端口，还可以是负责进行邮件数据通信的25号端口。此外，所述网络通信端口还可以是实体的通信接口或者通信芯片。例如，其可以为无线移动网络通信芯片，如gsm、cdma等；其还可以为wifi芯片；其还可以为蓝牙芯片。
在本实施方式中，所述存储器200可以是用于保存信息的记忆设备。在数字系统中，能保存二进制数据的设备可以是存储器；在集成电路中，一个没有实物形式的具有存储功能的电路也可以为存储器，如ram、fifo等；在系统中，具有实物形式的存储设备也可以叫存储器，如内存条、tf卡等。
所述处理器300可以按任何适当的方式实现。例如，处理器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式等等。本申请并不作限定。
上述实施方式公开的业务服务器，其网络通信端口100、存储器200和处理器300实现的具体功能，可以与本申请中订单处理方法实施方式相对照解释，可以实现本申请的订单处理方法实施方式并达到方法实施方式的技术效果。
在本申请一个实施方式中，所述处理器300还可以包括：
减量操作单元，用于在所述虚拟库存满足所述资源预订数量时，针对所述虚拟库存进行减量操作。
在本申请一个实施方式中，所述处理器还用于在所述虚拟库存发生更改后，将所述虚拟库存的当前库存量与阈值进行对比；若所述当前库存量低于所述阈值，向所述商家服务器发送库存补充提示，并向所述资源处理服务器发送库存量修改提示，以使得所述资源处理服务器将商品库存修改为所述当前库存量。
本申请实施方式还提供一种计算机存储介质，其上存储有可被处理器执行的计算机程序，请参阅图1，所述计算机程序在被处理器执行时，可实现以下步骤：
s1：接收订单请求，所述订单请求中包括资源预订数量；
s2：确认所述虚拟库存是否满足所述资源预订数量；
s3：在满足时，利用所述虚拟库存中的资源来处理所述订单请求，并向所述订单请求的发送方反馈成功信息；所述成功信息用于表示所述订单请求成功预定了所述资源预订数量个资源。
在本实施方式中，所述计算机存储介质可以是用于保存信息的记忆设备。在数字系统中，能保存二进制数据的设备可以是存储介质；在集成电路中，一个没有实物形式的具有存储功能的电路也可以为存储介质，如ram、fifo等；在系统中，具有实物形式的存储设备也可以叫存储介质，如内存条、tf卡等。
请参阅图4，本申请还提供一种订单处理方法，所述方法的执行主体可以是资源处理服务器，所述资源处理服务器存储有商品库存，所述方法可以包括以下步骤。
s11：向业务服务器发出订单请求；所述订单请求中包括资源预订数量；所述资源预订数量用于所述业务服务器根据所述虚拟库存判断是否可以生成订单。
在本实施方式中，用户通过客户端在在线旅游平台中选择了目标资源后，可以同时选择目标资源的数量，从而可以通过点击购买按键的方式向资源处理服务器发送订单下达指令。
在本实施方式中，所述订单下达指令中通常可以包括用户标识、资源标识以及资源预订数量。其中，所述用户标识可以是用户的账号，该账号可以是用户在在线旅游平台中预先注册的，也可以是在线旅游平台自动分配给用户的游客账号。所述资源标识可以是用户欲购买的资源在在线旅游平台中的编号。所述资源预订数量可以是用户欲购买的资源的数量。
在本实施方式中，当资源处理服务器接收到用户客户端发来的订单下达指令后，需要确认当前是否有充足的资源能够满足用户的订单需求。与现有技术中不同的是，在本实施方式中所述资源处理服务器并非直接向商家服务器查询当前剩余的实际库存，而是向所述业务服务器发送订单请求。
在本实施方式中，所述订单请求可以是按照预设规则进行编写的字符串。其中，所述预设规则可以是符合网络通信协议的规则。例如，所述订单请求可以是按照http协议进行编写的字符串。所述预设规则可以限定订单请求中的各个组成部分以及各个组成部分之间的排列顺序。例如，所述订单请求中可以依次包括请求类型、源ip地址、目标ip地址。其中，所述请求类型可以是查询类型，每个类型均可以对应一个预设的关键字。例如查询类型对应的关键字可以是query。所述源ip地址可以填写所述资源处理服务器的ip地址，所述目标ip地址可以填写所述业务服务器的ip地址。
在本实施方式中，所述订单请求中通常还可以包括资源预订数量，所述资源预订数量可以是用户在购买资源的过程中确定的。当然，在实际应用场景中，如果所述业务服务器中存在多种类型的资源的信息，那么在所述订单请求中还可以包括资源标识。这样，通过所述资源标识和所述资源预订数量，所述业务服务器便可以准确获知当前待确定的资源以及待确定的资源数量。
在本实施方式中，所述资源预订数量可以用于让所述业务服务器根据所述业务服务器的虚拟库存判断是否可以生成订单。具体地，所述业务服务器可以比较所述资源预订数量与所述业务服务器的虚拟库存的大小。当所述资源预订数量小于或者等于所述业务服务器中的虚拟库存的库存量时，则表明当前具备足够的资源提供给用户，那么所述业务服务器则判定可以生成订单。相反，当所述资源预订数量大于所述业务服务器中的虚拟库存的库存量时，所述业务服务器则判定不可以生成订单。
s21：接收所述业务服务器反馈的订单信息；所述订单信息表示所述虚拟库存满足所述资源预订数量。
在本实施方式中，当所述资源预订数量小于或者等于所述业务服务器中的虚拟库存的库存量时，可以表明所述虚拟库存满足所述资源预订数量。这样，所述业务服务器便可以生成订单信息，并将所述订单信息反馈至资源处理服务器。这样，所述资源处理服务器便可以接收所述业务服务器反馈的订单信息。
在本实施方式中，所述订单信息可以用于表示订单请求成功预定了所述资源预订数量个资源。所述订单信息中可以包括预定的资源信息以及提示信息。所述预定的资源信息可以包括预定的资源数量以及资源编号。例如，预定的资源可以为机票，订单信息中可以包括机票的数量，也可以包括各个机票的座位号。所述提示信息可以是预先编辑的文字模板，用于在用户的客户端中进行显示。所述提示信息例如可以为“您已成功预定”，在该提示信息后可以填充相应的预定的资源信息。例如，所述预定的资源信息可以为“2张车票，座位号分别为8排9座和8排10座”。这样，资源处理服务器接收到的订单信息便可以为“您已成功预定2张车票，座位号分别为8排9座和8排10座”。当然，在实际应用场景中，所述订单信息中还可以包含预定的资源的更多细节。例如，所述订单信息中还可以包括电影票的厅号、开映时间、结束时间；还可以包括机票的航站楼、航班号、起飞时间和降落时间等。
s31：向客户端发送所述订单信息。
在本实施方式中，所述资源处理服务器接收到所述订单信息后，便可以向客户端发送所述订单信息，从而在客户端的当前页面中向用户显示该订单信息。
在本申请一个实施方式中，所述业务服务器可以不用一直主动更新所述资源处理服务器中的库存量。这样处理的目的在于，如果当前剩余的实际库存还比较充足，那么在资源处理服务器中的库存量可以不必十分精确，从而可以不用给资源处理服务器的接口施加过多负载。例如，当前实际剩余的机票库存量为100张，表明当前的机票还比较充足。因此，尽管在资源处理服务器中的库存量为130张(用户在在线旅游平台中看到的剩余机票数也为130)，此时也没有必要将资源处理服务器中的库存量更新为100张。不过，当剩余的实际库存较少时，则可以将资源处理服务器中的库存量进行实时更新。具体地，在本实施方式中，在所述业务服务器中的虚拟库存发生更改后，所述业务服务器可以将虚拟库存的当前库存量与阈值进行对比。若所述业务服务器中当前库存量低于所述阈值时，所述业务服务器可以向所述资源处理服务器发送库存量修改指令，所述库存量修改指令中可以携带所述业务服务器中的当前库存量。这样，在接收到所述业务服务器发来的库存量修改指令后，所述资源处理服务器便可以将资源处理服务器的商品库存修改为所述库存量修改指令中的所述当前库存量，从而能够实时地在在线旅游平台的页面中显示真实的库存数量。
在本申请一个实施方式中，当资源处理服务器接收到用户客户端发来的订单下达指令时，可以预先将所述订单下达指令中的资源预订数量与本地的库存量进行对比。当所述资源预订数量小于或者等于所述资源处理服务器的商品库存时，表明当前实际剩余的库存量有可能可以满足用户的订单。此时，所述资源处理服务器可以再向所述业务服务器发送包含所述资源预订数量的订单请求。
在本实施方式中，如果所述资源预订数量大于所述资源处理服务器的商品库存时，则表明连所述资源处理服务器本地的库存量都已经无法满足用户的订单，此时则可以直接向所述用户客户端返回交易失败信息。
在本实施方式中，这样处理用户的订单下达指令的依据在于，当实际剩余的库存量比较充足时，资源处理服务器中的库存量不会与业务服务器中的库存量实时同步，此时如果所述资源预订数量小于或者等于所述资源处理服务器的商品库存时，表明当前实际剩余的库存量有可能可以满足用户的订单。具体能否满足则需要进一步地将所述资源预订数量与业务服务器的虚拟库存进行对比。通过上述内容可知，资源处理服务器中的库存量通常会大于或者等于业务服务器中的库存量，这样，如果所述资源预订数量大于所述资源处理服务器的商品库存，那么所述资源预订数量也会大于所述业务服务器中的虚拟库存的库存量，从而可以直接通过资源处理服务器向用户客户端返回交易失败信息，无需再去业务服务器中进行确认。
请参阅图5，本申请还提供一种资源处理服务器，所述包括网络通信端口110和处理器210。
在本实施方式中，所述网络通信端口110，用于进行网络数据通信。
所述处理器210，用于控制所述网络通信端口110向业务服务器发出订单请求；所述订单请求中包括资源预订数量；所述资源预订数量用于所述业务服务器根据虚拟库存判断是否可以生成订单；控制所述网络通信端口110接收所述业务服务器反馈的订单信息；所述订单信息表示所述虚拟库存满足所述资源预订数量；控制所述网络通信端口110向客户端发送所述订单信息。
在本实施方式中，所述网络通信端口110可以是与不同的通信协议进行绑定，从而可以发送或接收不同数据的虚拟端口。例如，所述网络通信端口可以是负责进行web数据通信的80号端口，也可以是负责进行ftp数据通信的21号端口，还可以是负责进行邮件数据通信的25号端口。此外，所述网络通信端口还可以是实体的通信接口或者通信芯片。例如，其可以为无线移动网络通信芯片，如gsm、cdma等；其还可以为wifi芯片；其还可以为蓝牙芯片。
所述处理器210可以按任何适当的方式实现。例如，处理器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式等等。本申请并不作限定。
上述实施方式公开的资源处理服务器，其网络通信端口110和处理器210实现的具体功能，可以与本申请中订单处理方法实施方式相对照解释，可以实现本申请的订单处理方法实施方式并达到方法实施方式的技术效果。
本申请还提供一种计算机存储介质，其上存储有可被处理器执行的计算机程序，请参阅图4，所述计算机程序在被处理器执行时，可实现以下步骤：
s11：向业务服务器发出订单请求；所述订单请求中包括资源预订数量；所述资源预订数量用于所述业务服务器根据虚拟库存判断是否可以生成订单；
s21：接收所述业务服务器反馈的订单信息；所述订单信息表示所述虚拟库存满足所述资源预订数量；
s31：向客户端发送所述订单信息。
在本实施方式中，所述计算机存储介质可以是用于保存信息的记忆设备。在数字系统中，能保存二进制数据的设备可以是存储介质；在集成电路中，一个没有实物形式的具有存储功能的电路也可以为存储介质，如ram、fifo等；在系统中，具有实物形式的存储设备也可以叫存储介质，如内存条、tf卡等。
请参阅图6，本申请还提供一种交易系统，所述交易系统包括资源处理服务器、业务服务器、商家服务器，其中，所述业务服务器存储虚拟库存，所述商家服务器存储实际库存，所述虚拟库存的库存量根据商家服务器的实际库存的库存量进行更新。
在本实施方式中，所述资源处理服务器向所述业务服务器发出订单请求；所述订单请求中包括资源预订数量。
所述业务服务器接收订单请求，所述订单请求中包括资源预订数量；确认所述虚拟库存是否满足所述资源预订数量；在满足时，利用所述虚拟库存中的资源来处理所述订单请求，并向所述订单请求的发送方反馈成功信息；所述成功信息用于表示所述订单请求成功预定了所述资源预订数量个资源。
在本实施方式中，上述系统中的各个服务器实现的具体功能，请对应参照订单处理方法实施方式，这里便不再赘述。
本申请实施方式提供的一种订单处理方法、交易系统及服务器，通过在资源处理服务器和商家服务器之间增加业务服务器，并且将业务服务器和商家服务器中的库存量进行同步，从而能够直接通过业务服务器和资源处理服务器完成与用户的交易过程。业务服务器在处理订单请求时，可以避免与商家服务器进行查询的操作，从而能够保证商家服务器不会由于过多地接收到查询请求而导致的响应慢、负载高等问题，这样便可以提高资源销售效率，并且解决了“超卖”的问题。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmablelogicdevice,pld)(例如现场可编程门阵列(fieldprogrammablegatearray，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片2。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardwaredescriptionlanguage，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog2。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施方式或者实施方式的某些部分所述的方法。
本说明书中的各个实施方式均采用递进的方式描述，各个实施方式之间相同相似的部分互相参见即可，每个实施方式重点说明的都是与其他实施方式的不同之处。尤其，针对交易系统、业务服务器、资源处理服务器、计算机存储介质的实施方式来说，均可以参照前述方法的实施方式的介绍对照解释。
本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
虽然通过实施方式描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。