一种云系统消息分发方法，装置和系统与流程

本发明实施例涉及云计算领域，尤其涉及一种云系统消息分发方法，装置和系统。
背景技术：
：云环境中，系统设计的最基本原则之一是水平扩展，即通过增加集群节点来提高系统处理能力，因此，负荷分担集群、分布式集群在云系统中应用越来越广泛。在负荷分担集群中，后端多台服务器(Server)组成业务处理集群，任一服务器节点可单独处理客户端(Client)的消息，Client通过负载均衡器(Loadbalancer)访问Server，Loadbalancer按照配置的负载均衡算法把Client的消息分发给Server。分布式集群与负荷分担集群的主要区别是Client的消息一般由多台Server协同处理。客户端代理(ClientAgent)作为协调者，把Client消息划分为多个子消息，再分发给多个Server处理，并把多个Server的处理结果合并后返回Client。ClientAgent可按负载均衡算法选举合适的Server。在负载均衡算法中，负载评估只考虑Server负载，即假设所有消息的处理成本是相同的，无法保证消息处理成本差异较大场景下的负载均衡，且长期运行后，由于Server运行环境变化，导致该Server处理特定消息失败时，负载均衡算法无法有效隔离，导致集群处理消息成功率下降。为了解决消息间处理成本差异较大场景下的故障快速隔离，现有技术在Server端增加反馈机制，Server接收到的Loadbalancer或ClientAgent发送的消息中携带deadline字段，deadline用于指示需要完成消息处理的时间，Server接收到消息后，先评估能否满足deadline，如满足，则继续处理，否则直接回应答通知Loadbalancer或ClientAgent不能满足deadline需求，Loadbalancer或ClientAgent重新选择其他Server处理。随着消息处理复杂度增加，Server端很难准确评估能否满足deadline要求，漏判误判风险高，而且网络交互和Server端评估会带来较大的开销。技术实现要素：有鉴于此，本发明实施例公开了一种云系统消息分发方法，装置和系统。第一方面，本申请提供了一种云系统分发方法，云系统包括客户端(Client)，分发装置和多个服务器(Server)节点，该方法包括：分发装置将M个消息发送给第一服务器处理，并根据第一服务器的处理情况确定该M个消息中服务质量(QoS，QualityOfService)差的N个消息，分发装置提取该N个消息的共同消息特征，并记录该共同消息特征与第一服务器的对应关系，该对应关系用于指示第一服务器处理具有该共同消息特征的消息的QoS差。其中，M为大于1的正整数，N为不大于M的正整数。分发装置通过实际统计，识别出服务器不适合处理的消息的共同消息特征，并记录服务器与消息特征之间的对应关系，后续在进行消息分发时，可以主动的避开不适合的服务器，避免了某个Server由于软件老化(如内存碎片)无法处理特定消息(如消息大小超过特定值)，从而引起的处理失败或处理时间长或某个Server由于运行环境变化触发软件错误，从而处理特定消息(读损坏的文件)时进程异常退出等情况，提高了系统处理性能和成功率。根据第一方面，在第一方面第一种可能的实现方式中，分发装置根据消息处理时间确定QoS差的消息。分发装置确定该M个消息中QoS差的N个消息可以为：分发装置确定处理时间大于预设时间阈值的N个消息，并将该N个消息作为QoS差的消息。分发装置将M个消息发送给第一服务器处理后，会监控第一服务器处理该M个消息中每个消息的处理时间。如果第一服务器对一个消息的处理时间大于预设时间阈值，或在预设时间阈值到达时还没有收到该消息的应答消息，则分发装置记录该消息。根据第一方面，在第一方面第二种可能的实现方式中，分发装置根据M个消息中的每个消息的响应消息，确定服务质量差的N个消息，其中，N个消息中的每个消息的响应消息中携带特征码，该特征码用于指示第一服务器处理该消息的服务质量差。进一步的，响应消息中还可以携带QoS类型，例如，可以使用0表示禁止，1表示响应时延长，2表示资源不足，3表示处理失败等。根据第一方面或第一方面以上任一种可能的实现方式，在第一方面第三种可能的实现方式中，分发装置记录共同消息特征与第一服务器的对应关系之后，该方法还包括：分发装置接收来自客户端的待分发消息，待分发消息具有该共同消息特征，分发装置根据记录的对应关系和该共同消息特征确定第一服务器，并在第一服务器外的其他服务器中选择第二服务器，并将待分发消息分发给第二服务器处理。分发装置可以直接将待分发消息发送给第二服务器处理，也可以将待分发消息拆分为多个子消息，然后将其中的一个子消息发送给第二服务器处理。通过分发装置记录的对应关系，在为待访问消息选择目标服务器时，可以避开不适合的服务器，从而保证了处理成功率和效率。根据第一方面第三种可能的实现方式，在第一方面第四种可能的实现方式中，分发装置在第一服务器外的服务器中选择第二服务器为：分发装置根据预设分发算法为待分发消息选择预分配服务器，如果预分配服务器为第一服务器，则分发装置为待分发消息选择第二服务器，第二服务器为第一服务器的从节点。分布式集群中，为保证可靠性，1个子消息一般至少有2个服务器可以处理，如果目标服务器是QoS差的服务器，则可以选择目标服务器的从服务器处理待分发消息。如果目标服务器没有从服务器或者目标服务器的从服务器也是QoS差的服务器，则可以将待分发消息发送给目标服务器处理或者直接给客户端发送处理失败的指示消息。根据第一方面或第一方面以上任一种可能的实现方式，在第一方面第五种可能的实现方式中，分发装置记录共同消息特征与第一服务器的对应关系之后，该方法还包括：分发装置接收来自客户端的待分发消息，待分发消息具有该共同消息特征，分发装置根据记录的对应关系和该共同消息特征确定第一服务器，调低第一服务器的权重，并使用动态分配算法为待分发消息选择服务器。如果预设算法为动态分发算法，为了降低选择QoS差的服务器的概率，分发装置调低QoS差的服务器的权重，然后使用动态分发算法选择目标服务器。更具体的，分发装置可以将QoS差的服务器的权重调整为0，以避免选择QoS差的服务器。第二方面，本申请提供了一种可读介质，包括执行指令，当计算设备的处理器执行该执行指令时，该计算设备执行以上第一方面或以上第一方面的任一种可能的实现方式中的方法。第三方面，本申请提供了一种计算设备，包括：处理器、存储器和总线；存储器用于存储执行指令，处理器与存储器通过总线连接，当计算设备运行时，处理器执行存储器存储的执行指令，以使计算设备执行以上第一方面或以上第一方面的任一种可能的实现方式中的方法。第四方面，本申请提供一种云系统消息分发装置，云系统包括客户端，该分发装置和多个服务器，该分发装置包括：分发单元，用于将M个消息发送给第一服务器处理，其中，M为大于1的正整数；确定单元，用于根据第一服务器的处理情况确定该M个消息中服务质量差的N个消息，其中，N为不大于M的正整数；记录单元，用于提取该N个消息的共同消息特征，并记录共同消息特征与第一服务器的对应关系该对应关系用于指示第一服务器处理具有该共同消息特征的消息的QoS差。根据第四方面，在第四方面第一种可能的实现方式中，确定单元用于根据消息处理时间确定QoS差的消息。确定单元用于确定处理时间大于预设时间阈值的N个消息，并将该N个消息作为QoS差的消息。根据第四方面，在第四方面第二种可能的实现方式中，确定单元用于根据M个消息中的每个消息的响应消息确定M个消息中服务质量差的N个消息，其中，N个消息中的每个消息的响应消息中携带特征码，该特征码用于指示第一服务器处理该消息的服务质量差。根据第四方面或第四方面以上任一种可能的实现方式，在第四方面第二种可能的实现方式中，该分发装置还包括接收单元，用于接收来自客户端的待分发消息，待分发消息具有共同消息特征，分发单元还用于根据记录单元记录的对应关系和该共同消息特征确定第一服务器，并在第一服务器外的服务器中选择第二服务器，并将待分发消息分发给第二服务器处理。根据第四方面第三种可能的实现方式，在第四方面第四种可能的实现方式中，分发单元用于根据预设分发算法为待分发消息选择预分配服务器，如果预分配服务器为第一服务器，则为待分发消息选择第二服务器，第二服务器为第一服务器的从节点。根据第四方面或第四方面以上任一种可能的实现方式，在第四方面第五种可能的实现方式中，该分发装置还包括接收单元，用于接收来自客户端的待分发消息，待分发消息具有共同消息特征，分发单元还用于根据记录单元记录的对应关系该共同消息特征确定第一服务器，调低第一服务器的权重，并使用动态分配算法为待分发消息选择服务器。第四方面为第一方面方法对应的装置实现方式，第一方面或第一方面任一种可能的实现方式中的描述对应适用于第四方面或第四方面任一种可能的实现方式，在此不再赘述。第五方面，本申请提供了一种分发系统，该系统包括客户端，第四方面或第四方面以上任一种可能的实现方式中的分发装置和多个服务器，该分发装置用于将客户端的消息分发给多个服务器处理。第五方面为第一方面方法对应的系统实现方式，第一方面或第一方面任一种可能的实现方式中的描述对应适用于第五方面或第五方面任一种可能的实现方式，在此不再赘述。根据本申请公开的技术方案，分发装置通过对已分发消息的服务质量的监控，识别出分发给某一服务器的消息中服务质量差的消息，例如，在消息处理成本差异较大场景下，大规模集群长时间运行后，某个服务器由于软件老化(如内存碎片)无法处理特定消息(如消息大小超过特定值)，而导致处理失败或处理时间长，或者某个服务器由于运行环境变化触发软件错误，而导致处理特定消息(读损坏的文件)时进程异常退出。分发装置提取服务质量差的消息的共同消息特征，将此类消息特征和服务器的映射关系加入黑名单，后续尽量不再分发此类消息给该服务器或保证不再分发此类消息给该服务器，从而提高了系统处理性能和成功率，避免了服务器的反复故障。附图说明下面将对实施例描述中所需要使用的附图作简单地介绍。图1为依据本发明一实施例的云系统的逻辑结构示意图；图2为依据本发明一实施例的云系统的逻辑结构示意图；图3为依据本发明一实施例的分发装置的硬件结构示意图；图4为依据本发明一实施例的分发方法的示范性流程图；图5为依据本发明一实施例的分发方法的示范性流程图；图6为依据本发明一实施例的分发装置的逻辑结构示意图；图7为依据本发明一实施例的分发装置的逻辑结构示意图。具体实施方式下面结合附图，对本发明的实施例进行描述。在云环境下，某个服务器可能因为节点故障或性能老化等原因，不适合处理特定消息类型的消息，否则可能会因为单点的性能下降，影响系统整体性能。为了实现特定消息类型对特定服务器的有效隔离，本发明实施例中，分发装置实际监控分发给某一服务器的消息的服务质量(QoS，QualityOfService)，并记录QoS差的消息，例如，处理时间均超过了预设的阈值(在预设的时间阈值内服务器没有向分发装置返回处理结果)，或消息的响应消息中携带了指示QoS差的特征码，则分发装置会提取QoS的消息的共同消息特征，并在黑名单中记录提取的共同消息特征与该服务器的对应关系，后续数据分发装置在接收到新的消息时，会根据消息特征，过滤掉在黑名单中与该消息特征对应的服务器，并在剩余的服务器中为该消息选择合适的处理器节点。从而提高了系统处理性能和成功率，避免了服务器的反复故障。本发明实施例通过监控服务器对消息的实际处理情况，实现了特定消息特征对特定服务器的隔离。图1为一种云系统100的逻辑结构示意图，云系统100包括多个客户端102，分发装置104和多个服务器节点110。分发装置104用于从客户端102接收请求消息，并将客户端102的请求消息分发给服务器节点110处理。其中，分发装置104维护有服务器列表106和黑名单108。服务器列表106用于记录分发装置104可选的服务器节点110。黑名单108用于记录服务器节点110与消息特征之间的对应关系，消息特征对应的服务器节点110对具有该消息特征的消息处理能力差，即服务器节点110对具有该消息特征的消息的服务质量差，分发装置104接收到具有该消息特征的消息后，会避免或尽量避免将具有该消息特征的消息分发给该消息特征对应的服务器节点110处理，从而保证消息的处理速度。在分布式集群中，分发装置104可以采用分布式的解决方案，如图2所示，系统100中可以包含多个分发装置104，多个分发装置104可以按照需求部署在系统的不同位置。每一个分发装置104可以连接部分或全部客户端102，并连接部分或者全部服务器节点110，本发明实施例对此并不进行限定。在负载分担集群中，后端多台服务器节点110组成业务处理集群，任一服务器节点110可单独处理客户端102的消息，分发装置104接收到客户端102发送的一个消息后，根据服务器列表106和黑名单108从多个服务器中为该消息选择一个合适的服务器节点110，并将该消息发送给选择的服务器节点110处理。分发装置104可以根据黑名单108排除不合适的服务器，并采用负载均衡算法为消息在合适的服务器节点110中选择服务器节点110，该负载均衡算法包括但不限于：随机、轮询、加权轮询、动态轮询、最快算法、最少连接、观察算法、预判算法等。其中，随机算法把负载分配到各个可用的服务器上，通过随机数生成算法选取一个服务器，然后把消息发送给它。轮询算法按顺序把每个新的消息分配给下一个服务器，最终把所有消息平分给所有的服务器。加权轮询算法中，每个服务器接受的消息数量是按权重比例分配的，这是对普通轮询算法的改进，例如，可以设定第三台机器的处理能力是第一台机器的两倍，那么负载均衡器会把两倍的消息数量分配给第3台机器。动态轮询算法类似于加权轮询，但权重值可以基于对各个服务器的监控，不断更新，可以基于服务器的实时性能分析分配消息，例如，根据每个服务器的当前消息数或者响应时间等分配消息。最快算法基于所有服务器中的最快响应时间分配消息。最少连接算法把新消息给当前连接数目最少的服务器。观察算法结合最小连接算法和最快算法来实施负载均衡，服务器根据当前的连接数和响应时间得到一个性能评估，性能评估越高，代表性能越好，会得到更多的连接。预判算法使用观察算法来进行性能评估，但是预判算法会通过分析性能的变化趋势来判断某台服务器的性能正在改善还是降低。具有改善趋势的服务器会得到更多的连接。在分布式集群中，客户端102的消息一般由多台服务器节点110协同处理。分发装置104作为协调者，接收到客户端102发送的一个消息后，将消息分解为多个子消息，并根据服务器列表106和黑名单108为该多个子消息选择多个服务器节点110，并将该多个子消息发送给选择的多个服务器节点110处理，然后把多个服务器节点110的处理结果合并后返回给客户端102。如图2所示，在分布式集群中，分发装置104采用分布式布局方式，每一个分发装置104在接收到客户端102的消息后，会将消息拆分成多个子消息，并根据服务器列表106和黑名单108将子消息分发给多个服务器。具体的，分发装置104使用消息分发算法将子消息分发给多个服务器。其中，消息分发算法包括但不限于静态路由算法、哈希(Hash)算法和一致性Hash算法。静态路由中，分发装置104根据配置的路由表，把子消息分发给指定的服务器节点110。Hash算法中，分发装置104根据消息中特定字段的Hash值选择服务器，如先计算子消息中键(Key)字段的Hash值，再用Hash值除以服务器总数，取余数作为选择的服务器的编号。在一致性Hash算法中，每个节点都有随机分配的编号(ID)。分发装置104使用内容的关键字和节点的ID进行一致性哈希运算并获得键值，一致性哈希要求键值和节点ID处于同一值域。分布式集群中，为保证可靠性，1个子消息至少有2个服务器108可以处理，分发装置104选择时，可结合黑名单108按上述负载均衡算法选举。本领域的技术人员应当明白，根据具体需要，系统100还可包含实现其他附加功能的硬件器件。此外，本领域的技术人员应当明白，系统100也可仅仅包含实现本发明实施例所必须的器件，而不必包含图1或图2中所示的全部器件。图3为依据本发明一实施例的分发装置104的硬件结构示意图，如图3所示，分发装置104包括:包括处理器302、存储器304、输入/输出接口306、通信接口308和总线310。其中，处理器302、存储器304、输入/输出接口306和通信接口308通过总线310实现彼此之间的通信连接。处理器302是分发装置104的控制中心，用于执行相关程序，以实现本发明实施例所提供的技术方案。处理器302可以采用通用的中央处理器(CentralProcessingUnit，CPU)，微处理器，应用专用集成电路(ApplicationSpecificIntegratedCircuit，ASIC)，或者一个或多个集成电路，用于执行相关程序，以实现本发明实施例所提供的技术方案。存储器304可以是只读存储器(ReadOnlyMemory，ROM)，静态存储设备，动态存储设备或者随机存取存储器(RandomAccessMemory，RAM)。存储器304可以存储操作系统和其他应用程序。在通过软件或者固件来实现本发明实施例提供的技术方案时，用于实现本发明实施例提供的技术方案的程序代码保存在存储器304中，并由处理器302来执行。存储器304可以与处理器302集成在一起或集成在处理器302的内部，也可以是独立于处理器302的一个或多个存储单元。供处理器302执行的程序代码可以存储在与其连接的外部存储设备中或存储器304中。可选的，存储器304为RAM，存储在外部存储设备内部的程序代码(例如，通信模块和分发控制模块等)被拷贝到存储器304中，以供处理器302执行。如图3所示，分发装置104的存储器304中包含通信模块和分发控制模块。处理器302执行分发控制模块代码，实现对接收到的消息的分发。除非另有说明，在本发明中，一个用于执行特定功能的组件，例如，处理器302或存储器304，可以通过配置一个通用的组件来执行相应功能来实现，也可以通过一个专门执行特定功能的专用组件来实现，本申请并不对此进行限定。输入/输出接口306用于接收输入的数据和信息，输出操作结果等数据。通信接口308使用例如但不限于收发器一类的收发装置，来实现分发装置104与其他设备或通信网络之间的通信。总线310可包括一通路，在分发装置104各个部件(例如处理器302、存储器304、输入/输出接口306和通信接口308)之间传送信息。应注意，尽管图3所示的计分发装置104仅仅示出了处理器302、存储器304、输入/输出接口306、通信接口308以及总线310，但是在具体实现过程中，本领域的技术人员应当明白，分发装置104还包含实现正常运行所必须的其他器件。同时，根据具体需要，本领域的技术人员应当明白，分发装置104还可包含实现其他附加功能的硬件器件。此外，本领域的技术人员应当明白，分发装置104也可仅仅包含实现本发明实施例所必须的器件，而不必包含图3中所示的全部器件。图3所示的硬件结构以及上述描述适用于本发明实施例所提供的各种消息分发装置，适用于执行本发明实施例所提供的各种消息分发方法。图4为依据本发明一实施例的一种云系统消息分发方法400的示意性流程图，云系统包括客户端，分发装置和多个服务器，如图4所示，方法400包括：S402：分发装置将M个消息发送给第一服务器处理。其中，M为大于1的正整数。分发装置在接收到客户端的的请求消息后，根据分发算法将M个消息分发给第一服务器。分发装置分发给第一服务器的消息可以是从客户端接收到的请求消息或者该请求消息的子消息，本发明实施例对此并不进行限定。例如，在分布式集群中，分发装置一般将从客户端接收到的请求消息拆分为多个子消息，并将每一个子消息分发给一个服务器处理，而在负荷分担集群中，分发装置一般将从客户端接收到的请求消息直接分发给一个服务器处理。S404：分发装置确定该M个消息中服务质量(QoS，QualityOfService)差的N个消息。其中，N为大于0，不大于M的正整数。分发装置可以根据该M个消息中的每个消息的响应消息，确定服务质量差的N个消息，其中，该N个消息中的每个消息的响应消息中携带特征码，该特征码用于指示该消息的服务质量差。进一步的，响应消息中还携带QoS类型，例如，可以使用0表示禁止，1表示响应时延长，2表示资源不足，3表示处理失败等。分发装置还可以根据消息处理时间确定QoS差的消息。分发装置确定该M个消息中QoS差的N个消息可以为：分发装置确定处理时间大于预设时间阈值的N个消息，并将该N个消息作为QoS差的消息。分发装置将M个消息发送给第一服务器处理后，会监控第一服务器处理该M个消息中每个消息的处理时间。如果第一服务器对一个消息的处理时间大于预设时间阈值，则分发装置记录该消息。其中，每个消息可以分别有一个预设时间阈值，该M个消息或部分消息也可以有共同的预设时间阈值，本发明实施例对此并不进行限定。如果分发装置将一个消息发送给第一服务器后，在该消息对应的预设时间阈值内，没有收到该消息的应答消息，则说明该消息的处理时间大于预设时间阈值。第一服务器对一个消息的处理时间可以为分发装置将该消息发送给第一服务器的时刻到分发装置接收到该消息的应答消息之间的时间。应理解，第一服务器处理对一个消息的处理时间可以有多种统计形式，本发明实施例对此并不进行限定。S406：分发装置提取该N个消息的共同消息特征，并记录该共同消息特征与第一服务器的对应关系。该共同消息特征可以为文件名(FileName)、数据大小(DataSize)、键(DataKey，即Key-Value中的Key)、分区ID(PartitionID)、卷ID(VolumeID)、客户标识(ClientFlag)、消息ID(MsgID)、业务类型(ServiceType)、用户标识(UserID)、消息类型(ReqID)等中的一种或多种。应理解，以上描述仅仅是举例说明，本发明实施例并不对共同消息特征的具体实现进行限定。分发装置可以将该共同消息特征与第一服务器的对应关系记录在一个黑名单中，该对应关系用于表征第一服务器处理具有该共同消息特征的消息的服务质量差。如表1所示，分发装置记录的黑名单的数据结构可以包含以下信息。表1黑名单示范性数据结构可选的，黑名单数据结构中还可以包含服务质量类型(QoSType)，服务质量类型用于表征服务器处理消息的质量。如表2所示，QoSType可以分为4个等级，每一个等级具有不同含义，应理解，本发明实施例仅仅是举例说明，在具体实现过程中，QoSType可以根据实际情况划分为不同的等级。表2黑名单示范性数据结构表3为依据本发明实施例的黑名单样例。表3黑名单样例AttrTypeAttrValueServerFileName/home/test.txtServer1DataKey1f553e4a-92fe-45bc-aea2-bffbf46903daServer3VolumeIDora_volumeServerMDataSize10240MBServer3其中，表3中，第一条含义：在Server1上访问文件名为/home/test.txt的文件，会导致消息的服务质量差，例如，处理时间大于预设时间阈值。第二条含义：在Server3上访问Key为1f553e4a-92fe-45bc-aea2-bffbf46903da的数据，会导致消息的服务质量差，例如，处理时间大于预设时间阈值。第三条含义：在ServerM上访问卷ID为ora_volume的数据，会导致消息的服务质量差，例如，处理时间大于预设时间阈值。第四条含义：在Server3上访问数据大小大于等于10240MB的数据，会导致消息的服务质量差，例如，处理时间大于预设时间阈值。进一步的，黑名单中还可以包含服务质量类型(QoSType)，例如，可以使用0表示禁止，1表示响应时延长，2表示资源不足，3表示处理失败等。如表4所示，表四为根据本发明一实施例的的黑名单样例。表4黑名单样例AttrTypeAttrValueServerQoSTypeFileName/home/test.txtServer10DataKey1f553e4a-92fe-45bc-aea2-bffbf46903daServer33VolumeIDora_volumeServerM1DataSize10240MBServer32其中，表4中，第一条含义：禁止在Server1上访问文件名为/home/test.txt的文件，否则可能导致系统异常。第二条含义：在Server3上访问Key为1f553e4a-92fe-45bc-aea2-bffbf46903da的数据处理失败。第三条含义：在ServerM上访问卷ID为ora_volume的数据时延长。第四条含义：在Server3上访问数据大小大于等于10240MB的数据资源不足。在分布式集群中，系统存在多个分发装置，每个分发装置服务固定区域的客户端。系统中还可以包含一个统计中心，每个分发装置负责本身分发的消息的QoS统计，并根据统计结果更新黑名单，并将QoS统计结果上报给统计中心，统计中心接收各分发装置上报的QoS统计结果后，综合计算出全局黑名单，并将全局的黑名单同步到各分发装置的黑名单。统计结果中包含上述消息特征与服务器之间的对应关系，具体可以为每个分发装置维护的黑名单。在具体实现过程中，该统计中心可以为多个分发装置中的一个。该统计中心可以由所有的分发装置投票选举得到，统计中心故障后支持重新选举。各分发装置也可以分别将自身的统计结果存储于一个公共存储设备，随后由每个分发装置分别去公共存储设备加载合并后的统计结果。在本发明实施例的另外一种实现方式中，每个分发装置负责本身分发的消息的QoS统计，根据统计结果更新黑名单，并将自身的统计结果发送个其他分发装置，每个分发装置可以将接收到的其他分发装置的统计结果加入自身维护的黑名单。应理解，在分布式架构下，分发装置之间共享统计结果的方式多种多样，本发明实施例仅仅是举例说明，并不限定各分发装置之间共享黑名单的方式。可选的，分发装置在接收到待分发消息后，首先识别待分发消息中是否携带黑名单中记录的消息特征，如果识别出待分发消息中携带黑名单中记录的消息特征，则分发装置根据该消息特征和黑名单记录的对应关系确定该消息特征对应的服务器，并在除该服务器外的服务器中为该待分发消息选择目标服务器。例如，如果分发装置接收到的待分发消息中携带第一服务器对应的上述共同消息特征，则分发装置根据黑名单记录的对应关系和该共同消息特征确定第一服务器，并在第一服务器外的其他服务器中选择第二服务器，并将待分发消息分发给第二服务器处理。在分布式集群中，分发装置接收到待分发消息后，可以先根据消息分发算法为该待分发消息选择预分配服务器，如果该预分配服务器为第一服务器，则分发装置为待分发消息选择第一服务器的从节点，则第二服务器为该第一服务器的从节点。应理解，在本发明实施例中，分发装置可以直接将待分发消息发送给第二服务器处理，也可以将待分发消息拆分为多个子消息，并将其中的一个或多个子消息发送给第二服务器处理。可选的，分发装置在接收到待分发消息后，首先识别待分发消息中是否携带黑名单中记录的消息特征，如果待分发消息中携带黑名单中记录的消息特征，则分发装置根据该消息特征和黑名单记录的对应关系确定该消息特征对应的服务器，并调低该服务器的权重，然后使用动态分配算法为待分发消息选择服务器。在这种实现方式中，通过调低服务器的权重，减小了选中第一服务器的概率。进一步的，可以将该服务器的权重调为0，从而避免选取到该服务器。在消息处理成本差异较大场景下，大规模集群长时间运行后，某个Server由于软件老化(如内存碎片)无法处理特定消息(如消息大小超过特定值)时，可能导致处理失败或处理时间长。根据本发明实施例公开的技术方案，分发装置通过把此类消息和Server的映射关系加入黑名单，尽量不再分发此类消息给该Server，提高了系统处理性能和成功率。进一步的，大规模集群长时间运行后，某个Server由于运行环境变化触发软件错误，可能导致处理特定消息(读损坏的文件)时进程异常退出，Server进程重启后，后续仍会收到此类消息而导致进程反复重启。根据本发明实施例，通过把此类消息和Server的映射关系加入黑名单，保证此类消息后续不会再分发给该Server，保证该Server不会反复故障。图5为依据本发明一实施例的消息分发方法500的示范性流程图，如图5所示，方法500包括：S502：分发装置接收待分发消息。分发装置接收到待分发消息后，会提取待分发消息的消息特征。S504：分发装置确定黑名单中是否存在与待分发消息的消息特征对应的服务器，如果在黑名单中不存在与待分发消息的消息特征对应的服务器，则执行步骤506，如果在黑名单中存在与待分发消息的消息特征对应的服务器，则执行步骤508。分发装置维护的黑名单中记录有消息特征与服务器的对应关系，该对应关系用于指示与消息特征对应的服务器处理具有该消息特征的消息的QoS差。黑名单的创建方式在图4实施例已有描述，在此不再赘述。S506：分发装置按照预设分发算法为待分发消息选择服务器。因为不存在与待分发消息的消息特征相对应的服务器，所以所有的可选的服务器都可以用来处理该待分发消息，分发装置根据预设分发算法为待分发消息选择目标服务器，并将待分发消息分发给目标服务器。S508:分发装置根据不同的分发算法执行不同的步骤，如果分发算法为轮询算法或随机算法，则执行步骤S510，如果分发算法为动态分发算法，则执行步骤S512，如果分发算法为静态路由表，哈希算法或一致性哈希算法，则执行步骤S514。S510：分发装置在服务质量差的服务器外的服务器中选择目标服务器。分发装置可以先再可选服务器列表中将服务器差的服务器删除，然后在剩余的服务器中轮询或随机选择目标服务器。服务质量差的节点为黑名单中记录的与待分发消息的消息特征对应的服务器，目标服务器为用于处理待分发消息的服务器。S512：分发装置调低服务质量差的服务器的权重，并在可选的服务器中选择目标服务器。如果预设算法为动态分发算法，为了降低选择QoS差的服务器的概率，分发装置调低QoS差的服务器的权重，然后使用动态分发算法选择目标服务器。更具体的，分发装置可以将QoS差的服务器的权重调整为0，以避免选择QoS差的服务器。S514：分发装置根据预设算法选择目标服务器。如果分发算法是静态路由表，哈希算法或一致性哈希算法，分发装置可以现根据分发算法选择目标服务器，然后再判断目标服务器是否是QoS差的服务器。S516：分发装置判断目标服务器是否为服务质量差的服务器，如果目标服务器为QoS差的服务器，则执行步骤S518，如果目标服务器不是QoS差的服务器，则将待分发消息分发给目标服务器。S518：分发装置判断目标服务器是否有可选的从服务器，如果目标服务器存在可选的从服务器，则执行步骤S520，如果目标服务器不存在可选的从服务器，则可以将待分发消息分发给目标服务器或直接给客户端反馈处理失败。分布式集群中，为保证可靠性，1个子消息一般至少有2个服务器可以处理，如果目标服务器是QoS差的服务器，则可以选择目标服务器的从服务器处理待分发消息。如果目标服务器没有从服务器或者目标服务器的从服务器也是QoS差的服务器，则可以将待分发消息发送给目标服务器处理或者直接给客户端发送处理失败的指示消息，例如，如果黑名单中包含QoS等级，如果QoS等级是处理时间，则可以仍然将待分发消息发送给目标服务器处理，如果QoS等级为禁止，则可以直接给客户端发送处理失败的指示消息。根据本申请公开的技术方案，分发装置通过对已分发消息的服务质量的监控，识别出分发给某一服务器的消息中服务质量差的消息，例如，在消息处理成本差异较大场景下，大规模集群长时间运行后，某个服务器由于软件老化(如内存碎片)无法处理特定消息(如消息大小超过特定值)，而导致处理失败或处理时间长，或者某个服务器由于运行环境变化触发软件错误，而导致处理特定消息(读损坏的文件)时进程异常退出。分发装置提取服务质量差的消息的共同消息特征，将此类消息特征和服务器的映射关系加入黑名单，后续尽量不再分发此类消息给该服务器或保证不再分发此类消息给该服务器，从而提高了系统处理性能和成功率，避免了服务器的反复故障。图6为依据本发明一实施例的一种分发装置600的逻辑结构示意图，云系统中包含客户端，分发装置600和多个服务器，如图6所示，装置600包括分发单元602，确定单元604和记录单元606。其中分发单元602用于将M个消息发送给第一服务器，其中，M为大于1的正整数。确定单元604用于确定M个消息中服务质量差的N个消息，其中，N为不大于M的正整数。可选的，确定单元604用于根据消息处理时间确定QoS差的消息。确定单元604用于确定M个消息中服务质量差的N个消息包括：确定单元604用于确定处理时间大于预设时间阈值的N个消息，并将该N个消息作为QoS差的消息。可选的，确定单元604用于确定M个消息中服务质量差的N个消息包括：确定单元604用于根据M个消息中的每个消息的响应消息，确定服务质量差的N个消息，其中，N个消息中的每个消息的响应消息中携带特征码，特征码用于指示服务质量差。记录单元606，用于提取N个消息的共同消息特征，并记录共同消息特征与第一服务器的对应关系。如图7所示，装置600还包括接收单元608，用于接收来自客户端的待分发消息，待分发消息具有共同消息特征。可选的，分发单元602用于根据记录单元606记录的对应关系和该共同消息特征确定第一服务器，并在第一服务器外的服务器中选择第二服务器，并将待分发消息分发给第二服务器处理。在一种具体的实现方式中，分发单元602用于根据预设分发算法为待分发消息选择预分配服务器，如果预分配服务器为第一服务器，则为待分发消息选择第二服务器，第二服务器为第一服务器的从节点。可选的，分发单元602用于根据记录单元606记录的对应关系和该共同消息特征确定第一服务器，调低第一服务器的权重，并使用动态分配算法为待分发消息选择服务器。分发单元602，确定单元604和记录单元606可以由图3所示的处理器302结合存储器304来实现，更具体的，可以由处理器302执行存储器304中的分发控制模块的程序代码来实现。接收单元608可以由图3所示的处理器302结合通信接口308来实现，更具体的，可以由处理器302执行存储器304中的通信模块的程序代码，以使通信接口308来实现接收单元608的功能。本发明实施例是云系统分发装置的实施例，图4和图5实施例部分的特征描述，适用于本发明实施例，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统，设备和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，在本发明各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的保护范围。当前第1页1 2 3