用于处理用户请求的方法和设备

1.一种用于处理用户请求的方法，包括：
接收用于响应订单的用户请求；
根据所述订单的发送时间和接收到所述用户请求的接收时间，确定与所述用户请求对应的用户响应时间，所述用户响应时间是指在所述订单的发送与所述用户请求的接收之间的时间间隔；
根据所述用户响应时间，确定针对所述订单的待选用户请求；以及
从所述待选用户请求中选择其中一个用户请求进行处理。
2.根据权利要求1所述的方法，其中根据所述用户响应时间，确定针对所述订单的待选用户请求包括：
在所述用户响应时间小于预定响应时间时，拒绝所述用户请求；以及
在所述用户响应时间大于或等于所述预定响应时间时，将所述用户请求确定为所述待选用户请求。
3.根据权利要求1所述的方法，其中根据所述用户响应时间，确定针对所述订单的待选用户请求包括：
在所述用户响应时间小于或等于第一预设时间间隔时，拒绝所述用户请求；
在所述用户响应时间大于或等于比所述第一预设时间间隔大的第二预设时间间隔时，将所述用户请求确定为所述待选用户请求；以及
在所述用户响应时间大于所述第一预设时间间隔且小于所述第二预设时间间隔时，根据接收到的针对所述订单的用户请求的数目确定是否将所述用户请求确定为所述待选用户请求。
4.根据权利要求3所述的方法，其中在所述用户响应时间大于所述第一预设时间间隔且小于所述第二预设时间间隔时，根据接收到的针对所述订单的用户请求的数目确定是否将所述用户请求确定为所述待选用户请求包括：
在接收到的针对所述订单的用户请求的数目大于预定数量时，拒绝所述用户请求；以及
在接收到的针对所述订单的用户请求的数目小于或等于所述预定数量时，将所述用户请求确定为所述待选用户请求。
5.根据权利要求1所述的方法，其中从所述待选用户请求中选择其中一个用户请求进行处理包括：
根据以下中的一项或多项来进行所述选择：
所述用户响应时间；
用户的当前位置和所述订单中的始发位置之间的距离；以及
从所述用户的当前位置到达所述订单中的始发位置所需的时间。
6.一种用于处理用户请求的设备，包括：
接收装置，用于接收用于响应订单的用户请求；
第一确定装置，用于根据所述订单的发送时间和接收到所述用户请求的接收时间来确定与所述用户请求对应的用户响应时间，所述用户响应时间是指在所述订单的发送与所述用户请求的接收之间的时间间隔；
第二确定装置，用于根据所述用户响应时间，确定针对所述订单的待选用户请求；以及选择装置，用于从所述待选用户请求中选择其中一个用户请求进行处理。
7.根据权利要求6所述的设备，其中所述第二确定装置包括：
拒绝单元，用于在所述用户响应时间小于预定响应时间时，拒绝所述用户请求；以及确定单元，用于在所述用户响应时间大于或等于所述预定响应时间时，将所述用户请求确定为所述待选用户请求。
8.根据权利要求6所述的设备，其中所述第二确定装置包括：
拒绝单元，用于在所述用户响应时间小于或等于第一预设时间间隔时，拒绝所述用户请求；
第一确定单元，用于在所述用户响应时间大于或等于比所述第一预设时间间隔大的第二预设时间间隔时，将所述用户请求确定为所述待选用户请求；以及
第二确定单元，用于在所述用户响应时间大于所述第一预设时间间隔且小于所述第二预设时间间隔时，根据接收到的针对所述订单的用户请求的数目确定是否将所述用户请求确定为所述待选用户请求。
9.根据权利要求8所述的设备，其中所述第二确定单元包括：
拒绝子单元，用于在接收到的针对所述订单的用户请求的数目大于预定数量时，拒绝所述用户请求；以及
确定子单元，用于在接收到的针对所述订单的用户请求的数目小于或等于所述预定数量时，将所述用户请求确定为所述待选用户请求。
10.根据权利要求6所述的设备，其中所述选择装置根据以下中的一项或多项来进行所述选择：
所述用户响应时间；
用户的当前位置和所述订单中的始发位置之间的距离；以及
从所述用户的当前位置到达所述订单中的始发位置所需的时间。

用于处理用户请求的方法和设备\n技术领域\n[0001] 本公开的实施例涉及数据处理，更具体地涉及一种用于处理用户请求的方法和设备。\n背景技术\n[0002] 随着移动互联网的发展，出现了越来越多的应用程序。在这些应用程序的使用中，通常需要客户端与服务器端之间的交互。相应地，在服务器端通常需要处理来自客户端的大量用户请求。\n[0003] 在现有技术中，服务器端通常按照先来先处理的原则来处理用户请求。但是这种处理方式在某些应用中会带来不便。例如，在打车应用中，针对服务器端发出的订单，司机用户会向服务器发出用于响应该订单的用户请求(即，进行抢单)。如果服务器按照先来先处理原则处理这些用户请求，就会使得移动设备性能好的司机用户的用户请求要比性能差的先获得处理，反应快的司机用户的用户请求要比反应慢的先获得处理。这样，订单可能无法被分配给最合适的司机(例如，距离最近的司机用户)。另一方面，某些司机用户可能使用加速器插件，以达到最快响应的目的。这样会扰乱整个打车平台的公平性，造成不合理的订单分配。\n[0004] 因此，需要一种改进的用户请求处理方式，以便克服上述问题。\n发明内容\n[0005] 本公开的实施例的目的在于提供一种用于处理用户请求的方法和设备，以更合理地处理用户请求，使得在诸如打车软件之类的应用中实现合理公平的订单分配。\n[0006] 根据本公开实施例的一个方面，提供一种用于处理用户请求的方法，包括：接收用于响应订单的用户请求；确定与所述用户请求对应的用户响应时间；根据所述用户响应时间，确定针对所述订单的待选用户请求；以及从所述待选用户请求中选择其中一个用户请求进行处理。\n[0007] 在一个实施例中，确定与所述用户请求对应的用户响应时间包括：根据所述订单的发送时间和接收到所述用户的用户请求的接收时间，确定所述用户响应时间。\n[0008] 在一个实施例中，根据所述用户响应时间，确定针对所述订单的待选用户请求包括：在所述用户响应时间小于预定响应时间时，拒绝所述用户请求；以及在所述用户响应时间大于或等于所述预定响应时间时，将所述用户请求确定为所述待选用户请求。\n[0009] 在一个实施例中，根据所述用户响应时间，确定针对所述订单的待选用户请求包括：在所述用户响应时间小于或等于第一预设时间间隔时，拒绝所述用户请求；在所述用户响应时间大于或等于比所述第一预设时间间隔大的第二预设时间间隔时，将所述用户请求确定为所述待选用户请求；以及在所述用户响应时间大于所述第一预设时间间隔且小于所述第二预设时间间隔时，根据接收到的针对所述订单的用户请求的数目确定是否将所述用户请求确定为所述待选用户请求。\n[0010] 在一个实施例中，根据接收到的针对所述订单的用户请求的数目确定是否将所述用户请求确定为所述待选用户请求包括：在接收到的针对所述订单的用户请求的数目大于预定数量时，拒绝所述用户请求；以及在接收到的针对所述订单的用户请求的数目小于或等于所述预定数量时，将所述用户请求确定为所述待选用户请求。\n[0011] 在一个实施例中，从所述待选用户请求中选择其中一个用户请求进行处理包括：\n根据以下中的一项或多项来进行所述选择：所述用户响应时间；用户的当前位置和所述订单中的始发位置之间的距离；以及从所述用户的当前位置到达所述订单中的始发位置所需的时间。\n[0012] 根据本公开实施例的另一方面，提供一种用于处理用户请求的设备，包括：接收装置，用于接收用于响应订单的用户请求；第一确定装置，用于确定与所述用户请求对应的用户响应时间；第二确定装置，用于根据所述用户响应时间，确定针对所述订单的待选用户请求；选择装置，用于从所述待选用户请求中选择其中一个用户请求进行处理。\n[0013] 在一个实施例中，所述第一确定装置根据所述订单的发送时间和接收到所述用户的用户请求的接收时间，确定所述用户响应时间。\n[0014] 在一个实施例中，所述第二确定装置包括：拒绝单元，用于在所述用户响应时间小于预定响应时间时，拒绝所述用户请求；以及确定单元，用于在所述用户响应时间大于或等于所述预定响应时间时，将所述用户请求确定为所述待选用户请求。\n[0015] 在一个实施例中，所述第二确定装置包括：拒绝单元，用于在所述用户响应时间小于或等于第一预设时间间隔时，拒绝所述用户请求；第一确定单元，用于在所述用户响应时间大于或等于比所述第一预设时间间隔大的第二预设时间间隔时，将所述用户请求确定为所述待选用户请求；以及第二确定单元，用于在所述用户响应时间大于所述第一预设时间间隔且小于所述第二预设时间间隔时，根据接收到的针对所述订单的用户请求的数目确定是否将所述用户请求确定为所述待选用户请求。\n[0016] 在一个实施例中，所述第二确定单元包括：拒绝子单元，用于在接收到的针对所述订单的用户请求的数目大于预定数量时，拒绝所述用户请求；以及确定子单元，用于在接收到的针对所述订单的用户请求的数目小于或等于所述预定数量时，将所述用户请求确定为所述待选用户请求。\n[0017] 在一个实施例中，所述选择装置根据以下中的一项或多项来进行所述选择：所述用户响应时间；用户的当前位置和所述订单中的始发位置之间的距离；以及从所述用户的当前位置到达所述订单中的始发位置所需的时间。\n[0018] 根据本公开的实施例，在处理用户请求时，可以实现高效公平的订单分配，方便用户的使用，以及改善用户体验。\n附图说明\n[0019] 此处所说明的附图用来提供对本公开的进一步理解，构成本公开的一部分，本公开的示意性实施例及其说明用于解释本公开，并不构成对本公开的不当限定。在附图中：\n[0020] 图1示出了根据本公开的一个实施例的用于处理用户请求的方法的流程图；\n[0021] 图2示出了根据本公开的一个实施例的用于根据用户响应时间确定针对订单的待选用户请求的方法的流程图；\n[0022] 图3示出了根据本公开的另一实施例的用于根据用户响应时间确定针对订单的待选用户请求的方法的流程图；以及\n[0023] 图4示出了根据本公开的一个实施例的用于处理用户请求的设备的示意框图。\n具体实施方式\n[0024] 本公开的实施例的构思在于，根据用户对订单的响应时间(用户响应时间)来排除一些反应速度过快的不合法的用户请求。具体地，服务器可以通过预设一个合理间隔时间(预定响应时间或者预设时间间隔)，然后将用户响应时间与该合理间隔时间进行比较，来筛除掉用户响应时间过短的那些不合法的用户请求。与此同时，可以确定出针对订单的待选用户请求，并且进一步地，可以根据例如用户响应时间、用户的当前位置和订单中的始发位置之间的距离、从用户的当前位置到达订单中的始发位置所需的时间等等，来从待选用户请求中选择一个合适的用户请求进行响应处理，从而完成订单的下发。由此避免了一些恶意抢单行为，同时提高了订单完成的效率。\n[0025] 在本公开的一个具体应用场景中，在服务器端，服务器可以在下发订单后的合理间隔时间内不响应任何用户请求，即拒绝该合理间隔时间内的所有用户请求。相应地，在司机用户端，可以设置一个等于合理间隔时间的倒计时，使得在倒计时过去之后司机才能开始抢单。这样也可以使得司机在抢单前充分了解订单的信息，例如出发地和目的地，而不会盲目作出对订单的响应操作。\n[0026] 为使本公开的实施例的目的、技术方案和优点更加清楚，以下结合附图及具体实施例，对本公开的实施例作进一步的详细说明。图1示出了根据本公开一个实施例的用于处理用户请求的方法100。\n[0027] 如图1所示，在步骤S101处，接收用于响应订单的用户请求。\n[0028] 在一个实施例中，在下发订单之后，服务器可以接收来自用户的用于响应订单的用户请求。\n[0029] 根据本公开的一个具体实施例，例如在打车软件的移动应用中，在服务器发布了一个订单(至少包含了打车用户的始发地信息、目的地信息、用车时间信息等)之后，希望接单的一个或多个司机用户会向服务器请求接收该订单，即，会分别向服务器发送希望接单的用户请求。因而，服务器可以接收用于响应订单的用户请求。\n[0030] 接着，在步骤S102处，确定与用户请求对应的用户响应时间。\n[0031] 在一个实施例中，服务器在接收到用于响应订单的用户请求之后，可以确定出与所述用户请求对应的用户响应时间。在一个实施例中，所述用户响应时间是指从服务器下发订单到服务器接收到用户的用户请求之间的时间间隔。\n[0032] 在本公开的一个具体实施例中，根据订单的发送时间和接收到用户的用户请求的接收时间来确定用户响应时间。在一个实施例中，通过将接收到用户的用户请求的接收时间减去订单的发送时间，确定出用户的对订单的用户响应时间。\n[0033] 接着，在步骤S103，根据在步骤S102确定出的用户响应时间，确定出针对订单的待选用户请求。\n[0034] 具体来说，服务器可以通过多种方式，来利用在步骤S102确定出的用户响应时间确定出针对订单的待选用户请求。\n[0035] 在本公开的一个具体实施例中，可以利用用户响应时间与预定阈值(预定响应时间)的比较来判断用户请求是否正常，以便选择出合理的待选用户请求。下面结合图2对此进行具体描述。\n[0036] 图2示出了根据本公开的一个实施例的用于根据用户响应时间确定针对订单的待选用户请求的方法200的流程图。\n[0037] 如图2所示，在步骤S201处，判断用户响应时间是否小于预定响应时间。\n[0038] 在一个可选实施例中，可以基于用户反应时间、发送订单所需要的时间、接收用户请求所需要的时间来设定该预定响应时间。在一个示例中，该预定响应时间可以是正常用户对订单做出最快的响应所需要的时间。在一个实施例中，可以基于用户对订单的最快反应时间、服务器发送订单所消耗的时间以及服务器接收用户请求所消耗的时间来设定该预定响应时间。\n[0039] 在一个实施例中，用户对订单的最快反应时间至少可以包括用户浏览订单所需要的时间以及用户做出决定所需要的时间。而服务器发送订单所消耗的时间以及服务器接收用户请求所消耗的时间可以根据移动网络运营商的传送速率来设定。\n[0040] 例如，在打车软件的移动应用中，用户浏览订单所需要的时间可以设置为1秒，用户做出决定所需要的时间例如可以设置为0.5秒。因而，用户对订单的正常反应时间可以被设置为1.5秒。服务器发送订单所消耗的时间以及服务器接收用户请求所消耗的时间可以分别设置为0.1秒。这样，在打车软件的移动应用中，最快响应时间可以设置为1.7秒。\n[0041] 在该步骤S201中，如果用户响应时间小于预定响应时间，则进入步骤S202。在步骤S202处，拒绝所述用户请求。\n[0042] 例如，在打车软件的移动应用中，在预定响应时间设置为1.7秒的情况下，如果发现某个用户的用户响应时间小于1.7秒，例如仅为0.5秒，则可以拒绝该用户的用户请求。\n[0043] 在该步骤S201中，如果用户响应时间大于或等于预定响应时间，则进入步骤S203。\n在步骤S203处，将所述用户请求确定为待选用户请求。\n[0044] 例如，在打车软件的移动应用中，在预定响应时间设置为1.7秒的情况下，如果发现某个用户的用户响应时间大于或等于1.7秒，例如为2秒，则可以将该用户的用户请求确定为待选用户请求。\n[0045] 通过图2所述的处理，可以简单准确地排除一些不正常的用户请求，由此可以制止一些在移动设备上使用加速器软件的用户的恶意抢单的行为。\n[0046] 在图2所示的实施例中，通过将用户响应时间和预定阈值(预定响应时间)进行比较来选择待选用户请求。但该阈值的计算中可能存在误差，由此可能导致响应时机不合理。\n因此，发明人还提出了另一种确定待选用户请求的可选方式，其中通过划分预定阈值范围的方式利用统计排除的方法来确定待选用户请求，下面结合图3对此进行具体描述。\n[0047] 图3示出了根据本公开另一个实施例的用于根据用户响应时间确定针对订单的待选用户请求的方法300的流程图。在本实施例中，预先设定一个预定阈值范围为[第一预设时间间隔T1，第二预设时间间隔T2]，其中T2大于T1。另外，假设用户响应时间为T。\n[0048] 在一个具体实施例中，可以将第一预设时间间隔T1设定为明显不在合理时间间隔内的时间差，将第二预设时间间隔T2设定为明显在合理时间间隔内的时间差。\n[0049] 在一个实施例中，同样可以基于用户反应时间、发送订单所需要的时间、接收用户请求所需要的时间来设定该第一预设时间间隔T1和该第二预设时间间隔T2。在另一个实施例中，用户对订单的反应时间至少可以包括用户浏览订单所需要的时间以及用户做出决定所需要的时间。而服务器发送订单所消耗的时间以及服务器接收用户请求所消耗的时间可以根据移动网络运营商的传送速率来设定。\n[0050] 假设正常用户对订单做出响应所需要的时间最快可以为t1，最慢可以为t2，其中t2>t1。假设服务器发送订单所消耗的时间为t3，服务器接收用户请求所消耗的时间为t4。\n则可以设定第一预设时间间隔T1＝t1+t3+t4以及第二预设时间间隔T2＝t2+t3+t4。\n[0051] 例如，在打车软件的移动应用中，用户浏览订单所需要的时间例如为1.0-2.0秒，用户做出决定所需要的时间例如为0.5-1.0秒。因而，用户对订单的正常反应时间可以例如为1.5-3.0秒。即，t1＝1.5秒，t2＝3.0秒。服务器发送订单所消耗的时间t3以及服务器接收用户请求所消耗的时间t4可以例如分别设置为0.1秒。这样，在打车软件的移动应用中，可以设定第一预定时间间隔T1为1.7秒以及第二预定时间间隔T2为3.2秒。\n[0052] 如图3所示，在步骤S301处，判断用户响应时间T是否小于或等于第一预设时间间隔T1。\n[0053] 在一个实施例中，如果用户响应时间T小于或等于第一预设时间间隔T1，则认为当前用户请求是不合法的用户请求，进入步骤S302。在步骤S302处，拒绝所述用户请求。\n[0054] 如果用户响应时间T大于第一预设时间间隔T1，则进入步骤S303。在该步骤S303处，判断用户响应时间T是否大于或等于第二预设时间间隔T2。\n[0055] 如果在步骤S303处判定T大于或等于T2，则认为所述用户请求是合法的用户请求，进入步骤S304。在步骤S304处，将所述用户请求确定为针对订单的待选用户请求。\n[0056] 如果在步骤S303处判定T小于T2，即，T1