一种信息处理方法及服务器技术领域
本发明涉及互联网技术，尤其涉及一种信息处理方法及服务器。
背景技术
随着互联网技术的发展，智能终端的大量普及，信息的传输和交互越来越便捷。移
动互联网时代的传输和交互比传统的互联网时代更加方便。比如，用户现在可以用手机终
端缴水、电或煤气费、购买理财产品等，这在以往都是不可想象的，而现在可以通过移动互
联网，通过手机终端来实现以往不可想象的各种服务。移动互联网时代，信息的传输和交互
需要得到快速的处理及响应，但是，网络环境的不稳定性，信息传输在网络架构的复杂体系
中实现，有多重的处理节点和处理环节，从而，导致哪怕是在整个信息传输中出现一点异常
或问题，就会导致用户得不到信息的及时处理及响应，这些信息包括用户想要实现的上述
服务，从而，在信息传输中信息得不到及时处理和响应，用户就得到了处理失败的结果，这
种情况在需要高速响应的处理场景中，由于某一个处理节点或环境的异常所导致对请求无
法及时处理，最终所产生的处理失败结果更是尤为多见的。然而，相关技术中，对于该问题，
尚无有效解决方案。
发明内容
有鉴于此，本发明实施例提供了一种信息处理方法及服务器，至少解决了现有技
术存在的问题。
本发明实施例的技术方案是这样实现的：
本发明实施例的一种信息处理方法，所述方法包括：
收集信息传输过程中获取的历史数据，根据所述历史数据设置第一缓冲值；
当根据预设的策略判断出所述第一缓冲值的设置不合理时，对所述第一缓冲值进
行调整，得到第二缓冲值，根据所述第二缓冲值对终端发起的第一请求进行响应；
当根据所述预设的策略判断出需要启动排队时，生成排队标识；
将所述排队标识封装到所述终端需进入排队模式的处理结果中，反馈给终端；
收到终端响应所述排队模式生成的第二请求，对所述第二请求进行响应。
上述方案中，所述当根据预设的策略判断出所述第一缓冲值的设置不合理时，则
对所述第一缓冲值进行调整，得到第二缓冲值，包括：
根据所述预设的策略构建用于调整第一缓冲值的数学模型；
获取信息传输过程中新增的第一数据，将所述第一数据输入所述数学模型，将模
型输出的结果确定为所述第二缓冲值。
上述方案中，所述方法还包括：
当根据所述预设的策略判断出所述第一缓冲值的设置不合理时，反馈给终端告警
的处理结果。
上述方案中，所述根据预设的策略判断出所述第一缓冲值的设置不合理，包括：
若所述第一缓冲值>平均每笔交易金额×每秒并发量×百分比，判断出第一缓冲
值设置不合理；和/或，
若所述第一缓冲值/单笔申购上限<预设的配置值，判断出第一缓冲值设置不合
理。
上述方案中，根据所述预设的策略判断出需要启动排队，包括：
若申购接口统计当前并发量>上一个交易日的最大并发量×百分比，判断出需要
启动排队；和/或，
若当前交易日下单总笔数×上一个交易日的支付成功率×每笔交易金额>每日限
额×百分比，判断出需要启动排队。
上述方案中，所述收到终端响应所述排队模式生成的第二请求，对所述第二请求
进行响应，包括：
收到所述第二请求，所述第二请求是根据所述排队标识生成的预下单请求，所述
预下单请求中携带请求发起的时间信息；
根据所述请求发起的时间信息对所述预下单请求进行请求发起时间的排序，得到
排序结果；
对所述排序结果中第一优先级的预下单请求进行实时的请求响应，为终端反馈所
述预下单请求对应的目标数据；
对所述排序结果中第二优先级的预下单请求进行延时的请求响应，达到触发时间
后为终端反馈所述预下单请求对应的目标数据；
若检测到所述预下单请求对应的目标数据已经消耗完，对于当前未响应的预下单
请求，为终端反馈停止下单的消息提醒。
上述方案中，所述方法还包括：
获取至少一个查询操作；
检测所述至少一个查询操作并发处理时得到的并发性能参数；
当所述并发性能参数符合第一阈值时，采用加锁的查询方式对所述至少一个查询
操作进行业务响应；
当所述并发性能参数超出所述第一阈值时，采用不加锁的查询方式对所述至少一
个查询操作进行业务响应。
上述方案中，所述方法还包括：
实时对所述并发性能参数进行监控，得到监控结果；
根据所述监控结果在所述加锁的查询方式和所述不加锁的查询方式间做业务权
衡的响应。
本发明实施例的一种服务器，所述服务器包括：
第一处理单元，用于收集信息传输过程中获取的历史数据，根据所述历史数据设
置第一缓冲值；
第二处理单元，用于当根据预设的策略判断出所述第一缓冲值的设置不合理时，
对所述第一缓冲值进行调整，得到第二缓冲值，根据所述第二缓冲值对终端发起的第一请
求进行响应；
第三处理单元，用于：
当根据所述预设的策略判断出需要启动排队时，生成排队标识；
将所述排队标识封装到所述终端需进入排队模式的处理结果中，反馈给终端；
响应单元，用于收到终端响应所述排队模式生成的第二请求，对所述第二请求进
行响应。
上述方案中，所述第二处理单元，进一步用于：
根据所述预设的策略构建用于调整第一缓冲值的数学模型；
获取信息传输过程中新增的第一数据，将所述第一数据输入所述数学模型，将模
型输出的结果确定为所述第二缓冲值。
上述方案中，所述第二处理单元，进一步用于：
当根据所述预设的策略判断出所述第一缓冲值的设置不合理时，反馈给终端告警
的处理结果。
上述方案中，所述第二处理单元，进一步用于：
若所述第一缓冲值>平均每笔交易金额×每秒并发量×百分比，判断出第一缓冲
值设置不合理；和/或，
若所述第一缓冲值/单笔申购上限<预设的配置值，判断出第一缓冲值设置不合
理。
上述方案中，所述第三处理单元，进一步用于：
若申购接口统计当前并发量>上一个交易日的最大并发量×百分比，判断出需要
启动排队；和/或，
若当前交易日下单总笔数×上一个交易日的支付成功率×每笔交易金额>每日限
额×百分比，判断出需要启动排队。
上述方案中，所述响应单元，进一步用于：
收到所述第二请求，所述第二请求是根据所述排队标识生成的预下单请求，所述
预下单请求中携带请求发起的时间信息；
根据所述请求发起的时间信息对所述预下单请求进行请求发起时间的排序，得到
排序结果；
对所述排序结果中第一优先级的预下单请求进行实时的请求响应，为终端反馈所
述预下单请求对应的目标数据；
对所述排序结果中第二优先级的预下单请求进行延时的请求响应，达到触发时间
后为终端反馈所述预下单请求对应的目标数据；
若检测到所述预下单请求对应的目标数据已经消耗完，对于当前未响应的预下单
请求，为终端反馈停止下单的消息提醒。
上述方案中，所述服务器还包括：
操作获取单元，用于获取至少一个查询操作；
检测单元，用于检测所述至少一个查询操作并发处理时得到的并发性能参数；
业务响应单元，用于：
当所述并发性能参数符合第一阈值时，采用加锁的查询方式对所述至少一个查询
操作进行业务响应；
当所述并发性能参数超出所述第一阈值时，采用不加锁的查询方式对所述至少一
个查询操作进行业务响应。
上述方案中，所述服务器还包括：
监控单元，用于实时对所述并发性能参数进行监控，得到监控结果；
所述业务响应单元，进一步用于根据所述监控结果在所述加锁的查询方式和所述
不加锁的查询方式间做业务权衡的响应。
本发明实施例的信息处理方法包括：收集信息传输过程中获取的历史数据，根据
所述历史数据设置第一缓冲值；当根据预设的策略判断出所述第一缓冲值的设置不合理
时，对所述第一缓冲值进行调整，得到第二缓冲值，根据所述第二缓冲值对终端发起的第一
请求进行响应；当根据所述预设的策略判断出需要启动排队时，生成排队标识；将所述排队
标识封装到所述终端需进入排队模式的处理结果中，反馈给终端；收到终端响应所述排队
模式生成的第二请求，对所述第二请求进行响应。
采用本发明实施例，在通过缓冲值及对其调整后的值，对终端发起的第一请求进
行响应时，通过缓冲处理，可以有序的对请求进行响应，哪怕是因为一点异常导致不能及时
响应，也不会带给用户处理失败或无法处理的结果。如果判断出需要启动排队，在排队模式
下收到终端响应所述排队模式生成的第二请求，通过排队处理，也可以有序的对请求进行
响应，从而使得在信息传输中的信息能得到处理和响应，尤其适应于需要高速响应的处理
场景，不会带给用户过多的处理失败或无法处理的结果。
附图说明
图1为本发明实施例中进行信息交互的各方硬件实体的示意图；
图2为本发明实施例一信息处理的示意图；
图3为本发明实施例又一信息处理的示意图；
图4为本发明实施例再一信息处理的示意图；
图5为本发明实施例一系统架构示意图；
图6为应用本发明实施例一应用场景的实现流程示意图。
具体实施方式
下面结合附图对技术方案的实施作进一步的详细描述。
现在将参考附图描述实现本发明各个实施例的移动终端。在后续的描述中，使用
用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明实施例的说明，
其本身并没有特定的意义。因此，"模块"与"部件"可以混合地使用。
在下面的详细说明中，陈述了众多的具体细节，以便彻底理解本发明。不过，对于
本领域的普通技术人员来说，显然可在没有这些具体细节的情况下实践本发明。在其他情
况下，没有详细说明公开的公知方法、过程、组件、电路和网络，以避免不必要地使实施例的
各个方面模糊不清。
另外，本文中尽管多次采用术语“第一”、“第二”等来描述各种元件(或各种阈值或
各种应用或各种指令或各种操作)等，不过这些元件(或阈值或应用或指令或操作)不应受
这些术语的限制。这些术语只是用于区分一个元件(或阈值或应用或指令或操作)和另一个
元件(或阈值或应用或指令或操作)。例如，第一操作可以被称为第二操作，第二操作也可以
被称为第一操作，而不脱离本发明的范围，第一操作和第二操作都是操作，只是二者并不是
相同的操作而已。
本发明实施例中的步骤并不一定是按照所描述的步骤顺序进行处理，可以按照需
求有选择的将步骤打乱重排，或者删除实施例中的步骤，或者增加实施例中的步骤，本发明
实施例中的步骤描述只是可选的顺序组合，并不代表本发明实施例的所有步骤顺序组合，
实施例中的步骤顺序不能认为是对本发明的限制。
本发明实施例中的术语“和/或”指的是包括相关联的列举项目中的一个或多个的
任何和全部的可能组合。还要说明的是：当用在本说明书中时，“包括/包含”指定所陈述的
特征、整数、步骤、操作、元件和/或组件的存在，但是不排除一个或多个其他特征、整数、步
骤、操作、元件和/或组件和/或它们的组群的存在或添加。
本发明实施例的智能终端(如移动终端)可以以各种形式来实施。例如，本发明实
施例中描述的移动终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、
个人数字助理(PDA，Personal Digital Assistant)、平板电脑(PAD)、便携式多媒体播放器
(PMP，Portable Media Player)、导航装置等等的移动终端以及诸如数字TV、台式计算机等
等的固定终端。下面，假设终端是移动终端。然而，本领域技术人员将理解的是，除了特别用
于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。
图1为本发明实施例中进行信息交互的各方硬件实体的示意图，图1中包括：终端
设备1，服务器21、服务器31、服务器41。其中，终端设备1由终端设备11-14构成，终端设备通
过有线网络或者无线网络与服务器进行信息交互。终端设备包括手机、台式机、PC机、一体
机等类型。采用本发明实施例，终端设备1经由服务器21和服务器31与服务器41进行信息传
输和交互，具体的，以购买理财产品的信息传输过程为例，终端设备11-14在从服务器41拉
取理财产品相关第一数据后，在本端生成的理财产品及其支付页面。其中，服务器21为支付
平台，服务器31为接入理财产品的中转平台，服务器41为理财产品所在的平台。在本端生成
理财产品及其支付页面后，用户选择想要购买的理财产品并进行支付，将选购理财产品和
支付操作所形成的相关第二数据，经由服务器21-服务器31反馈给服务器41进行处理，服务
器41将处理结果经由服务器21-服务器31反馈给终端。需要指出的是，从终端设备侧经由服
务器21-服务器31反馈给服务器41构成本发明实施例的一种信息传输的传输通道。还可以
包括其他传输通道，比如，用户选择想要购买的理财产品并进行预下单，以便在下单成功后
拉起支付框，用户输入密码进行支付，将选购理财产品和预下单操作所形成的相关第二数
据反馈给服务器21，服务器21向服务器31反馈该预下单操作所请求购买的理财产品，理财
产品的相关信息通过服务器31从服务器41中拉取，在服务器31中判决是否要对该预下单操
作的请求进行响应，如果当前还有可以购买的理财产品(并未达到能申购的理财产品的上
限)可以予以响应(如分为：按照缓冲值实时的响应和按照排队模式进行延时响应的不同策
略进行响应)，则反馈给终端，进行真实的下单和实际支付的提醒，终端设备响应该提醒，对
理财产品进行实际支付后，在服务器21中进行支付是否成功的确认，如果支付成功，则服务
器21向服务器31反馈已经支付理财产品成功的消息。如果当前没有可以购买的理财产品
(已经达到能申购的理财产品的上限)可以予以响应，则反馈给终端不予申购的提醒，终端
设备响应该提醒，不会对理财产品进行实际支付，通过上述一系列的处理，既可以实现对用
户的预下单操作的请求进行响应，而且也不会产生过多的退款，保证了整个信息传输流程
的服务稳定性。以服务器31为针对用户预下单操作的请求进行响应的执行实体而言，其处
理逻辑10如图1所示，处理逻辑10包括：S1、收集信息传输过程中获取的历史数据，历史数据
为信息传输过程中可以收集到的所有数据，比如，可以包括：1)上述终端设备11-14从服务
器41拉取理财产品相关第一数据，及2)用户选购理财产品和预下单操作所形成的相关第二
数据，将其反馈给服务器侧。S2、根据所述历史数据设置第一缓冲值。S3、当根据预设的策略
判断出所述第一缓冲值的设置不合理时，对所述第一缓冲值进行调整，得到第二缓冲值。
S4、根据所述第二缓冲值对终端发起的第一请求进行响应。S5、当根据所述预设的策略判断
出需要启动排队时，反馈给终端需进入排队模式的处理结果，具体的，当根据所述预设的策
略判断出需要启动排队时，生成排队标识；将所述排队标识封装到所述终端需进入排队模
式的处理结果中，反馈给终端。S6、收到终端响应所述排队模式生成的第二请求，对所述第
二请求进行响应。
对于在信息传输中，信息得不到及时处理和响应中用户会得到处理失败的结果，
这种情况在需要高速响应的处理场景中，由于某一个处理节点或环境的异常所导致对请求
无法及时处理，最终所产生的处理失败结果更是尤为多见的，具体来说，除了网络本身的问
题导致的异常，还包括其他异常的可能性。异常不一定都是网络问题导致，网络延迟毕竟是
少数，一个实际应用中，大部分的异常是因为操作的不连贯(需要多步操作)导致用户在中
途取消了操作、或支付失败，比如下单后未支付的所导致的异常，支付成功后又导致退款而
有损用户体验也是一种异常，这些都是处理失败结果。采用上述系统架构，可以针对这些问
题进行解决，以避免产生上述处理失败的结果。
上述图1的例子只是实现本发明实施例的一个系统架构实例，本发明实施例并不
限于上述图1所述的系统结构，基于上述图1所述的系统架构，提出本发明方法各个实施例。
本发明实施例的一种信息处理方法，如图2所示，包括终端设备51、服务器52、服务
器53、服务器54和服务器55。其中，服务器52将从终端设备51收集的历史数据发送给服务器
53，服务器53从服务器54-55多个不同的数据源来获取终端设备所请求的目标数据。服务器
52、服务器53、服务器54和服务器55如图2所示，可以采用服务器集群系统，在本实施例中仅
以2个服务器的形式进行示意。服务器53作为本发明实施例中的处理服务器，根据其处理逻
辑20，对历史数据进行分析，对终端设备的请求按照缓冲值和排队机制进行不同的响应处
理。具体的，服务器收集信息传输过程中获取的历史数据，信息传输过程包括：发起请求和
对请求进行响应处理中所涉及的各个处理节点和处理环节，比如，历史数据可以包括：不同
基金的支付成功率、并发量、每笔交易金额以及退款量，根据所述历史数据设置第一缓冲值
(101)，第一缓冲值为初始缓冲值，如果数据发生变化，缓冲值的设置不合理，导致退款量或
少卖量并没有明显缓解，比如，仍然有部分退款，这时才需要对缓冲值进行调整，使基于缓
冲值进行请求处理响应总能处于合理的状态，对第一缓冲值进行调整得到的调整值以第二
缓冲值表示。当服务器根据预设的策略(如判断何时需要调整缓冲值和/或何时需要启动排
队机制的策略)判断出所述第一缓冲值的设置不合理时，如通过上述统计历史的数据的更
新或新增数据作为以后缓冲值调整的参考，统计的区间是一个交易日，日切模式不同的基
金会有所差别。根据这些历史数据更新或新增数据，可以生成一些规则。具体的，规则1：缓
冲值>平均每笔交易金额×每秒并发量×百分比，说明缓冲值设置不合理，需要对所述第一
缓冲值进行调整，得到第二缓冲值，除了根据所述第二缓冲值对终端发起的第一请求进行
响应(102)之外，还可以给终端设备反馈第一次提醒，即告警介入，提醒终端设置请求需求
需要放缓，这里的终端设备可以为开发人员侧的终端设备，以便开发人员收到该告警介入
后，及时发现告警设置的不合理，从而开发人员可以对告警设置介入调整。规则2：缓冲值/
单笔申购上限<一个配置的值(该配置的值可以是每秒真实并发量，即支付成功量，该配置
的值是初始值，后续可以根据真实值进行调整)，说明缓冲值设置不合理，需要对所述第一
缓冲值进行调整，得到第二缓冲值，除了根据所述第二缓冲值对终端发起的第一请求进行
响应(102)之外，还可以给终端设备反馈第一次提醒，即告警介入，提醒终端设置请求需求
需要放缓，这里的终端设备可以为开发人员侧的终端设备，以便开发人员收到该告警介入
后，及时发现告警设置的不合理，从而开发人员可以对告警设置介入调整。当根据所述预设
的策略判断出需要启动排队时，反馈给终端需进入排队模式的处理结果(103)。具体的，当
根据所述预设的策略判断出需要启动排队时，生成排队标识；将所述排队标识封装到所述
终端需进入排队模式的处理结果中，反馈给终端。收到终端响应所述排队模式生成的第二
请求，该第二请求是一个预下单请求，预下单请求进行排队模式后，服务器可以将处理响应
速度调慢，以便于能对所述第二请求进行响应(104)。
采用本发明实施例，以目标数据为理财产品为例，服务器52向服务器54和服务器
55分别反馈该预下单操作所请求购买的理财产品，理财产品的相关信息通过服务器52从服
务器54和服务器55中分别拉取，在服务器52中判决是否要对该预下单操作的请求进行响
应，如果当前还有可以购买的理财产品(并未达到能申购的理财产品的上限)可以予以响应
(如分为：按照缓冲值实时的响应和按照排队模式进行延时响应的不同策略进行响应)，则
反馈给终端，进行真实的下单和实际支付的提醒，终端设备响应该提醒，对理财产品进行实
际支付后，在服务器52中进行支付是否成功的确认，如果支付成功，则服务器52向服务器53
反馈已经支付理财产品成功的消息。如果当前没有可以购买的理财产品(已经达到能申购
的理财产品的上限)可以予以响应，则反馈给终端不予申购的提醒，终端设备响应该提醒，
不会对理财产品进行实际支付，通过上述一系列的处理，既可以实现对用户的预下单操作
的请求进行响应，而且也不会产生过多的退款，保证了整个信息传输流程的服务稳定性。
本发明实施例的一种信息处理方法，如图3所示，包括终端设备61、服务器62、服务
器63、服务器64和服务器65。其中，服务器62将从终端设备61收集的历史数据发送给服务器
63，服务器63从服务器64-65多个不同的数据源来获取终端设备所请求的目标数据。服务器
62、服务器63、服务器64和服务器65如图3所示，可以采用服务器集群系统，在本实施例中仅
以2个服务器的形式进行示意。服务器63作为本发明实施例中的处理服务器，根据其处理逻
辑30，对历史数据进行分析，对终端设备的请求按照缓冲值和排队机制进行不同的响应处
理。具体的，服务器收集信息传输过程中获取的历史数据，信息传输过程包括：发起请求和
对请求进行响应处理中所涉及的各个处理节点和处理环节，比如，历史数据可以包括：不同
基金的支付成功率、并发量、每笔交易金额以及退款量，根据所述历史数据设置第一缓冲值
(201)，第一缓冲值为初始缓冲值，如果数据发生变化，缓冲值的设置不合理，导致退款量或
少卖量并没有明显缓解，比如，仍然有部分退款，这时才需要对缓冲值进行调整，使基于缓
冲值进行请求处理响应总能处于合理的状态，对第一缓冲值进行调整得到的调整值以第二
缓冲值表示。当服务器根据预设的策略(如判断何时需要调整缓冲值和/或何时需要启动排
队机制的策略)判断出所述第一缓冲值的设置不合理时，如通过上述统计历史的数据的更
新或新增数据作为以后缓冲值调整的参考，统计的区间是一个交易日，日切模式不同的基
金会有所差别。根据这些历史数据更新或新增数据，可以生成一些规则。具体的，规则1：缓
冲值>平均每笔交易金额×每秒并发量×百分比，说明缓冲值设置不合理，需要对所述第一
缓冲值进行调整；规则2：缓冲值/单笔申购上限<一个配置的值(该配置的值可以是每秒真
实并发量，即支付成功量，该配置的值是初始值，后续可以根据真实值进行调整)，说明缓冲
值设置不合理，需要对所述第一缓冲值进行调整，通过调整得到第二缓冲值。对所述第一缓
冲值进行调整的过程中，首先，根据所述预设的策略构建用于调整第一缓冲值的数学模型
(202)，可以利用机器学习算法来构建该数学模型，机器学习算法的原理是：根据输入的初
始数值来生成初始数学模型，实时获取输入数值的变化，对数学模型进行更新，还可以将数
学模型的输出结果作为数学模型的输入数值使用，在流程结束之前将输入数据和输出数据
在该数学模型中循环往复，对该数学模型进行优化和改良，从而让该数学模型始终处于最
合理的状态，将该数学模型当前的输出结果确定为所需调整值的最新值，在本发明实施例
中，所需调整值的最新值指对第一缓冲值调整后得到的第二缓冲值。其次，获取信息传输过
程中新增的第一数据，将所述第一数据输入所述数学模型，将模型输出的结果确定为所述
第二缓冲值(203)。根据第二缓冲值对终端发起的第一请求进行响应(204)。除了根据所述
第二缓冲值对终端发起的第一请求进行响应外，还可以给终端设备反馈第一次提醒，即告
警介入，提醒终端设置请求需求需要放缓，这里的终端设备可以为开发人员侧的终端设备，
以便开发人员收到该告警介入后，及时发现告警设置的不合理，从而开发人员可以对告警
设置介入调整。当根据所述预设的策略判断出需要启动排队时，反馈给终端需进入排队模
式的处理结果(205)。具体的，当根据所述预设的策略判断出需要启动排队时，生成排队标
识；将所述排队标识封装到所述终端需进入排队模式的处理结果中，反馈给终端。收到终端
响应所述排队模式生成的第二请求，该第二请求是一个预下单请求，预下单请求进行排队
模式后，服务器可以将处理响应速度调慢，以便于能对所述第二请求进行响应(206)。
采用本发明实施例，由于目前缓冲值的设置随意性太大，且设置好的缓冲值是固
定不变的，当实际情况发生变化后，按照该固定不变的缓冲值进行调整，就会非常不合理。
而本发明实施例是通过数据统计的方法对缓冲值给一个合理的建议值。可以通过统计历史
的数据作为以后缓冲值设置的参考，这些历史数据包括不同基金的支付成功率、并发量、每
笔交易金额以及退款量。统计的区间是一个交易日，日切模式不同的基金会有所差别。根据
这些数据可以给出上述规则1-2，根据规则1-2来判断缓冲值的设置是否合理，如果不合理，
则对缓冲值进行实时的动态调整。
本发明实施例中，除了缓冲值的设置，还增加了消息提醒，即：告警介入的提醒。前
端只有发起预下单操作和显示消息提醒的功能，后台服务器来进行各种策略配置，并根据
该策略配置对前端发起的多次请求进行响应。其中，以缓冲值对请求进行的响应流程，与以
排队机制对请求进行的响应流程二者有所区别。缓冲值本身就是延缓，以便能对所有的请
求进行响应，不错过每一个请求，而排队机制需要根据增加的排队标识，按照请求的时间顺
序进行速度放缓的调节后，才能对所有的请求进行响应，也不会错过每一个请求。
本发明实施例根据策略来配置合理的缓冲值，并可以进行调整，据调整后的缓冲
值进行响应，避免了由于缓冲值的设置不合理而反馈失败的处理结果，因为，在原有处理策
略中，在支付之前无法判断是否能成功，如果让用户发起支付，支付后才发现不能做成功，
则得到失败的处理结果。如果启动了排队模式，则通过排队来进行响应，避免了由于处理不
及时就返回失败处理结果，终端响应由服务器发起的排队机制。服务器对用户的请求，具体
为针对预下单请求进行响应时，预下单请求不是真实付费那种真正意义的下单，对于目标
数据为理财产品而言，不会产生过多的退款处理，退款处理反馈给终端，其实就是服务器反
馈给终端一种处理失败的结果。
本发明实施例的一种信息处理方法，如图4所示，包括终端设备71、服务器72、服务
器73、服务器74和服务器75。其中，服务器72将从终端设备71收集的历史数据发送给服务器
73，服务器73从服务器74-75多个不同的数据源来获取终端设备所请求的目标数据。服务器
72、服务器73、服务器74和服务器75如图4所示，可以采用服务器集群系统，在本实施例中仅
以2个服务器的形式进行示意。服务器73作为本发明实施例中的处理服务器，根据其处理逻
辑40，对历史数据进行分析，对终端设备的请求按照缓冲值和排队机制进行不同的响应处
理。具体的，服务器收集信息传输过程中获取的历史数据，信息传输过程包括：发起请求和
对请求进行响应处理中所涉及的各个处理节点和处理环节，比如，历史数据可以包括：不同
基金的支付成功率、并发量、每笔交易金额以及退款量，根据所述历史数据设置第一缓冲值
(301)，第一缓冲值为初始缓冲值，如果数据发生变化，缓冲值的设置不合理，导致退款量或
少卖量并没有明显缓解，比如，仍然有部分退款，这时才需要对缓冲值进行调整，使基于缓
冲值进行请求处理响应总能处于合理的状态，对第一缓冲值进行调整得到的调整值以第二
缓冲值表示。当服务器根据预设的策略(如判断何时需要调整缓冲值和/或何时需要启动排
队机制的策略)判断出所述第一缓冲值的设置不合理时，如通过上述统计历史的数据的更
新或新增数据作为以后缓冲值调整的参考，统计的区间是一个交易日，日切模式不同的基
金会有所差别。根据这些历史数据更新或新增数据，可以生成一些规则。具体的，规则1：缓
冲值>平均每笔交易金额×每秒并发量×百分比，说明缓冲值设置不合理，需要对所述第一
缓冲值进行调整；规则2：缓冲值/单笔申购上限<一个配置的值(该配置的值可以是每秒真
实并发量，即支付成功量，该配置的值是初始值，后续可以根据真实值进行调整)，说明缓冲
值设置不合理，需要对所述第一缓冲值进行调整，通过调整得到第二缓冲值。对所述第一缓
冲值进行调整的过程中，首先，根据所述预设的策略构建用于调整第一缓冲值的数学模型
(302)，可以利用机器学习算法来构建该数学模型，机器学习算法的原理是：根据输入的初
始数值来生成初始数学模型，实时获取输入数值的变化，对数学模型进行更新，还可以将数
学模型的输出结果作为数学模型的输入数值使用，在流程结束之前将输入数据和输出数据
在该数学模型中循环往复，对该数学模型进行优化和改良，从而让该数学模型始终处于最
合理的状态，将该数学模型当前的输出结果确定为所需调整值的最新值，在本发明实施例
中，所需调整值的最新值指对第一缓冲值调整后得到的第二缓冲值。其次，获取信息传输过
程中新增的第一数据，将所述第一数据输入所述数学模型，将模型输出的结果确定为所述
第二缓冲值(303)。根据第二缓冲值对终端发起的第一请求进行响应(304)。除了根据所述
第二缓冲值对终端发起的第一请求进行响应外，还可以给终端设备反馈第一次提醒，即告
警介入，提醒终端设置请求需求需要放缓，这里的终端设备可以为开发人员侧的终端设备，
以便开发人员收到该告警介入后，及时发现告警设置的不合理，从而开发人员可以对告警
设置介入调整。当根据所述预设的策略判断出需要启动排队时生成排队标识(305)。对于启
动排队的策略而言，排队与缓冲值的设置也有关系，如果缓冲值的设置不合理，比如，缓冲
值设置过小，则排队机制启动慢，因为没有足够的时间去响应，从而也会影响到整个信息传
输过程的服务稳定性，通过上述实施例中统计历史的数据的更新或新增数据作为以后缓冲
值调整的参考，统计的区间是一个交易日，日切模式不同的基金会有所差别。根据这些历史
数据更新或新增数据，可以生成一些规则。有别于上述规则1-2，在启动排队机制中，具体
的，规则3：申购接口统计当前并发量>上一个交易日的最大并发量×百分比，启动排队机
制；规则4：当前交易日下单总笔数×上一个交易日的支付成功率×每笔交易金额>每日限
额×百分比，启动排队机制。启动排队后，服务器将所述排队标识封装到所述终端需进入排
队模式的处理结果中，反馈给终端(306)，收到终端响应所述排队模式生成的第二请求，对
所述第二请求进行响应(307)。对所述第二请求进行响应的过程中，服务器收到所述第二请
求(如预下单请求)，所述第二请求是根据所述排队标识生成的预下单请求，所述预下单请
求中携带请求发起的时间信息，根据所述请求发起的时间信息对所述预下单请求进行请求
发起时间的排序，得到排序结果。
在本发明实施例中，按照排队标识使得终端的第二请求按照发起请求的先后时间
顺序进入排队模式后，在排序结果存在不同的优先级。当然，在实际应用中，也可以不区分
第一优先级和第二优先级，只要发起排队模式，就都是延迟响应，对于发起排队模式之前的
请求，走正常的下单流程；对于发起排队模式之后的请求，走预下单-下单的流程。就优先级
而言，1)对所述排序结果中第一优先级的预下单请求进行实时的请求响应，为终端反馈所
述预下单请求对应的目标数据；2)对所述排序结果中第二优先级的预下单请求进行延时的
请求响应，达到触发时间后为终端反馈所述预下单请求对应的目标数据，如根据用户发起
的时间先后顺序排序后用一定的速度调整接口下单；3)若检测到所述预下单请求对应的目
标数据已经消耗完，对于当前未响应的预下单请求，为终端反馈停止下单的消息提醒。就本
发明实施例的排队机制而言，当启动排队机制的时候，后台服务器先打一个标记并传给前
端，前端拿到标记后在用户下单时给用户二次确认的提示，此时可以是发给下单的普通用
户侧的终端设备，第一次的提醒是根据缓冲值发起的告警介入，此时可以是发给开发人员
侧的终端设备。针对该二次确认的提醒，用户点击确认后发起预下单。捞取预下单数据，根
据用户发起的时间先后顺序排序后用一定的速度调实时接口下单。
以目标数据为理财产品为例，还可以在请求发起之前判断理财产品是否已经售
罄，如果理财产品已经售罄的，捞取还未处理的预下单数据，给用户发消息提醒。其中，如果
启动排队机制，生成排队标识，排队标识发给前端，走排队流程对请求进行响应，与之前通
过缓冲值对请求进行响应有所区别，启动排队流程后，多个请求(如第二请求)并发时，请求
先发起的，服务器允许先购买理财产品；请求后发起的，如果还有理财产品，则将反馈速度
调慢，也就是说，先发起的，先下单，只要发起排队模式，就都会调慢下单速度，调慢速度的
原因是能更精准实时的获取到产品售罄的信号；如果发现没有可以购买的理财产品，则发
出提醒给前端，停止申购理财产品。通过上述一系列的处理，既可以实现对用户的预下单操
作的请求进行响应，而且也不会产生过多的退款，保证了整个信息传输流程的服务稳定性。
本发明实施例中，除了缓冲值的设置，还增加了排队机制和二次消息提醒，即：第
一次的告警介入提醒和第二次的排队提醒。前端只有发起预下单操作和显示消息提醒的功
能，后台服务器来进行各种策略配置，并根据该策略配置对前端发起的多次请求进行响应。
其中，以缓冲值对请求进行的响应流程，与以排队机制对请求进行的响应流程二者有所区
别。缓冲值本身就是延缓，以便能对所有的请求进行响应，不错过每一个请求，而排队机制
需要根据增加的排队标识，按照请求的时间顺序进行速度放缓的调节后，才能对所有的请
求进行响应，也不会错过每一个请求。
本发明实施例根据策略来配置合理的缓冲值，并可以进行调整，据调整后的缓冲
值进行响应，避免了由于缓冲值的设置不合理，直接对请求不响应而反馈失败的处理结果，
因为，在原有处理策略中，在支付之前无法判断是否能成功，如果让用户发起支付，支付后
才发现不能做成功，则得到失败的处理结果。如果启动了排队模式，则通过排队来进行响
应，避免了由于处理不及时就返回失败处理结果，终端响应由服务器发起的排队机制。服务
器对用户的请求，具体为针对预下单请求进行响应时，预下单请求不是真实付费那种真正
意义的下单，对于目标数据为理财产品而言，不会产生过多的退款处理，退款处理反馈给终
端，其实就是服务器反馈给终端一种处理失败的结果。
本发明实施例中，就上述规则1-4中的百分比设置而言，百分比的值是一个经验
值，需要根据线上数据调整，直到达到一个最优值。以理财产品为基金为例进行说明，当基
金收益率有明显波动的时候，这个值也需要做相应调整，必要的时候可以引入机器学习的
算法进行训练。系统初始化的时候，规则1和规则2百分比的值和配置的值(该配置的值可以
是每秒真实并发量，即支付成功量，该配置的值是初始值，后续可以根据真实值进行调整)
设置为通过前一个交易日的数据算出来的值，规则2设置的初始值建议不要小于每秒并发
量，规则3的百分比可以初始化为120％，规则4的百分比可以初始化为80％。随着系统的运
行，这些值再慢慢调整。比如说初始值设置的不合理导致排队过晚启动，可以调整规则3和
规则4的百分比。如果缓冲值设置不合理导致有退款但未告警，则调整规则1或规则2的设
置。规则1缓冲值设置过大会导致有部分资产没有卖完，规则2配置的值过小会导致缓冲值
设置过小导致退款，规则3的百分比设置过大会导致启动排队机制较晚，依然会引起少量退
款，规则4的百分比设置过大效果同规则3。如果交易日之间收益率有较大波动，如收益率变
小，则可以通过调整参数调小缓冲值的大小或稍晚启动排队。
信息交互因为各种传输操作中的异常导致：请求了之后，得到失败的处理结果。而
对于需要高速响应的基金抢购类应用场景中，需要的就是在最短时间内能精准的得到成功
的处理结果，而不是因为延迟处理，发现达到处理上限而导致不能及时处理，所产生的失败
的处理结果。比如，用户在理财通系统购买基金的流程是先下单，再输入密码支付。由于从
用户下单，拉起支付框支付，到支付中心通知理财通支付成功，这整个信息传输过程中包括
多个处理节点和处理环节。整个动作并不连贯，并且由于各种异常情况的存在，例如支付成
功通知延迟或者用户中途放弃，支付成功率并不是100％，也可能导致支付成功金额没有及
时累加，由于支付成功率的存在，如果支付前(下单)判断总金额会导致不准，如果支付后再
累加总金额可能因为延迟(整个操作完成至少需要几秒钟)，从而导致没有及时累加总金额
的问题。对于抢购类产品，由于收益率较高，会出现当天的额度在几分钟之内卖完的情况，
并发量很高。如果用户下单成功，但支付成功后发现已经超限则会退款。如何保证用户的购
买成功金额尽最大可能接近于当日的购买上限，并将退款的可能性降到最低，成为一个急
需解决的问题。对于这个问题，目前的处理，是设置一个固定的缓冲值进行数据缓存，但是
缓冲值的设置随意性太大，导致缓冲值不合理，本发明实施例中，是通过数据统计的方法对
缓冲值给一个合理的建议值，除了数据统计，还增加了排队和消息提醒机制，从而将退款的
可能性降到最低。根据下单量、并发量、支付成功率等数据进行数据统计，根据数据统计结
果增加了排队和消息提醒机制，从而在无法及时处理请求或者停止申购时在用户页面上发
起排队并给出消息提示。
基于上述各个实施例的信息处理方法，所述方法还包括：获取至少一个查询操作，
检测所述至少一个查询操作并发处理时得到的并发性能参数。如果所述并发性能参数符合
第一阈值，说明并发性能没有大幅下降，则采用加锁的查询方式对所述至少一个查询操作
进行业务响应；如果所述并发性能参数超出所述第一阈值，说明并发性能大幅下降，则采用
不加锁的查询方式对所述至少一个查询操作进行业务响应。
之后，实时对所述并发性能参数进行监控，得到监控结果，根据所述监控结果在所
述加锁的查询方式和所述不加锁的查询方式间做业务权衡的响应。
这里需要指出的是：以下涉及由终端和服务器构成的系统架构描述中，同上述方
法描述类似的细节和有益效果描述，不做赘述。对于本发明系统架构描述中未披露的技术
细节，请参照上述实施例所描述的内容。
本发明实施例的一种信息处理系统，如图5所示，包括：终端81、服务器82、服务器
83；其中，终端81作为请求发起方，服务器83作为请求所针对目标数据的数据源提供方，服
务器82作为接收请求后，根据所请求的目标数据，对请求进行处理的请求响应方。服务器82
包括：第一处理单元821，用于收集信息传输过程中获取的历史数据，根据所述历史数据设
置第一缓冲值；第二处理单元822，用于当根据预设的策略判断出所述第一缓冲值的设置不
合理时，对所述第一缓冲值进行调整，得到第二缓冲值，根据所述第二缓冲值对终端发起的
第一请求进行响应；第三处理单元823，用于当根据所述预设的策略判断出需要启动排队
时，反馈给终端需进入排队模式的处理结果，具体的，当根据所述预设的策略判断出需要启
动排队时，生成排队标识；将所述排队标识封装到所述终端需进入排队模式的处理结果中，
反馈给终端；响应单元824，用于收到终端响应所述排队模式生成的第二请求，对所述第二
请求进行响应。
本发明实施例一实施方式中，所述历史数据的类型包括：不同基金的支付成功率、
并发量、每笔交易金额和退款量中的至少一种。
本发明实施例一实施方式中，所述第二处理单元，进一步用于：根据所述预设的策
略构建用于调整第一缓冲值的数学模型；获取信息传输过程中新增的第一数据，将所述第
一数据输入所述数学模型，将模型输出的结果确定为所述第二缓冲值。
本发明实施例一实施方式中，所述第二处理单元，进一步用于：当根据所述预设的
策略判断出所述第一缓冲值的设置不合理时，反馈给终端告警的处理结果。
本发明实施例一实施方式中，所述第二处理单元，进一步用于：若所述第一缓冲值
>平均每笔交易金额×每秒并发量×百分比，判断出第一缓冲值设置不合理；和/或，若所述
第一缓冲值/单笔申购上限<预设的配置值，判断出第一缓冲值设置不合理。
本发明实施例一实施方式中，所述第三处理单元，进一步用于：当根据所述预设的
策略判断出需要启动排队时，生成排队标识；将所述排队标识封装到所述终端需进入排队
模式的处理结果中，反馈给终端。
本发明实施例一实施方式中，所述第三处理单元，进一步用于：若申购接口统计当
前并发量>上一个交易日的最大并发量×百分比，判断出需要启动排队；和/或，若当前交易
日下单总笔数×上一个交易日的支付成功率×每笔交易金额>每日限额×百分比，判断出
需要启动排队。
本发明实施例一实施方式中，所述响应单元，进一步用于：收到所述第二请求，所
述第二请求是根据所述排队标识生成的预下单请求，所述预下单请求中携带请求发起的时
间信息；根据所述请求发起的时间信息对所述预下单请求进行请求发起时间的排序，得到
排序结果。在排序结果存在不同的优先级。当然，在实际应用中，也可以不区分第一优先级
和第二优先级，只要发起排队模式，就都是延迟响应，对于发起排队模式之前的请求，走正
常的下单流程；对于发起排队模式之后的请求，走预下单-下单的流程。就优先级而言，对所
述排序结果中第一优先级的预下单请求进行实时的请求响应，为终端反馈所述预下单请求
对应的目标数据；对所述排序结果中第二优先级的预下单请求进行延时的请求响应，达到
触发时间后为终端反馈所述预下单请求对应的目标数据；若检测到所述预下单请求对应的
目标数据已经消耗完，对于当前未响应的预下单请求，为终端反馈停止下单的消息提醒。
本发明实施例一实施方式中，所述服务器还包括：操作获取单元，用于获取至少一
个查询操作。检测单元，用于检测所述至少一个查询操作并发处理时得到的并发性能参数。
业务响应单元，用于：当所述并发性能参数符合第一阈值时，采用加锁的查询方式对所述至
少一个查询操作进行业务响应；当所述并发性能参数超出所述第一阈值时，采用不加锁的
查询方式对所述至少一个查询操作进行业务响应。
本发明实施例一实施方式中，所述服务器还包括：监控单元，用于实时对所述并发
性能参数进行监控，得到监控结果。所述业务响应单元，进一步用于根据所述监控结果在所
述加锁的查询方式和所述不加锁的查询方式间做业务权衡的响应。
其中，对于用于数据处理的处理器而言，在执行处理时，可以采用微处理器、中央
处理器(CPU，Central Processing Unit)、数字信号处理器(DSP，Digital Singnal
Processor)或可编程逻辑阵列(FPGA，Field－Programmable Gate Array)实现；对于存储
介质来说，包含操作指令，该操作指令可以为计算机可执行代码，通过所述操作指令来实现
上述本发明实施例信息处理方法流程中的各个步骤。
以一个现实应用场景为例对本发明实施例阐述如下：
以信息传输中目标数据为理财产品的场景为例，用户在理财通系统购买基金的流
程是先下单，再输入密码支付。由于从用户下单，拉起支付框支付，到支付中心通知理财通
支付成功，整个动作并不连贯，并且由于各种异常情况的存在，例如支付中心通知理财通支
付成功延迟或者用户中途放弃，支付成功率并不是100％，也可能导致支付成功金额没有及
时累加，由于支付成功率的存在，如果支付前(下单)判断总金额会导致不准，如果支付后再
累加总金额可能因为延迟(整个操作完成至少需要几秒钟)，从而导致没有及时累加总金额
的问题。对于抢购类产品，由于收益率较高，会出现当天的额度在几分钟之内卖完的情况，
并发量很高。如果用户下单成功，但支付成功后发现已经超限则会退款。这样对于用户体验
是有伤害的。如何保证用户的购买成功金额尽最大可能接近于当日的购买上限，并将退款
的可能性降到最低，成为一个急需解决的问题。
针对这个问题，目前在下单的时候判断如果已经支付成功金额加上当前金额大于
当日购买限额或者已经打上售罄标记则拒绝，支付确认的时候判断购买上限减当日已购买
金额如果小于缓冲则打上售罄标记，这样是为了防止退款的场景。缓冲的大小由产品在管
理系统上配置。为了减少持有锁的时间、增加并发量，支付确认的时候先不加锁查询已经购
买金额，并且判断当前金额加上已经购买金额是否会超限，如果此时判断已经超限则退款，
否则，做单成功。在加锁和不加锁间寻求平衡是防止超卖的场景。
对于防退款的场景，采用本发明实施例，由于目前缓冲值的设置随意性太大，采用
本发明实施例，通过数据统计的方法对缓冲值给一个合理的建议值。可以通过统计历史的
数据作为以后缓冲值设置的参考，这些历史数据包括不同基金的支付成功率、并发量、每笔
交易金额以及退款量。统计的区间是一个交易日，日切模式不同的基金会有所差别。根据这
些数据我们可以给出一些规则：
规则1：缓冲值>平均每笔交易金额*每秒并发量*百分比，说明设置不合理，告警介
入；
规则2：缓冲值/单笔申购上限<一个配置的值，说明设置不合理，告警介入；
规则3：申购接口统计当前并发量>上一个交易日的最大并发量*百分比，启动排队
机制；
规则4：当前交易日下单总笔数*上一个交易日的支付成功率*每笔交易金额>每日
限额*百分比，启动排队机制。
上述规则中，百分比的值是一个经验值，需要根据线上数据调整，直到达到一个最
优值。当基金收益率有明显波动的时候，这个值也需要做相应调整，必要的时候可以引入机
器学习的算法进行训练。系统初始化的时候，规则1和规则2百分比的值和配置的值设置为
通过前一个交易日的数据算出来的值，规则2设置的初始值建议不要小于每秒并发量，规则
3的百分比可以初始化为120％，规则4的百分比可以初始化为80％。随着系统的运行，这些
值再慢慢调整。比如说初始值设置的不合理导致排队过晚启动，可以调整规则3和规则4的
百分比。如果缓冲值设置不合理导致有退款但未告警，则调整规则1或规则2的设置。规则1
缓冲值设置过大会导致有部分资产没有卖完；规则2配置的值过小会导致缓冲值设置过小
导致退款；规则3的百分比设置过大会导致启动排队机制较晚，依然会引起少量退款；规则4
的百分比设置过大效果同规则3。如果交易日之间收益率有较大波动，如收益率变小，则可
以通过调整参数调小缓冲值的大小或稍晚启动排队。
当启动排队机制的时候，后端先打一个标记并传给前端，前端拿到标记后在用户
下单时给用户二次确认的提示，用户点击确认以后发起预下单。准实时批跑捞取预下单数
据，根据用户发起的时间先后顺序排序后用一定的速度调实时接口下单。发起之前判断是
否已经售罄，如果已经售罄的，捞取还未处理的预下单数据，给用户发消息提醒，具体的支
付流程的序列图如图6所示，包括：前端的终端用户侧和后台的服务器侧，其中，cgi指理财
平台，除了理财平台，还包括：实现排队批跑的实体、支付中心、实现基金集成服务的实体、
实现核心交易服务的实体及基金公司。前端的用户发起理财产品申购后，在服务器集群中
进行处理，服务器集群中，用于请求响应和获取请求所针对的目标数据的，是由实现排队批
跑的实体、支付中心、实现基金集成服务的实体所构成的服务器集群，如500所标识的该服
务器集群对用户发起理财产品的申购请求进行处理的过程中，包括：发起排队、预下单、内
部排队，传输申购请求等。经500所标识的该服务器集群对申购请求处理后，将该处理后的
申购请求分别发送给实现核心交易服务的实体及基金公司，收到返回结果，将返回结果反
馈给cgi去生成支付跳转链接，将支付跳转链接返回给前端处理。前端调用支付中心完成支
付后，支付结果回调，向实现基金集成服务的实体发送支付确认，在支付确认后，通知基金
公司支付结果，返回所请求的理财产品申购成功的结果给前端，更新后台的申购单状态。如
果所请求的理财产品申购无法申购，则将申购失败的结果给前端，更新后台的申购单状态。
对于防超卖的场景，现有技术中，mysql事务中提供了四种隔离级别：读取未提交
内容(read uncommitted)、读取提交内容(read committed)、可重复读(repeatable
read)、可串行化(serializable)。目前理财通线上数据库使用的隔离级别是read
committed，它可以解决脏读的问题，但是无法解决不可重复读的问题。所谓不可重复读就
是用户运行同一语句两次，看到的结果是不同的。只有加锁查询能解决不可重复读的问题，
但是加锁查询会导致系统的并发性能大大降低。业务上通常需要做权衡。结合业务的支付
流程，由于不加锁查询可能导致查询的结果不准，那么后面做成功的单，很有可能是因为超
卖需要退款的单。因此这种方法不能解决超卖的问题，由于缓冲的设置具有随意性，因此也
不能解决因为缓冲设置不合理导致的大量退款或少卖的情况。
采用本发明实施例，利用mysql事务的特性解决超卖的问题，同时，利用上述防退
款场景中的数据统计加排队的机制，将退款的可能性降到最低。mysql事务主要用于处理操
作量大，复杂度高的数据。比如说，在人员管理系统中，删除一个人员，即需要删除人员的基
本资料，也要删除和该人员相关的信息，如信箱，文章等等，这样，这些数据库操作语句就构
成一个事务。事务是必须满足4个条件：事务的原子性、一致性、隔离性和持久性。其中，所述
事务的原子性指：一组事务，要么成功；要么撤回。所述一致性指：事务在完成时，必须使所
有的数据都保持一致状态。所述隔离性指：由并发事务所作的修改必须与任何其它并发事
务所作的修改隔离。事务的100％隔离，需要牺牲速度。所述持久性指：事务完成之后，它对
于系统的影响是永久性的。可靠性和高速度不可兼得。具体的，对于防超卖，采用本发明实
施例也可以用缓冲值来控制请求的并发响应。在支付确认的时候先不加锁查询已支付成功
的金额，判断是否需要退款，如果需要退款，和已有逻辑保持一致；否则将做单成功。事务的
最后加锁查询已支付成功的金额，重新判断是否需要退款，如果不需要则更新已支付成功
金额，否则抛异常，目前的方案没有抛异常，仍然做成功，从而会导致超卖，由支付回调补单
批跑重新发起支付确认，这时不加锁查询出已经支付成功的金额再次判断的时候就已经可
以得出退款的结论，因为之前加锁查询到的是已经提交的事务的最新值，总金额只加不减。
这种方法可以解决超卖的问题，最后一笔可能导致超卖的会判断为退款。而支付中心通知
理财通支付确认延迟的问题，可以通过补单批跑来准实时的获取财付通侧的支付数据，手
动发起调用理财通的支付确认来解决。通过上述一系列处理，在加锁和不加锁间寻求平衡，
从而利用mysql事务的特性解决了超卖的问题。在申购接口中统计并发量对代码有倾入性，
还可以考虑使用批跑统计或接入监控系统已有数据。采用本发明实施例，能有效的解决因
抢购导致的超卖问题，并且能将因超卖导致的退款量降到最低。
在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其
它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为
一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或
可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部
分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合
或通信连接，可以是电性的、机械的或其它形式的。
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显
示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单
元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可
以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述
集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过
程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序
在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读
存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或
者光盘等各种可以存储程序代码的介质。
或者，本发明上述集成的单元如果以软件功能单元的形式实现并作为独立的产品
销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施
例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，
该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以
是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。
而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码
的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何
熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵
盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。