CN113792950A - 任务派发方法及装置、计算机可读存储介质、电子设备 - Google Patents

Abstract

本公开属于计算机技术领域，涉及一种任务派发方法及装置、计算机可读存储介质、电子设备。该方法包括：当接收到业务信息时，从业务信息中获取目标对象标识；查询与目标对象标识对应的目标状态信息，并获取与目标对象对应的目标任务；依据业务信息在预设时长内对目标状态信息进行更改得到更改结果，并根据更改结果确定目标任务的派发结果。在本公开中，一方面，当接收到业务信息时，先对目标状态信息进行更改，再向下游通知业务信息的变更，满足了任务派发的实时性；另一方面，根据更改结果确定目标任务的派发结果，避免了由于网络异常导致的派发结果和业务信息不一致的情况发生，不仅优化了用户的体验，而且降低了派单结果的出错率。

Description

任务派发方法及装置、计算机可读存储介质、电子设备

技术领域

本公开涉及计算机技术领域，尤其涉及一种任务派发方法与任务派发装置、计算机可读存储介质及电子设备。

背景技术

随着计算机技术的发展，越来越多的人选择通过网络实现在线问诊、在线预约车辆、在线订餐、在线送货等事务。在这些事务中，任务派发方和完成任务方属于两个相互独立的系统，需要任务派发方对完成任务方进行任务的派发，并且，任务派发方的功能依赖于任务完成方当前的状态。

在相关技术中，采用的解决方法是2PC(Two-phase commitment protocol，两段提交协议)、TCC(Try-Confirm-Cancel，预留确认取消模式)、本地消息表或者事务信息的方式，具体的，在第一种方式中，当网络发生异常时会导致任务派发方的派发结果与完成任务方的当前状态不一致，除此之外，一旦任务完成方所在的系统发生故障，直到故障消除任务派发方才继续进行任务的派发，无法满足任务派发的实时性；在第二种方式中，需要完成任务方向任务派发方进行多次请求，同样无法满足任务派发的实时性；在第三种和第四种方式中，当接收到任务完成方的状态变更信息后，不会先通知任务派发方，同样无法满足任务派发的实时性。

鉴于此，本领域亟需开发一种新的任务派发方法及装置。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种任务派发方法、任务派发装置、计算机可读存储介质及电子设备，进而至少在一定程度上克服由于相关技术的限制而导致的任务派发的过程中不具有实时性的问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本发明实施例的第一个方面，所述方法包括：当接收到业务信息时，从所述业务信息中获取目标对象标识；查询与所述目标对象标识对应的目标状态信息，并获取与所述目标对象标识对应的目标任务；依据所述业务信息在预设时长内对所述目标状态信息进行更改得到状态更改结果，并根据所述状态更改结果确定所述目标任务的派发结果。

在本发明的一种示例性实施例中，所述从所述业务信息中获取目标对象标识，包括：获取与所述业务信息对应的状态标识，并获取预设状态标识；判断所述状态标识与所述预设状态标识是否一致得到标识判断结果；若所述标识判断结果为所述状态标识与所述预设状态标识一致，从所述业务信息中获取目标对象标识。

在本发明的一种示例性实施例中，所述查询与所述目标对象标识对应的目标状态信息，包括：获取状态信息列表，并从所述状态信息列表中查询与所述目标对象标识对应的目标状态信息。

在本发明的一种示例性实施例中，所述根据所述状态更改结果确定所述目标任务的派发结果，包括：判断在所述预设时长内是否接收到与所述状态更改结果对应的状态事件信息，以得到第一状态判断结果；根据所述第一状态判断结果确定所述目标任务的派发结果。

在本发明的一种示例性实施例中，所述根据所述第一状态判断结果确定所述目标任务的派发结果，包括：若所述第一状态判断结果为接收到所述状态事件信息，根据所述状态更改结果保持所述目标任务的派发结果。

在本发明的一种示例性实施例中，所述根据所述第一状态判断结果确定所述目标任务的派发结果，包括：若所述第一状态判断结果为未收到所述状态事件信息，在所述预设时长后接收与所述目标对象标识对应的当前状态信息；判断所述当前状态信息和所述状态更改结果得到第二状态判断结果；若所述第二状态判断结果为所述当前状态信息和所述状态更改结果一致，根据所述状态更改结果保持所述目标任务的派发结果；若所述第二状态判断结果为所述当前状态信息与所述状态更改结果不一致，根据所述状态更改结果更改所述目标任务的派发结果。

在本发明的一种示例性实施例中，所述在所述预设时长后接收与所述目标对象标识对应的当前状态信息，包括：获取补偿信息，并确定与所述补偿信息对应的预设时长；在所述预设时长后接收与所述目标对象标识对应的当前状态信息。

根据本发明实施例的第二个方面，所述装置包括：获取模块，被配置为当接收到业务信息时，从所述业务信息中获取目标对象标识；查询模块，被配置为查询与所述目标对象标识对应的目标状态信息，并获取与所述目标对象标识对应的目标任务；派发模块，被配置为依据所述业务信息在预设时长内对所述目标状态信息进行更改得到状态更改结果，并根据所述状态更改结果确定所述目标任务的派发结果。

根据本发明实施例的第三个方面，提供一种电子设备，包括：处理器和存储器；其中，存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现上述任意示例性实施例的任务派发方法。

根据本发明实施例的第四个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意示例性实施例中的任务派发方法。

由上述技术方案可知，本发明示例性实施例中的事件数据的处理方法、事件数据的处理装置、计算机存储介质及电子设备至少具备以下优点和积极效果：

在本公开的示例性实施例提供的方法及装置中，一方面，当接收到业务信息时，先对目标状态信息进行更改，再向下游通知业务信息的变更，满足了任务派发的实时性；另一方面，根据更改结果确定目标任务的派发结果，避免了由于网络异常导致的派发结果和业务信息不一致的情况发生，不仅优化了用户的体验，而且降低了派单结果的出错率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出本公开实施例中任务派发方法的流程示意图；

图2示意性示出本公开实施例中从业务信息中获取目标对象标识的流程示意图；

图3示意性示出本公开实施例中根据状态更改结果确定目标任务的派发结果的流程示意图；

图4示意性示出本公开实施例中根根据第一状态判断结果确定目标任务的派发结果的流程示意图；

图5示意性示出本公开实施例中在预设时长后接收与目标对象标识对应的当前状态信息的流程示意图；

图6示意性示出本公开示例性实施例中应用场景下任务派发的流程示意图；

图7示意性示出本公开实施例中一种任务派发装置的结构示意图；

图8示意性示出本公开实施例中一种任务派发方法的电子设备；

图9示意性示出本公开实施例中一种任务派发方法的计算机可读存储介质。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

本说明书中使用用语“一个”、“一”、“该”和“所述”用以表示存在一个或多个要素/组成部分/等；用语“包括”和“具有”用以表示开放式的包括在内的意思并且是指除了列出的要素/组成部分/等之外还可存在另外的要素/组成部分/等；用语“第一”和“第二”等仅作为标记使用，不是对其对象的数量限制。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。

针对相关技术中存在的问题，本公开提出了一种任务派发的方法。图1示出了任务派发方法的流程示意图，如图1所示，任务派发方法至少包括以下步骤：

步骤S110.当接收到业务信息时，从业务信息中获取目标对象标识。

步骤S120.查询与目标对象标识对应的目标状态信息，并获取与目标对象标识对应的目标任务。

步骤S130.依据业务信息在预设时长内对目标状态信息进行更改得到状态更改结果，并根据状态更改结果确定目标任务的派发结果。

在本公开的示例性实施例提供的方法及装置中，一方面，当接收到业务信息时，先对目标状态信息进行更改，再向下游通知业务信息的变更，满足了任务派发的实时性；另一方面，根据更改结果确定目标任务的派发结果，避免了由于网络异常导致的派发结果和业务信息不一致的情况发生，不仅优化了用户的体验，而且降低了派单结果的出错率。

下面对任务派发方法的各个步骤进行详细说明。

在步骤S110中，当接收到业务信息时，从业务信息中获取目标对象标识。

在本公开的示例性实施例中，业务信息指的是完成任务方发送的信息。举例而言，若完成任务方为医生，业务信息可以是医生关诊时发送的信息，可以是医生开诊时发送的信息，还可以是医生处于忙碌时发送的信息，还可以是医生请求减少任务派发量的信息，还可以是医生请求增加任务派发量的信息，本示例性实施例对此不做特殊限定。

举例而言，若完成任务方是司机，业务信息可以是司机上线时的信息，也可以是司机下线时的信息，还可以是司机正在完成一个任务时发送的信息，还可以是司机完成一个任务时发送的信息，本示例性实施例对此不做特殊限定。

举例而言，若完成任务方是外卖员，业务信息可以是外卖员开始接受任务时的信息，也可以是外卖员不再接受任务时的信息，还可以是外卖员请求重新验证送货地址的信息，还可以是外卖员点击货物已送达时的信息，还可以是外卖员请求延迟送达货物时的信息，本示例性实施例对此不做特殊限定。

举例而言，若完成任务方是送货司机，业务信息可以是司机开始接受任务时的信息，也可以是司机不再接收任务时的信息，也可以是司机无法联系到收货人时的信息，还可以是司机延迟送货时间的信息，还可以是司机请求重新验证收货地址的信息，本示例性实施例对此不做特殊限定。

值得说明的是，任何一种需要完成任务和任务派发两方的场景都属于本申请保护的范围，任何一种完成任务方向任务派发方发送的信息都属于本申请中的业务信息。

目标对象标识指的是发送业务信息的完成任务方的标识。目标对象标识可以是完成任务方的名称，可以是完成任务方的身份识别号，可以是完成任务方的昵称，还可以是完成任务方的身份证号，还可以是任何一个可以唯一代表完成任务方的信息，本示例性实施例对此不做特殊限定。

举例而言，若完成任务方是医生A，医生A可以通过点击终端上的关诊控件将状态改变为关诊状态，并且当点击关诊控件后，任务派发方会收到与关诊这一操作对应的业务信息，并且在业务信息中包含着与医生A对应的目标对象标识，具体的目标对象标识可以是医生A的真实姓名。

当任务派发方收到医生A发送的业务信息时，可以从业务信息中获取与医生A对应的医生真实姓名。

在可选的实施例中，图2示出了从业务信息中获取目标对象标识的流程示意图，如图2所示，该方法至少包括以下步骤：在步骤S210中，获取与业务信息对应的状态标识，并获取预设状态标识。

其中，状态标识代表的是业务信息类型的标识。

具体的，状态标识可以是一个数字，也可以是一串字符，还可以是一段文字，本示例性实施例对此不做特殊限定。

举例而言，若完成任务方为医生，业务信息可以是医生开诊时的信息，可以医生关诊时的信息，可以是医生请求增加问诊单的信息，可以是医生请求减少问诊单的信息，可以是医生报告任务派发出现异常时的信息，可以是医生报告任务派发异常消除时的信息。

将医生开诊和医生关诊时发送的业务信息设置为A类业务信息，并且与A类业务信息对应存在一个状态标识A，同理，将医生请求增加问诊单的信息和医生请求关闭问诊单的信息设置为B类信息，并且与B类业务信息对应存在一个状态标识B，将医生报告任务派发出现异常和异常消除的业务信息设置为C类业务信息，并且与C类业务信息对应存在一个状态标识C。

预设状态标识指的是预设的一种与某一类业务信息的类型对应的标识。

举例而言，若任务完成方是医生，任务派发方需要根据医生此时的关诊状态或开诊状态决定是否向医生进行任务的派发，此时需要将预设状态标识为与医生开诊或关诊对应的状态标识保持一致，且与医生关诊或开诊对应的状态标识为A，于是将预设转状态标识设置为A。

在步骤S220中，判断状态标识与预设状态标识是否一致得到标识判断结果。

对获取的状态标识和预设状态标识进行判断得到标识判断结果。

举例而言，获取的状态标识是A，获取的预设状态标识是B，判断状态标识A与预设状态标识B是否一致得到标识判断结果。

在步骤S230中，若标识判断结果为状态标识与预设状态标识一致，从业务信息中获取目标对象标识。

当标识判断结果是状态标识和预设状态标识一致时，从业务信息中获取目标状态标识。

举例而言，获取的预设状态标识是A，若获取的状态标识是与医生开诊和医生关诊时发送的业务信息对应的状态标识A，显然，状态标识与预设状态标识一致，此时从状态标识为A的业务信息中获取的目标对象标识可以是医生的真实姓名。

在本示例性实施例中，在获取目标对象标识之前增设了判断逻辑，将业务信息对应的状态标识和预设状态标识进行判读，当业务信息对应的状态标识和预设状态标识一致时，从业务信息中获取目标对象标识，避免了当状态标识和预设状态标识不一致时，仍然需要获取从业务信息中获取目标对象标识的情况发生，避免了不必要的性能损耗，使得方法的逻辑性更完善。

在步骤S120中，查询与所述目标对象标识对应的目标状态信息，并获取与所述目标对象标识对应的目标任务。

在本公开的示例性实施例中，当任务完成方产生信息后，会先将业务信息发送至任务派发方，这样做可以在第一时间让任务派发方获取任务完成方的状态，以便决定继续向任务完成方派发任务或者暂停向任务完成方派发任务，满足了任务派发的实时性。

目标状态信息决定着派发方是否派发与目标对象标识对应的目标任务，并且目标状态信息与目标对象标识对应，具体的，目标状态信息可以是一个数字，也可以是一段字符串，还可以是一段文字，本示例性实施例对此不做特殊限定。

举例而言，若任务完成方中有医生A、医生B以及医生C。且医生A此时处于开诊状态，医生B此时处于闭诊状态，医生C此时处于开诊状态。若获取的是与医生A对应的目标对象标识，在任务派发方获取的目标状态信息就是开诊。

在可选的实施例中，查询与目标对象标识对应的目标状态信息，包括：获取状态信息列表，并从状态信息列表中查询与目标对象标识对应的目标状态信息。

状态信息列表在任务派发方中，且在状态信息列表中包含了所有任务完成方的状态信息。

举例而言，若任务完成方有3个医生，分别是医生A、医生B以及医生C。获取到的状态信息列表中包含了与医生A、医生B以及医生C分别对应的3个目标对象标识，分别是医生A的真实姓名张三，医生B的真实姓名李四，医生C的真实姓名刘一，除此之外，状态信息列表中还包含与张三对应的状态信息关诊，与李四对应的状态信息开诊，与刘一对应的状态信息开诊。

若获取的目标对象标识为张三，则从状态信息列表中查询到的目标状态信息为与张三对应的状态信息关诊。

在本公开的实施例中，在任务派发方查询目标对象标识对应的目标状态信息和对应的目标任务，有助于后续保证业务信息和任务派发结果的一致性。

在步骤S130中，依据业务信息在预设时长内对目标状态信息进行更改得到状态更改结果，并根据状态更改结果确定目标任务的派发结果。

在本公开的示例性实施例中，在预设时长内依据业务信息对获取的目标状态信息进行短暂的更改得到状态更改结果，并根据状态更改结果确定如何派发目标任务。

其中，预设时长可以是30s，也可以是10s，还可以是任意时间值，本示例性实施例对此不做特殊限定，并且预设时长的确定与完成任务方的需求有关。例如，若完成任务方为医生，且医生此时处于开诊状态，医生在开状态下可以接受的最长空闲时间为30s，此时预设时长就为30s。

举例而言，若完成任务方为医生A，且医生A发送的业务信息为与开诊对应的业务信息，预设时长设置为30s，则在30s的时长内将医生A对应的目标状态信息更改为开诊状态，此时存在更改成功和更改失败两种状态更改结果，若状态更改结果成功，此时医生A对应的目标状态信息为开诊，并且继续派发与医生A对应的目标任务；若状态更改结果失败，此时医生A对应的目标状态信息为关诊，停止派发与医生A对应的目标任务。

在可选的实施例中，图3示出了根据状态更改结果确定目标任务的派发结果的流程示意图，如图3所示，该方法至少包括以下步骤：在步骤S310中，判断在预设时长内是否接收到与状态更改结果对应的状态事件信息，以得到第一状态判断结果。

任务派发方将状态更改结果发送至任务完成方后，任务完成方根据状态更改结果对与目标对象标识对应的任务完成方的状态信息进行更改，若更改成功会生成对应的状态事件信息并将状态事件信息发送至任务派发方；若更改失败不会生成状态事件信息；若更改成功生成了状态事件信息，但由于网络故障等原因任务完成方可能无法将状态事件信息成功发送至任务派发方，在这种情况下也造成任务派发方在预设时长内无法接收到状态事件信息。

第一状态判断结果指的就是判断在预设时长内是否接收到状态事件信息的判断结果。

举例而言，预设时长为30s，判断在30s内任务派发方是否接收到状态事件信息，以得到第一状态判断结果。

在步骤S320中，根据第一状态判断结果确定目标任务的派发结果。

依据第一状态判断结果的内容确定目标任务的派发结果。

举例而言，第一状态判断结果包括两种可能情况，第一种情况是在预设时长内任务派发方接收到了状态事件信息，第二种是在预设时长内任务派发方未接受到状态事件信息，根据不同的第一状态判断结果可以得到目标任务的不同派发结果。

在可选的实施例中，根据第一状态判断结果确定目标任务的派发结果，包括：若第一状态判断结果为接收到状态事件信息，根据状态更改结果保持目标任务的派发结果。

若第一状态判断结果为接收到状态事件信息，确定的状态更改结果一定是与状态更改成功对应的状态更改结果。

举例而言，任务完成方为医生A，医生A发送的业务信息为与关诊对应的业务信息，预设时长为30s，在接收到关诊信息后，会先将业务信息发送至任务派发方，任务派发方会在预设时长内将与医生A对应的目标状态信息暂时更改为关诊，并且将状态更改结果发送至任务完成方，保证了任务派发方实时的根据业务信息更改与目标对象标识对应的目标状态信息，防止了在医生A发送关诊业务信息后，还向医生A进行任务派发的情况发生。

若状态更改结果为与成功对应的状态更改结果，任务完成方会将与医生A对应的状态信息更改为关诊状态，并且当任务完成方成功将与医生A对应的状态更改为关诊状态后，生成状态事件信息，并将状态事件信息发送至任务派发方，即任务派发方接收到状态事件信息时，一定是任务完成方对于与目标对象标识对应的目标状态信息进行了成功的更改。基于此，因为此时状态更改结果为关诊，所以对于目标任务的派发结果是与关诊对应的停止任务派发。

派发结果包括了对目标任务进行派发和对目标任务停止派发的两种派发结果。

举例而言，当接收到状态事件信息时状态更改结果一定是与成功对应的状态更改结果，基于此，若状态更改结果为在预设时长内将目标状态信息更改为了关诊，对应目标任务的派发结果为对任务进行派发。

若状态更改结果为在预设时长内将目标状态信息更改为了开诊，对应目标任务的派发结果为对任务进行派发。

在可选的实施例中，图4示出了根根据第一状态判断结果确定目标任务的派发结果的流程示意图，如图4所示，该方法至少包括以下步骤：在步骤S410中，若第一状态判断结果为未收到状态事件信息，在预设时长后接收与目标对象标识对应的当前状态信息。

当前状态信息指的是在预设时长后，在任务完成方中与目标对象标识对应的状态信息。

举例而言，任务完成方为医生A，若第一状态判断信息为未收到状态事件信息，可能存在三种情况，第一种情况是任务派发方在预设时长内对目标状态信息的更改不成功，进而不生成状态事件信息；第二种情况是任务派发方在预设时长内对目标状态信息的更改成功，但是任务完成方对于目标状态信息更改失败；第三种情况是任务派发方在预设时长内对目标状态信息的更改成功，但是由于故障或者网络问题，任务派发方未收到状态事件信息。

进一步的，在第一种情况下，因为在预设时长内没有将医生A对应的目标状态信息成功的更改为关诊，进而对应的当前状态为仍为开诊。

在第二种和三种情况下，在预设时长内对医生A对应的目标状态信息更改成功，但是任务完成方对目标状态信息的更改失败，导致与医生A对应的当前状态信息仍为开诊；若任务完成方对目标状态信息的更改成功，但由于故障或网络问题，任务派发方未收到状态事件信息，则与医生A对应的当前状态信息为关诊。

在步骤S420中，判断所述当前状态信息和所述状态更改结果得到第二状态判断结果。

其中，状态更改结果有两种情况，一种是任务派发方在预设时长内对目标状态信息进行了成功的更改，另一种是任务派发方在预设时长内对目标状态信息的更改失败。

具体的，在第一种情况中，可能存在的当前状态信息有两种，在第二种情况中，可能存在的当前状态信息有一种。

举例而言，若任务完成方为医生A，医生A发送的业务信息为关诊，且获取的状态更改结果为在预设时长内将目标状态信息更改为了关诊，但是任务完成方对目标状态信息的更改失败了，此时获取的当前状态信息为开诊，判断状态更改结果与当前状态信息开诊得到第二状态判断结果。

在步骤S430中，若第二状态判断结果为当前状态信息和状态更改结果一致，根据状态更改结果保持目标任务的派发结果。

若当前状态信息和状态更改结果一致，保持目标任务的派发结果与状态更改结果一致。

举例而言，若当前状态信息和状态更改结果一致，意味着是由于故障或网络问题导致的任务派发方未收到状态事件信息，并且，弱在预设时长内任务派发方已经将目标状态信息更改为了关诊状态，此时保持与关诊状态一致，对任务完成方不进行派发任务。

在步骤S440中，若第二状态判断结果为当前状态信息与状态更改结果不一致，根据状态更改结果更改目标任务的派发结果。

若当前状态信息和状态更改结果不一致，更改目标任务的派发结果。

举例而言，若当前状态信息和状态更改结果不一致，意味着在预设时长内对目标状态信息更改成功，但是任务完成方对目标状态信息的更改失败，导致与医生A对应的当前状态仍为开诊，或者是任务派发方在预设时长内没有将目标状态信息成功的更改为关诊，进而对应的当前状态仍为开诊。

在这两种情况下，当前状态信息与状态更改结果不一致，若当前状态信息为开诊，意味着任务派发方在预设时长内将目标状态信息更改为了关诊，此时任务派发方应该依据当前状态信息将开诊更改为关诊，对医生A不进行任务的派发；反之，若当前状态信息为关诊，此时任务派发方应该依据当前状态信息将关诊更改为开诊，对医生A进行任务的派发。

在可选的实施例中，图5示出了在预设时长后接收与目标对象标识对应的当前状态信息的流程示意图，如图5所示，该方法至少包括以下步骤：在步骤S510中，获取补偿信息，并确定与补偿信息对应的预设时长。

其中，补偿信息指的是根据目标对象标识生成的一条信息。

举例而言，任务完成方为医生，获取补偿信息，并确定与补偿信息对应的预设时长为30s。

在步骤S520中，在预设时长后接收与目标对象标识对应的当前状态信息。

当任务派发方在预设时长内未收到状态事件信息时，会从补偿信息中获取目标对象标识，并接收从任务完成方发送的与目标对象标识对应的当前状态信息。

在本公开的示例性实施例中，一方面，当接收到业务信息时，先对目标状态信息进行更改，再向下游通知业务信息的变更，满足了任务派发的实时性；另一方面，根据更改结果确定目标任务的派发结果，避免了由于网络异常导致的派发结果和业务信息不一致的情况发生，不仅优化了用户的体验，而且降低了派单结果的出错率。

下面结合一应用场景对本公开实施例中的事件数据的处理方法做出详细说明。

图6示出了在应用场景下任务派发的流程示意图，其中包括医生状态系统、派单系统以及补偿信息，对象610为医生状态系统中的医生张三，步骤S620为基本数据校验和业务逻辑校验过程，步骤S630为在派单系统中更改目标对象状态的过程，步骤S640为医生状态系统获取步骤S630中的更改结果，并根据不同的更改结果选择执行步骤的过程，S650为医生状态系统对目标对象状态进行更改的过程，步骤S660为根据步骤S650中不同的状态更改结果选择执行步骤的过程，步骤S670为判断是否存在状态事件信息的过程，步骤S680为从医生状态系统中获取与目标对象标识对应的当前状态信息的过程，步骤S690为确定任务派发结果的过程，信息600为补偿信息，661为执行步骤S640的执行结果，662为执行步骤S660的执行结果，691以及692为执行步骤S690的执行结果，663为状态事件信息。

具体的，当医生系统中的医生张三点击与关诊对应的控件时，医生系统会响应于医生张三的点击操作，获取与医生张三对应的业务信息，在步骤S620中，医生状态系统会对获取的业务信息进行基本数据校验和业务逻辑校验，其中，基本数据校验是判断业务信息的状态标识是否与预设状态标识一致，业务逻辑校验的过程是当收到的业务信息为与关诊对应的信息时，会自动忽略之后获取的与关诊对应的业务信息，避免由于医生的误操作而导致的多次响应，避免了不必要的性能损耗。

在步骤S630中，在预设时长内将医生张三的目标状态信息暂时更改为与业务信息对应的关诊，并获取与医生张三对应的目标任务。

在步骤S640中，当在预设时长内成功将医生张三的目标状态信息更改为关诊时，将执行步骤S650，在步骤S650中，在医生状态系统中更改医生张三的目标状态信息。

此时存在两种目标状态信息的更改结果，一个是在医生状态系统中将医生张三的目标状态系统更改成功即结果662，此时向医生张三发送一个提示信息，告知医生张三此时状态已经成功变更为关诊，并生成一个状态事件信息663。

另一个是在医生状态系统中医生张三的目标状态信息更改失败，此时会提醒医生张三此时状态变更失败即结果661，并且此时医生张三的当前状态信息为开诊。

当在预设时长内未将医生张三的目标状态信息更改为关诊时，将向医生张三发送提示信息，告知医生张三此时状态变更失败即结果661，并且此时医生张三的当前状态信息为开诊。

在上述情况中，只有在医生状态系统中将医生张三的目标状态信息更改成功，并且没有出现故障的情况下，任务派发系统才会收到状态事件信息。

在步骤S630中，派单系统判断是否接收到状态事件信息，若接收到状态事件信息，将继续保持在步骤S630中的状态更改结果，对目标任务不进行派单；若没有接收到状态事件信息，则从补偿信息600中获取目标对象标识，并执行步骤S680，从医生状态系统中获取与目标状态标识对应的当前状态信息，若此时获取的当前状态信息与步骤S630中的状态更改结果一致，都为关诊，则保持状态更改结果，得到结果691停止对目标任务的派发；若此时获取的当前状态信息与步骤S630中的状态更改结果不一致，状态更改结果为关诊，当前状态信息为开诊，则将状态更改结果从关诊更改为开诊得到结果692对目标任务进行派发。

在本应用场景中，一方面，当接收到业务信息时，先对目标状态信息进行更改，再向下游通知业务信息的变更，满足了任务派发的实时性；另一方面，根据更改结果确定目标任务的派发结果，避免了由于网络异常导致的派发结果和业务信息不一致的情况发生，不仅优化了用户的体验，而且降低了派单结果的出错率。

此外，在本公开的示例性实施例中，还提供一种任务派发装置。图7示出了任务派发装置的结构示意图，如图7所示，事件数据的处理装置700可以包括：获取模块710、查询模块720和派发模块730。其中：

获取模块710被配置为当接收到业务信息时，从所述业务信息中获取目标对象标识；查询模块720，被配置为查询与所述目标对象标识对应的目标状态信息，并获取与所述目标对象标识对应的目标任务；派发模块730，被配置为依据所述业务信息在预设时长内对所述目标状态信息进行更改得到状态更改结果，并根据所述状态更改结果确定所述目标任务的派发结果。

上述任务派发装置700的具体细节已经在对应的任务派发方法中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及任务派发装置700的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。

下面参照图8来描述根据本发明的这种实施例的电子设备800。图8显示的电子设备800仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图8所示，电子设备800以通用计算设备的形式表现。电子设备800的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830、显示单元840。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施例的步骤。

存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)821和/或高速缓存存储单元822，还可以进一步包括只读存储单元(ROM)823。

存储单元820还可以包括具有一组(至少一个)程序模块825的程序/使用工具824，这样的程序模块825包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包含网络环境的现实。

总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备800也可以与一个或多个外部设备870(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备800交互的设备通信，和/或与使得该电子设备800能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口850进行。并且，电子设备800还可以通过网络适配器860与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与电子设备800的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备800使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施例的描述，本领域的技术人员易于理解，这里描述的示例实施例可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施例的方法。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施例中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施例的步骤。

参考图9所示，描述了根据本发明的实施例的用于实现上述方法的程序产品900，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施例。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。

Claims (10)

1.一种任务派发方法，其特征在于，所述方法包括：

当接收到业务信息时，从所述业务信息中获取目标对象标识；

查询与所述目标对象标识对应的目标状态信息，并获取与所述目标对象标识对应的目标任务；

依据所述业务信息在预设时长内对所述目标状态信息进行更改得到状态更改结果，并根据所述状态更改结果确定所述目标任务的派发结果。

2.根据权利要求1所述的任务派发方法，其特征在于，所述从所述业务信息中获取目标对象标识，包括：

获取与所述业务信息对应的状态标识，并获取预设状态标识；

判断所述状态标识与所述预设状态标识是否一致得到标识判断结果；

若所述标识判断结果为所述状态标识与所述预设状态标识一致，从所述业务信息中获取目标对象标识。

3.根据权利要求1所述的任务派发方法，其特征在于，所述查询与所述目标对象标识对应的目标状态信息，包括：

获取状态信息列表，并从所述状态信息列表中查询与所述目标对象标识对应的目标状态信息。

4.根据权利要求1所述的任务派发方法，其特征在于，所述根据所述状态更改结果确定所述目标任务的派发结果，包括：

判断在所述预设时长内是否接收到与所述状态更改结果对应的状态事件信息，以得到第一状态判断结果；

根据所述第一状态判断结果确定所述目标任务的派发结果。

5.根据权利要求4所述的任务派发方法，其特征在于，所述根据所述第一状态判断结果确定所述目标任务的派发结果，包括：

若所述第一状态判断结果为接收到所述状态事件信息，根据所述状态更改结果保持所述目标任务的派发结果。

6.根据权利要求4所述的任务派发方法，其特征在于，所述根据所述第一状态判断结果确定所述目标任务的派发结果，包括：

若所述第一状态判断结果为未收到所述状态事件信息，在所述预设时长后接收与所述目标对象标识对应的当前状态信息；

判断所述当前状态信息和所述状态更改结果得到第二状态判断结果；

若所述第二状态判断结果为所述当前状态信息和所述状态更改结果一致，根据所述状态更改结果保持所述目标任务的派发结果；

若所述第二状态判断结果为所述当前状态信息与所述状态更改结果不一致，根据所述状态更改结果更改所述目标任务的派发结果。

7.根据权利要求6所述的任务派发方法，其特征在于，所述在所述预设时长后接收与所述目标对象标识对应的当前状态信息，包括：

获取补偿信息，并确定与所述补偿信息对应的预设时长；

在所述预设时长后接收与所述目标对象标识对应的当前状态信息。

8.一种派单处理装置，其特征在于，包括：

获取模块，被配置为当接收到业务信息时，从所述业务信息中获取目标对象标识；

查询模块，被配置为查询与所述目标对象标识对应的目标状态信息，并获取与所述目标对象标识对应的目标任务；

派发模块，被配置为依据所述业务信息在预设时长内对所述目标状态信息进行更改得到状态更改结果，并根据所述状态更改结果确定所述目标任务的派发结果。

9.一种电子设备，其特征在于，包括：

处理器；

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器被配置为经由执行所述可执行指令来执行权利要求1-7中的任意一项所述的任务派发方法。

10.一种计算机可读存储介质，其上存储计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-7中的任意一项所述的任务派发方法。

Images