CN106034137A - 用于分布式系统的智能调度方法及分布式服务系统 - Google Patents

Abstract

本申请公开了一种用于分布式系统的智能调度方法，包括：负责处理客户端异步请求的第一服务端，将接收到的异步请求的相关信息记录在共享存储中；当监控服务端监测到所述第一服务端停止服务时，由第二服务端执行下述操作：从所述共享存储中获取所述第一服务端尚未处理的异步请求信息；根据所述异步请求信息，执行相应的处理操作。本申请同时提供一种分布式服务系统。采用本申请提供的智能调度方法，能够有效解决服务停止场景下异步请求可能丢失的问题，保证业务执行的正确性；同时由于异步请求的处理在服务端得到了有效保障，客户端也无需等待超时并执行查询操作，其执行效率也能得到相应的提高。

Description

用于分布式系统的智能调度方法及分布式服务系统

技术领域

本申请涉及智能调度技术，具体涉及一种用于分布式系统的智能调度方法。本申请同时涉及一种分布式服务系统。

背景技术

在分布式系统中，通常以集群形式将多台服务器组织在一起，每台服务器包括一个或者一个以上服务端(也称为服务实例)，每个服务端根据接收到的来自客户端的请求，执行相应的处理动作。客户端和服务端之间的请求处理方式包括同步请求方式和异步请求方式。所谓同步请求方式是指，服务端接收到客户端的请求后处理所述请求，并在处理完毕后才向客户端返回应答；异步请求方式是指，服务端接收到客户端的请求后，立刻向客户端返回应答，之后才开始处理所述请求。

由此可见，对于需要消耗较多处理时间、资源的客户端请求，如果采用异步请求的方式来处理，可以解决客户端超时、服务端压力不均衡等问题，还能提高客户端的处理效率。

但是在服务端停止服务的情况下，如果采用同步请求方式，客户端可以相对容易的获知服务端状态，并采取路由策略重试，即可保证业务的正常执行；而对于异步请求方式，由于客户端提交请求的操作已经完成，当服务端停止服务时，客户端无法实时感知到服务端的当前状态，自然也不会主动尝试重试策略，从而导致正在处理的客户端请求可能被丢弃，无法保证请求得到有效的处理，业务的正确性也得不到有效保证。

针对异步请求方式存在的上述问题，现有技术通常采用以下两种解决方案：

(一)由客户端设置超时时间，超过超时时间后主动进行重试；

(二)服务端负责保存异步请求的相关信息，并在重启后重新处理。

上述两种解决方案，在特定业务场景是可以满足需求的，但是在普适场景就存在各自的缺陷。针对方案(一)，由于超时时间的设置是固定的，如果设置的过长，可能造成客户端长时间等待，影响客户端效率；如果设置的过短，可能服务端还没完成正常处理，因此客户端需要反复重试，依然影响效率。针对方案(二)，如果服务端由于设备故障等问题未能重启，那么该服务端尚未处理的异步请求依然会被丢弃。

发明内容

本申请提供一种用于分布式系统的智能调度方法，以解决服务端停止服务时尚未处理的异步请求可能会丢失、以及客户端无法进行有效处理的问题。本申请另外提供一种分布式服务系统。

本申请提供一种用于分布式系统的智能调度方法，包括：

负责处理客户端异步请求的第一服务端，将接收到的异步请求的相关信息记录在共享存储中；

当监控服务端监测到所述第一服务端停止服务时，由第二服务端执行下述操作：

从所述共享存储中获取所述第一服务端尚未处理的异步请求信息；

根据所述异步请求信息，执行相应的处理操作。

可选的，所述异步请求的相关信息包括：从客户端接收到的异步请求信息、和负责处理所述异步请求的第一服务端标识。

可选的，所述共享存储包括：分布式缓存、或者数据库。

可选的，所述监控服务端为注册中心服务器；

所述注册中心服务器监测到所述第一服务端停止服务时，首先执行下述操作：

按照预先设定的策略选择所述第二服务端；

向所述第二服务端推送执行重试操作的通知，所述通知中包含所述第一服务端标识。

可选的，所述注册中心服务器采用如下方式监测各服务端的状态：

通过监测心跳数据包的方式，监测各服务端的状态；或者，

通过监测长连接状态的方式，监测各服务端的状态。

可选的，所述注册中心服务器为zookeeper服务器。

可选的，所述监控服务端是按照预先设定的策略从负责处理客户端异步请求的服务端中指定的，所述第二服务端为所述监控服务端。

可选的，所述异步请求的相关信息还包括：负责处理所述异步请求的第一服务端的IP地址和网络端口标识；

所述监控服务端采用如下方式监测各服务端的状态：

根据共享存储中记录的信息，定期检查各服务端的网络端口状态。

可选的，在执行所述根据所述异步请求信息执行相应的处理操作的步骤后，执行下述操作：

从所述共享存储中删除所述异步请求信息。

相应的，本申请还提供一种分布式服务系统，包括：

服务单元，用于接收客户端的异步请求，将所述异步请求的相关信息记录在共享存储中，并执行相应的处理操作；

监控单元，用于监控各服务单元的工作状态；

重试单元，用于在所述监控单元监测到本系统中的服务单元停止服务时，从所述共享存储中获取所述停止服务的服务单元尚未处理的异步请求信息，并执行相应的处理操作。

可选的，所述系统中的服务单元部署于服务器，每个服务器包括至少一个服务单元。

可选的，所述服务单元记录的异步请求的相关信息包括：从客户端接收到的异步请求信息、和负责处理所述请求的服务单元标识。

可选的，所述共享存储包括：分布式缓存、或者数据库。

可选的，所述监控单元部署在注册中心服务器；

所述监控单元还用于在监测到本系统中的服务单元停止服务时，按照预先设定的策略从本系统中选择一个服务单元作为重试单元，并向所选重试单元推送执行重试操作的通知，所述通知中包含所述停止服务的服务单元标识。

可选的，所述监控单元具体用于，通过监测心跳数据包或者监测长连接状态的方式，监测各服务单元的状态。

可选的，所述注册中心服务器为zookeeper服务器。

可选的，所述分布式服务系统中至少一个服务单元包括所述监控单元；所述重试单元为包括所述监控单元的服务单元。

可选的，所述服务单元记录的异步请求的相关信息还包括：负责处理所述异步请求的服务单元的IP地址和网络端口标识；

所述监控单元具体用于根据共享存储中记录的信息，定期检查各服务单元的网络端口状态，从而获知各服务单元的工作状态。

可选的，所述重试单元还用于，在执行相应的处理操作后，从所述共享存储中删除所述异步请求信息。

与现有技术相比，本申请具有以下优点：

本申请提供的用于分布式系统的智能调度方法，由负责处理客户端异步请求的第一服务端，将接收到的异步请求的相关信息记录在共享存储中，当监控服务端监测到所述第一服务端停止服务时，由第二服务端从所述共享存储中获取所述第一服务端尚未处理的异步请求信息，并执行相应的处理操作。上述技术方案，提供了一种在分布式系统中针对异步请求的智能调度方法，充分地利用了分布式服务的集群优势，在监测到某一服务端停止服务时，由其他服务端接替其处理异步请求，从而有效解决了服务停止场景下异步请求可能丢失的问题，保证业务执行的正确性；同时由于异步请求的处理在服务端得到了有效保障，客户端也无需等待超时并执行查询操作，其执行效率也能得到相应的提高。

附图说明

图1是本申请的一种用于分布式系统的智能调度方法的第一实施例的流程图；

图2是本申请的一种用于分布式系统的智能调度方法的第二实施例的流程图；

图3是本申请的一种分布式服务系统的实施例的示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请中，分别提供了一种用于分布式系统的智能调度方法、以及一种分布式服务系统，在下面的实施例中逐一进行详细说明。

请参考图1，其为本申请的一种用于分布式系统的智能调度方法的实施例的流程图，在本实施例中，采用集中监控模式(也称中心服务推送模式)，由作为监控服务端的注册中心服务器负责监控系统内各服务端的工作状态，并在某服务端停止服务的情况下通知其他服务端接替其进行异步请求的处理。所述方法包括如下步骤：

步骤101：负责处理客户端异步请求的第一服务端，将接收到的异步请求的相关信息记录在共享存储中。

本实施例所述的服务端是指，根据接收到的客户端请求执行相应的处理、从而为客户端提供其所需服务的应用程序，也可以称作服务实例，例如提供数据库服务的服务实例、提供文件服务的服务实例、提供web服务的服务实例、以及其他基于业务定制的服务实例，都属于本实施例所述的服务端。在具体实施中，服务端通常在服务器上运行，一个服务器上可以运行一个或者一个以上的服务端。

在本实施例中，负责处理客户端异步请求的某服务端，即本实施例所述的第一服务端，在接收异步请求后，不仅按照常规的异步请求处理方式，向客户端返回异步请求接受完毕的应答，而且将所述异步请求的相关信息记录在共享存储中。

本实施例所述的异步请求的相关信息包括：从客户端接收到的异步请求信息、和负责处理所述异步请求的第一服务端的服务端标识。所述服务端标识是指，能够在分布式系统中区别各个服务端的标识信息，例如可以用“服务端名称+序列号”作为服务端标识，其中服务端名称可以是预先指定的，序列号则可以采用递增的自然数或者是启动时获取的随机数。在具体的实施中，也可以采用其他服务端标识形式，只要能够唯一的标识服务端即可。

本实施例所述的共享存储是指，分布式系统中各服务端都可以访问的共享数据存储空间，例如分布式缓存。分布式缓存可能在物理上分布于多个单独的物理设备中，但是却为使用缓存的各服务端提供了一个单一的高速缓存的逻辑视图，从而各服务端可以方便地访问同一个缓存并通过缓存实现数据共享。

此外，也可以采用数据库作为共享存储，例如采用基于key-value架构的数据库，可以将服务端标识作为key，将所述服务端负责处理的异步请求信息作为value存储在数据库中。

由于一个服务端可能在短时间内接收到多个待处理的异步请求，因此在共享存储中，与某一个服务端标识对应的异步请求信息可能有多条，也可以采用队列的方式存储与服务端标识对应的异步请求信息。上面给出了在共享存储中记录异步请求信息的几种方式，在具体实施中，也可以采用其他存储方式，只要能够满足分布式系统中各服务端的共享访问需求即可。

步骤102：注册中心服务器监测到所述第一服务端停止服务后，通知第二服务端。

在本实施例中，负责监控各服务端工作状态的任务由注册中心服务器实现，所述注册中心服务器是分布式系统中的一个集中管理者。分布式系统中每个服务端在启动时，可以向所述注册中心服务器进行注册，例如上报自己的标识、服务类型等信息，之后采用特定的机制与所述注册中心服务器保持联络，从而注册中心服务器能够监测各服务端的工作状态。

具体说，注册中心服务器可以采用心跳检查的方式监测各服务端的状态。各服务端在正常工作状态下，按照预先设定的间隔时间定期向所述注册中心服务器发送心跳数据包，注册中心服务器如果定期接收到所述心跳数据包，则认为对应的服务端处于提供服务的正常状态，如果在预先设定的一段时间内未接收到某服务端的心跳数据包，则认为该服务端处于停止服务的异常状态，例如，服务端因为软件故障无法提供服务，或者服务端所在设备宕机等。

此外，注册中心服务器也可以采用检查长连接状态的方式监测各服务端的状态。分布式系统中的各服务端可以在启动后，与所述注册中心服务器之间建立TCP长连接，并保持长连接状态。一旦注册中心服务器发现与某服务端之间的长连接断开了，例如注册中心服务器基于对应长连接发送的探测报文没有收到响应，则认为该服务端处于停止服务的异常状态。

在本实施例中，所述第一服务端在记录了接收到的异步请求的相关信息后，由于发生故障无法对外提供服务。这种情况下，注册中心服务器通过上述方式或者其他机制检测到所述第一服务端停止服务时，可以向分布式系统内的第二服务端(也称重试服务端)发送重试通知，所述第二服务端负责重新处理所述第一服务端尚未处理的异步请求。

在具体实施时，考虑到系统资源的优化利用，可以不在分布式系统内部设置专门的第二服务端，而是由注册中心服务器按照预先设定的策略，从负责处理客户端异步请求的服务端中选择一个作为所述第二服务端，并向所述第二服务端推送执行重试操作的通知。

所述预先设定的策略，可以采用round-robin策略，按照一定的顺序轮流从各服务端中选择一个作为所述第二服务端，也可以采用基于负载均衡的选择策略，从各个服务端中选择一个相对空闲的服务端作为所述第二服务端，还可以随机地从各个服务端中进行选择。

在向所述第二服务端推送执行重试操作的通知中，可以包含所述第一服务端标识，以便于所述第二服务端从共享存储中获取相应的需要执行重试操作的异步请求信息。

在具体实施中，可以采用zookeeper服务器作为所述注册中心服务器，负责管理分布式系统中的各服务端、监测各服务端的工作状态。

步骤103：所述第二服务端从所述共享存储中获取所述第一服务端尚未处理的异步请求信息。

所述第二服务端接收注册中心服务器推送的执行重试操作的通知后，可以从该通知中提取所述第一服务端的标识，然后根据该服务端标识从所述共享缓存中获取该服务端尚未处理的异步请求信息。

在具体实施中，根据所采用的共享缓存的不同，本步骤获取异步请求信息的方式也不同。例如，对于采用基于key-value架构的数据库作为共享存储的实施方式，则可以用所述第一服务端标识作为输入，通过get()或者类似的接口，从数据库中获取所述第一服务端尚未处理的异步请求信息。从共享存储中获取的对应于所述第一服务端标识的异步请求信息可以是一条或者是多条。

步骤104：所述第二服务端根据所述异步请求信息，执行相应的处理操作。

所述第二服务端获取了所述第一服务端尚未处理的异步请求信息后，根据所述异步请求信息中记录的请求内容，执行相应的处理操作，例如，执行数据库更新操作，或者是其他业务相关的操作。正常情况下，由接收该异步请求的第一服务端负责执行相应的处理操作，由于该服务端停止服务，而由注册中心服务器选择的第二服务端接替其执行相应的处理操作，可以认为是一个重新尝试的过程，因此该过程也被称为异步请求的重试过程。

如果在步骤103中获取了多条异步请求信息，那么在本步骤中可以逐一地执行相应的处理操作，从而保证每一个来自客户端的异步请求都得到有效的处理，而不会因为所述第一服务端停止服务，导致客户端异步请求被丢弃。

此外，所述第二服务端针对从共享存储中获取的异步请求信息，执行相应的处理操作后，为了避免重复处理，影响执行效率，该服务端可以从所述共享存储中删除所述异步请求信息。如果与所述第一服务端标识对应的异步请求信息有多条，则可以每处理完毕一条，从所述共享存储中删除一条，当与所述第一服务端标识对应的异步请求都处理完毕，则可以从共享存储中删除所述第一服务端标识。

至此，提供了用于分布式系统的智能调度方法的一个具体的实施例，在本实施例中由注册中心服务器实现对系统内部各服务端的集中管理与监控，并在监测到某服务端停止服务时，通知其他服务端重新执行未被处理的异步请求，从而保证了在服务端停止服务的情况下，异步请求依然能够得到有效的处理。

与上述的一种用于分布式系统的智能调度方法实施例相对应的，本申请还提供了所述方法的另一种实施例。请参考图2，其为本申请提供的一种用于分布式系统的智能调度方法的第二实施例的流程图，在本实施例中，采用分布式服务查询模式，由负责处理客户端异步请求的某一服务端作为监控服务端，定期检查各服务端的网络端口是否正常，并在监测到停止服务的情况时，自行执行重试操作。本实施例与上述第一实施例步骤相同的部分不再赘述，下面重点描述不同之处。

本申请提供的一种用于分布式系统的智能调度方法包括：

步骤201：负责处理客户端异步请求的第一服务端，将接收到的异步请求的相关信息记录在共享存储中。

本步骤与第一实施例步骤101基本相同，请参见第一实施例的相关描述。

需要说明的是，为了便于后续步骤202执行监控操作，本步骤写入共享存储的关于异步请求的相关信息还包括：负责处理所述异步请求的第一服务端的IP地址和网络端口标识，所述网络端口标识是指第一服务端对外提供服务的端口号。

步骤202：监控服务端监测服务端的工作状态，并在监测到所述第一服务端停止服务时，执行步骤203。

本实施例与第一实施例的不同之处在于，对各服务端工作状态进行监控所采用的方式不同，第一实施例采用集中管理模式，而本实施例采用分布式查询模式。由于未采用集中管理模式，因此本实施例可以不在分布式系统中设置集中的管理与监控中心，而是由负责处理客户端异步请求的服务端负责进行监控。

本实施例所述的监控服务端，可以是按照预先设定的策略从所述负责处理客户端异步请求的服务端中指定的。在具体实施时，可以预先设定由各服务端轮流承担所述监控任务，例如，8点至9点由1号服务端承担监控任务，9点至10点由2号服务端承担监控任务，10点至11点由3号服务端承担监控任务......依此类推，各服务端轮流充当监控服务端的角色。这里给出的只是一个具体的例子，在其他实施方式中，每个服务端承担监控任务的时间粒度可以根据需求进行调整，也可以采用其他策略进行指定，或者随机指定一个服务端同样可以实现本申请的技术方案。

负责执行监控任务的服务端，则可以按照一定的时间间隔定期从共享存储中获取当前提供服务的各服务端的网络信息，例如IP地址和端口号，并检查各服务端的网络端口是否正常。例如，定期根据各服务端的IP地址和端口号，向各服务端的端口发送测试报文，如果在预先设定的时间段内接收到某服务端的应答，则可以认为该服务端的网络端口处于正常状态，该服务端处于提供服务的正常状态；反之，如果在预先设定的时间段内没有接收到某服务端的应答，则可以认为该服务端的网络端口处于非正常状态，因此可以进一步认为该服务端处于停止服务的异常状态。

在本步骤中，如果监控服务端监测到所述第一服务端停止服务，则执行后续的步骤203和204进行相应的重试操作。

步骤203：所述监控服务端从所述共享存储中获取所述第一服务端尚未处理的异步请求信息。

由于本实施例中由负责处理异步请求的服务端承担监控任务，即：监控服务端本身具备处理异步请求的能力，因此本实施例中不需要再指派或者通知其他服务端执行重试操作，而是由监控服务端自己完成所述重试操作。

在本步骤中，所述监控服务端从所述共享缓存中获取需要执行重试操作的异步请求信息，其处理过程与第一实施例中的步骤103基本相同，请参见第一实施例的相关描述。

步骤204：所述监控服务端根据所述异步请求的相关信息，执行相应的处理操作。

本步骤与第一实施例的步骤104的处理过程基本相同，请参见第一实施例的相关描述。

上述步骤201至步骤204，提供了用于分布式系统的智能调度方法的另一个具体的实施例，在本实施例中由负责处理客户端异步请求的服务端承担监控任务，采用分布式服务查询模式监测系统内各服务端的状态，并在监测到某服务端停止服务时，重新执行未被处理的异步请求，从而保证了在服务端停止服务的情况下，异步请求依然能够得到有效的处理。

需要说明的是，本申请提供的智能调度方法，通常应用于分布式系统中。分布式系统通常是指由多个计算机或者服务器通过网络互联组成的系统，而本申请所述的分布式系统则是一个相对宽泛的概念，如果一个系统包括了两个或者两个以上为客户端提供服务的服务端，所述服务端可以在同一台物理设备上(例如同一台服务器上)，也可以分布在不同的物理设备上，只要所述服务端能够在整个系统的控制下协同地为客户端透明地提供服务，这些服务端就组成了本申请所述的分布式系统，而与其在物理设备上的具体分布情况无关。

综上所述，本申请的技术方案，提供了一种在分布式系统中针对异步请求的智能调度方法，充分地利用了分布式服务的集群优势，在通过集中监控模式或者分布式服务查询模式等方式，监测到某一服务端停止服务时，由其他服务端接替其处理异步请求，从而有效解决了服务停止场景下异步请求可能丢失的问题，保证业务执行的正确性；同时由于异步请求的处理在服务端得到了有效保障，客户端也无需等待超时并执行查询操作，其执行效率也能得到相应的提高。

在上述的实施例中，提供了一种用于分布式系统的智能调度方法，与之相对应的，本申请还提供一种分布式服务系统。请参看图3，其为本申请的一种分布式服务系统的实施例示意图。该系统包括：服务单元301，用于接收客户端的异步请求，将所述异步请求的相关信息记录在共享存储中，并执行相应的处理操作；监控单元302，用于监控各服务单元的工作状态；重试单元303，用于在所述监控单元监测到本系统中的服务单元停止服务时，从所述共享存储中获取所述停止服务的服务单元尚未处理的异步请求信息，并执行相应的处理操作。

在具体实施时，所述服务单元可以部署于服务器，每个服务器包括至少一个服务单元。服务单元将来自客户端的异步请求的相关信息，包括从客户端接收到的异步请求信息、和负责处理所述请求的服务单元标识，记录在共享存储中，所述共享存储包括：分布式缓存或者数据库。

在具体实施本系统时，可以采用集中监控模式。所述监控单元可以部署在注册中心服务器，例如zookeeper服务器。所述监控单元通过监测心跳数据包或者监测长连接状态的方式，监测各服务单元的状态，并在监测到某服务单元停止服务时，按照预先设定的策略从所述分布式服务系统中选择一个服务单元作为重试单元，并向所选重试单元推送执行重试操作的通知，所述通知中可以包含所述停止服务的服务单元标识。所述重试单元接收到上述通知后，从共享存储中获取停止服务的服务单元尚未处理的异步请求信息，执行相应的处理操作，并在处理完毕后从所述共享存储中删除所述异步请求信息。

在具体实施本系统时，也可以采用分布式服务查询模式。所述分布式服务系统中至少一个服务单元包括所述监控单元，所述重试单元为包括所述监控单元的服务单元，也就是说由服务单元承担监控任务和重试任务。在本实施方式下，所述服务单元记录的异步请求的相关信息还包括：负责处理所述异步请求的服务单元的IP地址和网络端口标识。承担监控任务的服务单元根据共享存储中记录的信息，定期检查各服务单元的网络端口状态，从而获知各服务单元的工作状态，并在监测到某服务单元停止服务的情况下，直接执行重试操作：从共享存储中获取停止服务的服务单元尚未处理的异步请求信息，执行相应的处理操作，并在处理完毕后从所述共享存储中删除所述异步请求信息。

上面对本实施例提供的分布式服务系统进行了描述，并给出了基于集中监控模式和分布式服务查询模式的两种具体实施方式。在其他分布式服务系统中，其实施方式可能不同于上述描述，但只要能够在监测到服务停止情况时，通过系统内部的智能调度方式由其他服务单元执行重试操作，处理所述停止服务的服务单元未处理的异步请求，就不偏离本系统的核心，依然在本系统的保护范围之内。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

Claims (19)

1.一种用于分布式系统的智能调度方法，其特征在于，包括：

负责处理客户端异步请求的第一服务端，将接收到的异步请求的相关信息记录在共享存储中；

当监控服务端监测到所述第一服务端停止服务时，由第二服务端执行下述操作：

从所述共享存储中获取所述第一服务端尚未处理的异步请求信息；

根据所述异步请求信息，执行相应的处理操作。

2.根据权利要求1所述的用于分布式系统的智能调度方法，其特征在于，所述异步请求的相关信息包括：从客户端接收到的异步请求信息、和负责处理所述异步请求的第一服务端标识。

3.根据权利要求1所述的用于分布式系统的智能调度方法，其特征在于，所述共享存储包括：分布式缓存、或者数据库。

4.根据权利要求2所述的用于分布式系统的智能调度方法，其特征在于，所述监控服务端为注册中心服务器；

所述注册中心服务器监测到所述第一服务端停止服务时，首先执行下述操作：

按照预先设定的策略选择所述第二服务端；

向所述第二服务端推送执行重试操作的通知，所述通知中包含所述第一服务端标识。

5.根据权利要求4所述的用于分布式系统的智能调度方法，其特征在于，所述注册中心服务器采用如下方式监测各服务端的状态：

通过监测心跳数据包的方式，监测各服务端的状态；或者，

通过监测长连接状态的方式，监测各服务端的状态。

6.根据权利要求4所述的用于分布式系统的智能调度方法，其特征在于，所述注册中心服务器为zookeeper服务器。

7.根据权利要求2所述的用于分布式系统的智能调度方法，其特征在于，所述监控服务端是按照预先设定的策略从负责处理客户端异步请求的服务端中指定的，所述第二服务端为所述监控服务端。

8.根据权利要求7所述的用于分布式系统的智能调度方法，其特征在于，所述异步请求的相关信息还包括：负责处理所述异步请求的第一服务端的IP地址和网络端口标识；

所述监控服务端采用如下方式监测各服务端的状态：

根据共享存储中记录的信息，定期检查各服务端的网络端口状态。

9.根据权利要求1-8任一所述的用于分布式系统的智能调度方法，其特征在于，在执行所述根据所述异步请求信息执行相应的处理操作的步骤后，执行下述操作：

从所述共享存储中删除所述异步请求信息。

10.一种分布式服务系统，其特征在于，包括：

服务单元，用于接收客户端的异步请求，将所述异步请求的相关信息记录在共享存储中，并执行相应的处理操作；

监控单元，用于监控各服务单元的工作状态；

重试单元，用于在所述监控单元监测到本系统中的服务单元停止服务时，从所述共享存储中获取所述停止服务的服务单元尚未处理的异步请求信息，并执行相应的处理操作。

11.根据权利要求10所述的分布式服务系统，其特征在于，所述系统中的服务单元部署于服务器，每个服务器包括至少一个服务单元。

12.根据权利要求11所述的分布式服务系统，其特征在于，所述服务单元记录的异步请求的相关信息包括：从客户端接收到的异步请求信息、和负责处理所述请求的服务单元标识。

13.根据权利要求11所述的分布式服务系统，其特征在于，所述共享存储包括：分布式缓存、或者数据库。

14.根据权利要求12所述的分布式服务系统，其特征在于，所述监控单元部署在注册中心服务器；

所述监控单元还用于在监测到本系统中的服务单元停止服务时，按照预先设定的策略从本系统中选择一个服务单元作为重试单元，并向所选重试单元推送执行重试操作的通知，所述通知中包含所述停止服务的服务单元标识。

15.根据权利要求14所述的分布式服务系统，其特征在于，所述监控单元具体用于，通过监测心跳数据包或者监测长连接状态的方式，监测各服务单元的状态。

16.根据权利要求14所述的分布式服务系统，其特征在于，所述注册中心服务器为zookeeper服务器。

17.根据权利要求12所述的分布式服务系统，其特征在于，所述分布式服务系统中至少一个服务单元包括所述监控单元；所述重试单元为包括所述监控单元的服务单元。

18.根据权利要求17所述的分布式服务系统，其特征在于，所述服务单元记录的异步请求的相关信息还包括：负责处理所述异步请求的服务单元的IP地址和网络端口标识；

所述监控单元具体用于根据共享存储中记录的信息，定期检查各服务单元的网络端口状态，从而获知各服务单元的工作状态。

19.根据权利要求10-18任一所述的分布式服务系统，其特征在于，所述重试单元还用于，在执行相应的处理操作后，从所述共享存储中删除所述异步请求信息。