为集中的时间段内的交易数量均大于预定值I笔。当前时刻为上午9:30时，该当前时刻处于该用户产生交易行为集中的9-10点之间，则可以将该用户的基本状态更新为忙碌状态。
[0056]也可以通过相关第一用户和/或第二用户的当前数据交互数量计算相关第一用户和/或第二用户的基本状态。当相关第一用户和/或第二用户当前数据交互数量大于预定值时，则将相关第一用户和/或第二用户的基本状态更新为忙碌状态；当相关第一用户和/或第二用户当前数据交互数量小于或等于预定值时，则将相关第一用户和/或第二用户的基本状态更新为空闲状态。
[0057]例如，当第二用户为商户时，该商户当前处理的交易量为8笔，预先设定的预定值为10笔，那么商户当前处理的交易量小于预定值(8笔小于10笔)，则该商户的基本状态为空闲，该商户还有能力处理新产生的交易。
[0058]进一步地，用于与数据交互数量进行比较的预定值，可以根据历史行为记录来进行设置，也可以由第一用户或第二用户根据经验进行自定义设置。例如，对于与商户(第二用户)的交易数量(数据交互数量)进行比较的预设值，可以根据商户的历史交易记录(历史行为记录)来计算出预设值，如，计算商户每分钟可以处理的交易数量的峰值(最大值)是20笔，那么可以将该20笔作为预设值。该预定值还可以是商户在应用程序(客户端，如APP)中自定义设置其每分钟可以处理的交易笔数(数据交互数量)，如，该商户每分钟可以处理10笔交易，则可以将该10笔作为该商户的预定值。在这两种情况下，可以优先使用用户(第一用户、第二用户)自定义设置的预定值，如果用户没有自定义设置预定值，则使用通过历史行为记录计算出来的预定值。
[0059]也即是说，用于与历史行为记录中的数据交互数量进行比较的预定值和与当前数据交互数量进行比较的预定值可以是相同的预定值，也可以是不同的预定值。
[0060]在一个实施例中，可以根据具有不同位置信息的应用场景和/或根据应用场景的网络状态的差别，设置相应的所述预定值。也即是说，用于与数据交互数量进行比较的预定值，可以根据应用场景和/或应用场景的网络状态的不同进行差别性设置。具体而言，应用场景可以包括商场、酒店、家庭、工作场所等等。每个应用场景中的网络状态不同。例如，在网络状态较好时，用户在一分钟内可以处理5个与数据交互相关的操作，完成5个用户之间的数据交互。在网络状态不好的情况下，用户在一分钟可以处理I个与数据交互相关的操作，完成I个用户之间的数据交互。那么网络状态的好坏直接影响数据交互的执行速度，可以在网络状态较好的应用场景中，或者在一个应用场景中网络状态较好的时段，设置数值较大的预定值。可以在网络状态不好的应用场景中，或者在一个应用场景中网络状态不好的时段，设置数值较小的预定值。进一步地，每一个应用场景拥有一个位置信息，如商场的地理位置信息可以是付款台的地理位置信息，商场的预定范围可以是能够覆盖商场面积的地理位置范围。当用户的地理位置信息处于商场地理位置范围内时，则采用专门为商场设置的预定值来衡量用户的基本状态。
[0061]进一步地，服务器可以将每一个相关第一用户的基本状态推送给对应的相关第一用户和推送给第二用户，并且将第二用户的基本状态推送给该第二用户和推送给每一个相关第一用户。
[0062]当第一用户和第二用户登录用于数据交互的应用程序后，处于第二用户预定范围内的相关第一用户可以在该应用程序中看到其自身的基本状态和该第二用户的基本状态，第二用户也可以在应用程序中看到其自身的基本状态以及处于其预定范围内的一个或多个第一用户(相关第一用户)的基本状态。
[0063]在步骤S130处，接收来自相关第一用户中的特定相关第一用户或第二用户发送的特定相关第一用户与第二用户之间进行数据交互的数据交互请求。数据交互请求的类型可以是根据特定相关第一用户和/或第二用户的基本状态确定的。
[0064]换言之，接收来自相关第一用户中的特定相关第一用户或第二用户、基于特定相关第一用户和/或第二用户的基本状态、发送的在特定相关第一用户与第二用户之间进行数据交互的数据交互请求。
[0065]特定相关第一用户可以是，处于第二用户预定范围内的相关第一用户中，需要与该第二用户进行数据交互的其中一个相关第一用户。
[0066]相关第一用户的基本状态和第二用户的基本状态相互可见。换言之，相关第一用户可以看到第二用户的基本状态，第二用户也可以看到相关第一用户的基本状态。进一步地，相关第一用户中的特定相关第一用户或第二用户可以根据看到的特定相关第一用户和/或第二用户的基本状态向服务器发送数据交互请求，该数据交互请求用于请求服务器在特定相关第一用户和第二用户之间进行数据交互。
[0067]该数据交互请求可以包括实时性数据交互请求和延迟性数据交互请求。实时性数据交互请求，用于请求服务器在特定相关第一用户和第二用户之间立即进行数据交互。延迟性数据交互请求，用于请求服务器延迟一定时间后再在特定相关第一用户和第二用户之间进行数据交互。服务器可以根据接收到的实时性数据交互请求实时地生成数据交互指令，并下发给进行数据交互的特定相关第一用户和第二用户。服务器可以根据接收到的延迟性数据交互请求，询问第二用户是否可以延迟生成数据交互指令，若第二用户同意延迟生成数据交互指令，则服务器通知特定相关第一用户延迟数据交互时间，并在延迟时间过后生成数据交互指令，下发给进行数据交互的特定相关第一用户和第二用户。其中，该延迟时间可以根据应用场景的不同设置经验值，或者是未发送数据交互请求的一方(特定相关第一用户、第二用户)的基本状态从忙碌变为空闲时所经历的时间。若该延迟性数据交互请求为第二用户发送，则表示该第二用户同意服务器延迟生成数据交互指令。例如:用户在进行支付时，点击立即支付，表示向服务器发送实时性数据交互请求，点击生成订单，表示向服务器发送延迟性数据交互请求。
[0068]具体而言，当特定相关第一用户和/或第二用户的基本状态为忙碌时，服务器可以接收来自特定相关第一用户或第二用户的实时性数据交互请求或延迟性数据交互请求。换言之，服务器接收延迟性数据交互请求表示，当特定相关第一用户和/或第二用户的基本状态为忙碌时，第二用户可以允许服务器延迟一定时间执行与特定相关第一用户的数据交互。那么特定相关第一用户和/或第二用户可以发送延迟性数据交互请求，来延迟数据交互的时间。
[0069]当特定相关第一用户和第二用户的基本状态为空闲时，服务器可以接收来自特定相关第一用户或第二用户的实时性数据交互请求。也即是说，当特定相关第一用户和第二用户的基本状态都有空闲时，特定相关第一用户或第二用户可以发送实时性数据交互请求，以作实时性的数据交互。
[0070]在一个实施例中，特定相关第一用户或第二用户在发送数据交互请求之前，可以相互交换、服务器为每一个第一用户和每一个第二用户预先分配的唯一的身份编码(ID)。相关第一用户和第二用户在各自登录的应用程序中可以查看自身的ID以及显示的相关第一用户或第二用户的ID。也即是说，相关第一用户可以在其应用程序中查看该相关第一用户预定范围内的每一个第二用户的ID，第二用户可以在其应用程序中查看该第二用户预定范围内的每一个相关第一用户的ID。当相关第一用户中的特定相关第一用户或第二用户需要发送数据交互请求时，可以针对特定/目标ID，向服务器发送数据交互请求。
[0071]例如，第二用户是商户，第一用户有用户A、用户B和用户C。其中商户的ID为“111”，用户A的ID为“001”，用户B的ID为“002”，用户C的ID为“003”。当商户、用户A、用户B和用户C均登录用于支付(数据交互)的应用程序后，根据商户、用户A、用户B和用户C的地理位置信息，在商户使用的应用程序中可以显示处于其预定范围内的用户A的ID “001，，、用户B的ID “002”和用户C的ID “003”。当用户A需要向商户进行支付时，用户A可以将其ID “001”告知商户，商户在其使用的应用程序中查找ID “001”，并针对ID为“001”的用户A，向服务器发送支付请求(数据交互请求)。
[0072]在步骤S140处，根据数据交互请求的类型，在特定相关第一用户和第二用户之间执行数据交互。
[0073]当服务器接收到延迟性数据交互请求时，则在延迟第二用户所允许延迟的一定时间后，执行特定相关第一用户和第二用户的数据交互。
[0074]当服务器接收到实时性数据交互请求时，则执行特定相关第一用户和第二用户的数据交互。
[0075]具体而言，可以为第二用户授予可以延迟数据交互时间的权限。当特定相关第一用户和/或第二用户的基本状态为忙碌时，可以由第二用户通过服务器发起延迟执行数据交互的指令，发起该指令一定时间(延迟时间)后，执行特定相关第一用户与第二用户的数据交互。例如，在商场中进行支付，顾客为第一用户，商户为第二用户，由于该商户的顾客密度较大，该商户的基本状态为忙碌，所以该商户允许其顾客延迟一定时间进行支付，当进行支付时，顾客或商户可以主动向服务器发送延迟性支付请求(延迟性数据交互请求)，服务器接收到该延迟性支付请求，若该请求来自顾客，则服务器为商户弹出提示“是否可以延迟支付”，商户可以点击“是”按钮，表示同意，则服务器延迟一定时间在顾客和商户之间进行数据交互(支付)；若该请求来自商户，则服务器不询问商户是否可以延迟支付，直接延迟一定时间后执行顾客和商户之间的数据交互(支付)。
[0076]更具体地，当需要进行数据交互的