专利名称：分布式系统业务分发的方法和系统的制作方法
技术领域：
本发明属于通信技术领域，尤其涉及分布式系统业务分发的方法和系统。
背景技术：
在大容量的通信系统中，对于庞大的信令业务处理要求，采用集中式处理方式一般难以胜任，为了提高信令业务的处理能力，目前多采用分布式的业务处理系统。与集中式系统单模块处理方式的不同之处在于，分布式系统中的某种业务分散由多个结构相同的处理模块分担处理，因此，分布式系统具有更大的系统容量和更高的业务处理效率。
针对分布式系统，有两种信令业务分发的方案，下面分别进行描述方案一、“保存全部业务索引”法系统设置一个分发模块和多个信令业务处理模块，分发模块负责把所有信令业务分发给各个处理模块。分发模块保存和维护一个记录当前所有业务实例的特征关键字的表，该表记录了当前每个业务实例的处理模块。在业务实例的开始和结束时，分发模块负责“特征关键字表”中对应项目的创建和注销。分发模块通过查询“特征关键字表”来分发所有的信令业务，找到对应的处理模块。
上述方案中，业务的分发依赖于分发模块中维护的所述业务实例与特征关键字对应关系的表，而在大容量系统中，由于业务实例非常多，导致记录所有业务实例的“特征关键字表”非常庞大，因此，“特征关键字表”会占用巨大的内存资源。由于“特征关键字表”的庞大，分发模块将消耗较多的时间查询对应的处理模块，导致分发模块分发的效率降低，进而影响分布式系统的业务处理效率。
方案二、“直接散列”负荷分布方案，具体为系统设置一个分发模块和多个信令业务处理模块，分发模块执行散列算法得到对应的处理模块，并向该模块分发信令业务。
简单举例说明对所有的业务实例，按照特征关键字，计算出特征值，并用处理模块个数模除特征值，从而得到信令业务对应的处理模块，并向对应处理模块分发业务。可以看出，该散列算法中，模除用的处理模块个数决定了信令业务与处理模块的对应关系，当该值改变时，信令业务与处理模块的对应关系将发生很大变化，如果将某处理模块处理的信令业务重新分配到另一处理模块，可能导致已经建立的业务大范围中断。
采用散列算法，将信令业务直接映射到对应的处理模块，从而解决了方案一中占用内存资源较多和分发效率较低的问题，然而，一旦算法确定，特征关键字与处理模块的关系也就确定了，在调整个别信令业务所分配的处理模块时，散列算法稍加改变，信令业务与处理模块的对应关系即会发生很大变化，导致已经建立的业务受到大范围影响。因此，对信令业务所分配的处理模块进行调整的方案无法实际应用，因而造成下述缺陷1)在多个处理模块中的某个处理模块故障时，因为通过散列算法分配给该处理模块的业务不能被调整到其它处理模块，将导致该模块所对应的业务不能处理，因此，不能满足通信系统高可靠性的要求；2)当隔离某处理模块进行维护时，分发模块仍然执行原来的散列算法向该处理模块分发业务，隔离操作无法完成，因此，无法满足通信系统操作维护灵活方便的要求；3)当对系统进行扩容时，为了将原来由其它处理模块处理的业务部分调整到新加入的处理模块，只有改变散列算法，将导致处理模块上正在进行的业务大范围中断，因此，该方案无法实现动态扩容。
因此，在处理模块脱离/加入系统时，若对负荷进行调整，将对业务造成很大影响。
综上所述，方案一存在内存资源消耗巨大和分发处理性能低下的问题，而方案二无法实现不影响业务的负荷动态调整。
发明内容
有鉴于此，本发明的主要目的在于提供分布式系统业务分发的方法和系统，该方案能够实现不影响业务处理的负荷动态调整，并避免了内存资源消耗巨大和分发处理性能低下的问题。
为实现上述目的，本发明提供了一种分布式系统业务分发的方法，该方法包括步骤1)根据业务特征关键字执行散列算法得到散列值，以大于处理模块个数的值M为模，对所述散列值取余，将业务散列为M个业务组；2)将所述业务组分发到各组分配的处理模块处理。
其中，步骤2)所述的处理模块处理业务的步骤具体为a1)处理模块判断接收到的业务是否为初始业务，如果是，则创建业务实例并处理业务；否则，执行步骤a2)；a2)从已经创建的业务实例中根据关键字查找，如果存在对应的业务实例，则处理业务。
处理模块间进一步建立主从关系，步骤a2)还包括如果不存在对应的业务实例，则执行散列算法得到对应的业务组，若所述业务组建立了从处理模块，则转发业务到该从处理模块处理。进一步设置有效时限(Time to Live，TTL)限制从处理模块的存在时间，若TTL超时，取消对应业务组的从处理模块。
若处理模块发生故障/被隔离，在步骤2)之前还包括步骤t1)改变对应业务组分配的处理模块。
其中，所述步骤t1)具体为t11)计算某个非故障/被隔离处理模块当前应处理的业务组数；t12)判断该处理模块作为主处理模块数是否小于所述业务组数，如果是，则选取该模块用于处理故障/被隔离模块对应的业务组。
其中，选取故障/被隔离处理模块对应业务组为当前选出的非故障/未被隔离模块的步骤为b1)如果当前故障/被隔离处理模块所对应业务组的从处理模块为当前选出的非故障/未被隔离处理模块，则改变对应业务组分配的处理模块为该处理模块；否则，执行步骤b2)；b2)如果当前故障/被隔离处理模块所对应业务组的从处理模块不存在，则改变对应业务组分配的处理模块为该处理模块；否则，执行步骤b3)；b3)如果当前故障/被隔离处理模块所对应业务的从处理模块为其它非故障/未被隔离的处理模块，则改变对应业务组分配的处理模块为该处理模块。对故障处理模块，进一步取消其对应业务组的从处理模块；对被隔离处理模块，进一步置其为对应业务组的从处理模块。
若处理模块取消隔离/有新的处理模块增加，在步骤2)之前还包括步骤t2)分配业务组到取消隔离/新增的处理模块。
其中，步骤t2)具体为t21)计算某个原来的处理模块当前应处理的业务组数；t22)判断该处理模块作为主处理模块数是否大于所述业务组数，如果是，则选取该模块所对应的业务组分配到取消隔离/新增的处理模块。
其中，选取某个原来的处理模块所对应的业务组分配到取消隔离的处理模块的步骤为c1)如果当前选出的处理模块所对应业务组的从处理模块为取消隔离的处理模块，则分配对应业务组到取消隔离的处理模块；否则，执行步骤c2)；c2)如果当前选出的处理模块所对应业务组的从处理模块不存在，则分配对应业务组到取消隔离的处理模块；否则，执行步骤c3)；c3)如果当前选出的处理模块所对应业务组的从处理模块为其它的处理模块，则分配对应业务组到取消隔离的处理模块。
其中，选取某个原来的处理模块所对应的业务组分配到新增加的处理模块的步骤为d1)如果当前选出的处理模块所对应业务组的从处理模块不存在，则分配对应业务组到新增的处理模块；否则，执行步骤d2)；d2)如果当前选出的处理模块所对应业务组的从处理模块为其它的处理模块，则分配对应业务组到新增的处理模块。
进一步置所述业务组原来的主处理模块为该业务组的从处理模块。
为实现发明目的，本发明提供了一种分布式系统业务分发的系统，该系统包括分发模块、至少两个处理模块，其中分发模块，用于保存各业务组分配的处理模块的标识，根据业务特征关键字执行散列算法得到散列值，以大于处理模块个数的值M为模，对所述散列值取余，将业务散列为M个业务组，将所述业务组分发到各组分配的处理模块处理。
处理模块，用于处理接收到的业务。
其中，所述的分发模块还用于建立并保存各业务组的处理模块的主从关系，主处理模块将业务组转发到有该业务组对应业务实例的从处理模块处理。
分发模块还用于维护对应业务组分配的处理模块。
为实现发明目的，本发明提供了一种分布式系统业务分发的系统，该系统包括至少两个处理模块，各处理模块保存各业务组分配的处理模块的标识，根据业务特征关键字执行散列算法得到散列值，以大于处理模块个数的值M为模，对所述散列值取余，将业务散列为M个业务组，将所述业务组分发到各组分配的处理模块处理，并对接收到的业务进行处理。
其中，所述的处理模块还用于建立并保存各业务组的处理模块的主从关系，主处理模块将业务组转发到有该业务组对应业务实例的从处理模块处理。
系统还包括功能维护模块，用于维护对应业务组分配的处理模块。
可见，本发明所提供的系统根据业务特征关键字执行散列算法得到散列值，以大于处理模块个数的值M为模，对所述散列值取余，将业务散列为M个业务组，将所述业务组分发到各组分配的处理模块处理。
采用散列算法，与现有技术方案一相比，避免了占用巨大的系统资源以及分发处理性能低下的问题。
将业务散列为M组后，特征关键字与M个组相对应，而不是直接映射到具体的处理模块，当改变个别业务组对应的处理模块时，不会改变特征关键字与各个业务组的关系，不需要改变散列算法，因此不会对其它业务组造成影响，即不会影响其它处理模块上正在进行的业务，从而实现了负荷的动态调整，而在现有技术中，由于无法实现负荷的动态调整，在处理模块故障、进行维护或扩容时，会对业务造成很大影响。
因此，本发明与所述现有技术的方案二相比，具有如下优点1)当系统中某个处理模块发生故障时，该处理模块上的业务由其它非故障处理模块进行处理，不会影响由该模块处理的后续业务，提高了系统的可靠性。
2)当需要对某处理模块进行隔离维护时，该处理模块所分配的业务由其它未被隔离的处理模块处理，不影响后续业务；当对某处理模块取消隔离时，将原来处理模块上的部分业务组分配到该处理模块处理即可，方便了系统的维护。
3)当增加新的处理模块时，只需改变原来处理模块所对应的部分业务组到该处理模块，从而实现不影响业务的动态扩容。
更进一步，处理模块间建立主从关系时，在对处理模块进行隔离、取消隔离，以及增加新的处理模块时，将被隔离模块以及原来的主处理模块上正在进行的业务转由从处理模块进行处理，使所有的处理模块当前正在进行的业务也不会受到影响，因而所有的业务都不会受到影响，进一步提高了系统的可靠性。
在处理模块发生故障/被隔离时，将该模块上的业务转移到业务量较少的处理模块上，在处理模块取消隔离或增加新的处理模块时，由该处理模块分担业务量较多的处理模块上的负荷，从而使负荷更加均衡。
增加TTL，使得业务组与处理模块的关系最大程度上保持初始化时的状态，避免了业务的不必要转发，提高了系统效率。
图1为本发明实施例的系统结构图；图2为本发明系统为固定分发模式时系统正常运行的业务处理流程图；图3为本发明系统为固定分发模式时处理模块发生故障时的流程图；图4为本发明系统为固定分发模式时处理模块被隔离时的流程图；图5为本发明系统为固定分发模式时处理模块取消隔离时的流程图；图6为本发明系统为固定分发模式时增加新的处理模块时的流程图；图7为本发明系统为全分布式时正常运行的业务处理流程图；图8为本发明系统为全分布式时处理模块发生故障时的流程图；图9为本发明系统为全分布式时处理模块被隔离时的流程图；图10为本发明系统为全分布式时处理模块隔离取消时的流程图；图11为本发明系统为全分布式时增加新的处理模块时的流程图。
具体实施例方式
本发明为分布式系统业务分发的方法和系统，其核心思想为根据业务特征关键字执行散列算法得到散列值，以大于处理模块个数的值M为模，对所述散列值取余，将业务散列为M个业务组，并将所述业务组分发到各组分配的处理模块处理。
为使本发明的目的、技术方案和优点更加清楚明白，以下参照附图并举实施例，对本发明进一步详细说明。
在本发明中，业务分发可以分别采用固定分发模块模式和全分布式两种方案，下面分别针对这两种情况，对本发明进行详细描述(一)业务分发采用固定分发模块模式参见图1，业务分发采用固定分发模块式，即分发模块向多个处理模块分发业务，本发明所提供的处理业务的系统包括分发模块、至少两个处理模块，其中分发模块，用于保存各业务组分配的处理模块的标识，根据业务特征关键字执行散列算法得到散列值，以大于处理模块个数的值M为模，对所述散列值取余，将业务散列为M个业务组，并分发给M个业务组对应的处理模块，并可通过改变业务组对应的处理模块来动态调整业务负荷。
处理模块，用于接收业务并进行处理。
上述分发模块对散列值取余所得的余数可以与业务组的标号相同或一一对应。所述M取值必须大于实际的处理模块的个数，M取值越大，负荷越均衡，其中，当M值为小于等于实际处理模块个数的所有数的最小公倍数时，M相对较大又使各个模块上分配的业务组相等，负荷非常均衡。例如，实际有7个处理模块，M取值可为1、2、3、4、5、6、7的最小公倍数420。
可以通过业务分发表的方式来建立和维护业务组与处理模块的对应关系。业务分发表由M个业务组组成，在初始化时可以轮流填充每个业务组对应处理模块的标识，以保证负荷分担尽量均衡。
为了在改变业务组对应的处理模块时，不使原处理模块上已经建立的业务中断，每个业务组还可以分配一个从处理模块，将原来的处理模块作为从处理模块，处理该模块上已经建立的业务。为了避免业务的过多转发，在初始化时将从处理模块初始化为空。
为了保持业务分发表初始化时的状态，避免在经过了较长时间后，过多的信令业务进行不必要的转发，浪费系统资源，业务分发表还可以包括有效时限(Time to Live，TTL)，如图1所示。
该业务分发表共有M个业务组，对每个业务组，业务分发表包括主、从处理模块的标识以及从处理模块的TTL值三个属性。主处理模块属性非空，表示对应业务组的处理模块。从处理模块在TTL非0的时候可以非空，表示在某段时间，该组的某些信令业务仍然是由从处理模块处理的。例如，当设置从处理模块时，对应TTL值设置为64，TTL值从64往下计数，后续每隔一个固定时间TTL值递减一，当TTL值为0时，清除对应组的从处理模块。当然，TTL值也可根据实际业务的处理时间及各个从处理模块的具体负荷能力来设置，以保证原有以建立的业务处理完毕而又避免后续业务的不必要转发。初始化时该值设置为0。
分发模块的分发规则为根据各业务的特征关键字，比如移动用户识别码(Mobile Station Identification，MSID)、国际移动用户识别码(InternationalMobile Station Identification，IMSI)或电子串号(Electronic Serial Number，ESN)，执行散列算法得到唯一的散列值，以大于处理模块个数的值M为模，对所述散列值取余，将信令业务散列为M组，并把信令业务分发给业务分发表中记录的对应业务组的主处理模块。
每个处理模块内部还可保存一个从处理模块记录表，以避免转发时需要从分发模块获得从处理模块地址，给分发模块增加不必要的负荷。该表记录有每个业务组对应的从处理模块，对每个处理模块的从处理模块记录表，该表中记录的业务组分配的处理模块的标识与业务分发表中该处理模块所对应的所有业务组的从处理模块标识相同。例如，当某个处理模块故障或被隔离时，分发模块改变业务分发表后，立即通知处理模块改变从处理模块记录表，即可实现二者同步。
处理模块对接收到信令业务的处理规则为判断如果是初始信令业务，则创建业务实例并处理信令业务，否则，从已经创建的业务实例中根据关键字查找，如果存在对应的业务实例，则处理信令，否则，执行散列算法得到对应的业务组，查找从处理模块记录表中对应的记录，如果为空或是自身，则丢弃该信令，否则，转发信令给对应的从处理模块。
为了方便起见，每个处理模块也可保存和维护一个业务分发表，即每个模块中的表都是相同的。
以上为本发明所提供的系统的描述，下面结合附图，对在业务分发采用固定分发模块模式的情况下，本发明所提供的方法进行详细描述实施例一、参见图2，实现本发明需要以下步骤步骤200分发模块创建业务分发表并进行初始化假设有7个处理模块，令M等于420，把各处理模块的标识如地址作为编号轮流填写到主处理模块属性中，以保证各处理模块在业务分发表的主处理模块标识中出现的次数大致相同；从处理模块标识初始化为空，TTL值初始化为0。各处理模块初始化从处理模块记录表令M等于420，从处理模块属性初始化为空。
步骤201分发模块根据各信令业务中的MSID，执行设定的散列算法得到唯一的散列值，并按M模取余，将信令业务散列为M个组，M等于420，并把信令业分发给业务分发表中记录的对应业务组的主处理模块。
步骤202处理模块接收信令业务。
步骤203处理模块判断是否为初始信令业务，如果是，则执行步骤211；如果否，则执行步骤204。
步骤204各处理模块从已经创建的业务实例中根据MSID查找。
步骤205判断是否存在对应的业务实例，如果是，则执行步骤210；否则，执行步骤206。
步骤206执行散列算法得到对应的业务组。
步骤207判断对应业务组从处理模块属性是否为空或是自身，如果是，则执行步骤209；如果否，则执行步骤208。
步骤208转发信令业务给对应的从处理模块。
步骤209处理模块将该信令丢弃。
步骤210处理模块对该信令进行处理。
步骤211处理模块创建业务实例，并处理该初始信令。
上述步骤202～步骤211为处理模块处理业务的过程。
在步骤200中，将业务分发表及从处理模块记录表中的从处理模块初始化为空，避免了信令业务的二次转发，节约了资源，提高了系统效率。
步骤201中所述的特征关键字MSID也可以是IMSI或ESN。
如果不设置从处理模块，则初始化时只需初始化业务分发表中的处理模块即可。
实施例二、当某处理模块发生故障时，如图3所示，假设处理模块F发生故障，实现本发明需要以下步骤步骤301分发模块计算非故障处理模块应该处理的业务组的个数K。设有N个非故障处理模块，分发模块初始化时是按轮流循环的方式将各个处理模块地址填入业务分发表的主处理模块中，则前面M％N个处理模块应处理M/N+1个业务组，后面的处理模块应处理M/N个业务组。
步骤302分发模块判断非故障处理模块的个数N是否大于0，如果是，则执行步骤303；如果否，则执行步骤309。
步骤303设D为下一个非故障处理模块，判断D在业务分发表中作为主处理模块的次数是否大于等于其应该处理的业务组的个数K，如果是，执行步骤308；如果否，执行步骤304。
步骤304判断是否存在主处理模块为F且从处理模块为D的业务组，如果是，执行步骤307；如果否，执行步骤305。
步骤305判断是否存在主处理模块为F且从处理模块为空的业务组，如果是，执行步骤307；如果否，执行步骤306。
步骤306判断是否存在主处理模块为F的业务组，如果是，执行步骤307；否则，执行步骤308。
步骤307对选取的业务组进行操作置业务组的主处理模块为该非故障处理模块D，从处理模块为空，TTL值为0；并通知D改变其从处理模块记录表中对应业务组的从处理模块属性为空；然后执行步骤303。
步骤308N递减一，并执行步骤301。
步骤309分发模块分发信令业务。分发模块根据各信令业务的特征关键字，如MSID、IMSI、ESN等，执行预设的散列算法得到唯一的散列值，并按M模取余，将信令业务散列为M个组，并把信令业分发给业务分发表对应业务组的主处理模块。
步骤310处理模块处理信令业务。处理模块接收信令业务并判断是否是初始信令业务，如果是，则创建业务实例并处理该初始信令业务；如果否，则从已经创建的业务实例中根据特征关键字进行查找，如果找到对应的业务实例，则对该信令业务进行处理；否则，执行设定的散列算法得到对应的业务组，查找从处理模块记录表中对应的记录，如果非空或不是自身，则转发该信令业务给对应的从处理模块；否则丢弃该信令。
步骤302～步骤308为分发模块改变业务分发表，处理模块调整从处理模块记录表的过程。在步骤307中将处理模块F对应的业务调整到其它非故障处理模块上，这些信令业务得以继续处理。
上述步骤304至步骤306为从处理模块F的处理模块中按优先级选取业务组的过程，这样对业务分发表的所做的调整最小，同时不至于使某个模块上的负荷陡增，保持负荷均衡，从而实现负荷的动态调整。
从步骤308和步骤309可以看出，所述的分发模块分发信令业务和处理模块处理信令业务的步骤与实施例一中的步骤相同，与实施例一的不同之处在于，需要在分发前对业务分发表及从处理模块记录表进行改变。
实施例三、当用户维护处理模块，某处理模块被隔离时，参见图4，设处理模块F被隔离，下面描述改变业务分发表及从处理模块记录表的具体步骤。
步骤401分发模块计算未被隔离处理模块应该处理的业务组的个数K。设有N个未被隔离的处理模块，分发模块初始化时是按轮流循环的方式将各处理模块ID填入业务分发表的主处理模块属性中，则前面M％N个处理模块应处理M/N+1个业务组，后面的处理模块应处理M/N个业务组。
步骤402分发模块判断非故障处理模块的个数N是否大于0，如果是，执行步骤403；如果否，结束循环。
步骤403设D为下一个未被隔离的处理模块，判断D在业务分发表中作为主处理模块的次数是否大于等于其应该处理的业务组的个数K，如果是，执行步骤408；如果否，执行步骤404。
步骤404判断是否存在主处理模块为F且从处理模块为D的业务组，如果是，执行步骤407；如果否，执行步骤405。
步骤405判断是否存在主处理模块为F且从处理模块为空的业务组，如果是，执行步骤407；如果否，执行步骤406。
步骤406判断是否存在主处理模块为F的业务组，如果是，执行步骤407；否则，执行步骤408。
步骤407对选取的业务组进行操作置业务组的主处理模块为该未被隔离处理模块D，从处理模块为被隔离处理模块F的ID，TTL值为预设的最大值；并通知D改变其从处理模块记录表中对应业务组的从处理模块属性为被隔离处理模块F的ID；然后执行步骤403。
步骤408N递减一，并执行步骤401。
业务分发表及从处理模块记录表改变后，分发模块将信令业务分发到对应的处理模块并进行处理，如上述实施例二步骤309和步骤310所示，不再详细描述。
本实施例中，与处理模块故障时采取的不同措施在于，置选取的业务组的从处理模块为被隔离的处理模块，TTL为预设最大值，使被隔离处理模块上正在进行的业务得到处理。
实施例四、当处理模块取消隔离时的方案。
同实施例二的流程大致相同，下面仅对业务分发表以及从处理模块记录表的维护与改变进行描述。
如图5所示，当处理模块F取消隔离时，需要采取以下步骤步骤501当分发模块检测到处理模块F取消隔离的请求后，首先计算加入取消隔离的处理模块后每个处理模块应该处理的业务组的个数设加入F后处理模块的个数为N，第N个处理模块应该处理的业务组的个数为K，则其中M％N个处理模块应该处理M/N+1个业务组，其它的处理模块应该处理M/N个业务组，这个可以用统计的方法获得。
步骤502判断N是否大于0，如果是，则执行步骤503；如果否，则结束循环。
步骤503设D为下一个原来的处理模块，判断D在业务分发表的处理模块属性中出现的次数是否小于等于K，如果是，执行步骤508；否则，执行步骤504。
步骤504判断是否存在主处理模块D且从处理模块为F的业务组，如果是，执行步骤507；否则，执行步骤505。
步骤505判断是否存在主处理模块为D且从处理模块为空的业务组，如果是，执行步骤507；否则，执行步骤506。
步骤506判断是否存在出来模块为D的业务组，如果是，执行步骤507；否则，执行步骤508。
步骤507对选取的业务组进行操作置其从处理模块为当前主处理模块，设为MD，置其主处理模块为F，TTL值置为最大值；通知MD改变其从处理模块记录表中对应业务组的从处理模块属性为空，通知F改变其从处理模块记录表中对应业务组的从处理模块为MD；然后执行步骤503。
步骤508N递减一，并执行步骤501。
实施例五、当系统需要扩展，有新的处理模块需要增加时的方案，如图6所示，需要采取以下步骤步骤601当分发模块检测到新的处理模块G的添加请求后，首先计算加入新的处理模块G后每个处理模块应该处理的业务组的个数设加入G后处理模块的个数为N，第N个处理模块应该处理的业务组的个数为K，为了保证均衡，在初始化时仍轮流将各处理模块填写到业务分发表中的主处理模块属性中，前面的M％N个处理模块应该处理M/N+1个业务组，其它的处理模块应该处理M/N个业务组。
步骤602判断N是否大于0，如果是，执行步骤603；否则，结束循环。
步骤603设D为下一个原来的处理模块，判断D在业务分发表的主处理模块属性中出现的次数是否小于等于K，如果是，执行步骤607；否则，执行步骤604。
步骤604判断是否存在主处理模块为D且从处理模块为空的业务组，如果是，则执行步骤606；否则，执行步骤605。
步骤605判断是否存在主处理模块为D的业务组，如果是，执行步骤606；否则，执行步骤607。
步骤606对选取的业务组进行操作置其从处理模块为当前主处理模块，设为MD，置其主处理模块为G，TTL值置为最大值；通知MD改变其从处理模块记录表中对应业务组的从处理模块属性为空，通知G改变其从处理模块记录表中对应业务组的从处理模块为MD；然后执行步骤603。
步骤607N递减一，并执行步骤601。
与上述两实施例相同，当检测到处理模块脱离或加入时，分发模块完成对业务分发表的改变，相应的处理模块完成对从处理模块记录表的改变后，分发模块即可根据业务分发表来分发信令业务，处理模块对接收到的信令业务进行处理，从而完成整个分布式系统的业务处理。整个过程中保证了负荷的均衡，且这种动态调整不会对业务产生影响，保证系统的可靠性和处理效率，便于维护和扩充系统容量。
当然，如果处理模块中没有从处理模块记录表，则只需调整分发模块中业务分发表的相应业务组的主处理模块属性值。在处理模块需要转发信令业务时，从分发模块中获得相应的业务地址。
如果从处理模块中保存的也为主从结构业务分发表，在分发模块中的主从结构业务分发表改变后，同步给各处理模块即可。
以上为分发业务采用固定分发模块模式时业务分发的具体描述，下面对分发业务采用全分布式模式时本发明所提供的系统和方法进行详细描述。
(二)业务分发采用全分布式结构本发明的业务分发也可采用全分布式结构，系统不设置专门的分发模块，只有处理模块，分发模块的功能由各个处理模块来完成，各个处理模块内部都保存和维护有一个业务分发表，该表与系统一中的业务分发表结构相同，对每个业务组，也可以扩展从处理模块及TTL。
该系统的分发规则为根据业务特征关键字执行散列算法得到散列值，以大于处理模块个数的值M为模，对所述散列值取余，将业务散列为M个业务组，并将所述业务组分发到各组分配的处理模块处理。
在建立业务分发表的基础上，将信令业务散列到业务分发表中对应的M个业务组，所述分发模块对散列值取余所得的余数可以与业务分发表中业务组的标号相同或一一对应。M取值必须大于实际的处理模块的个数，M取值越大，负荷越均衡，其中，当M值为小于等于实际处理模块个数的所有数的最小公倍数时，M相对较大又使各个模块上分配的业务组相等，负荷非常均衡。
若没有设置从处理模块，则把信令业务分发给业务分发表中各业务组对应的处理模块并由该模块处理。
若设有从处理模块，判断如果该业务组的从处理模块是自身，则直接处理该信令。对从处理模块不是自身的信令业务，如果该业务组的主处理模块也不是自身，则把信令业务分发给业务分发表中记录的对应组的主处理模块；若该业务组的主处理模块是自身，对初始信令，创建业务实例并直接处理之；对其它信令，如果能够找到对应的业务实例，则直接处理，否则转发给其它从处理模块。
各个处理模块还用于维护业务分发表，例如当某模块发生故障或被隔离等异常情况下，该模块首先修改其内部的业务分发表，并广播通知其它处理模块。
为了节约资源，并使各个处理模块内部的主从结构业务分发表保持一致，处理模块的维护功能也可由单独的某一处理模块来完成并同步给其它处理模块。维护模块的选取可以采用令牌的方式，用于令牌的模块作为业务分发表的维护模块。各个处理模块可以轮流拥有令牌，也可以确定由某一处理模块拥有令牌，如果拥有该令牌的处理模块发生故障，则可以把令牌交给相邻的处理模块，也可以采用其它的令牌传递规则，以保持系统的可靠。
当然，为了简便起见，可以由用户直接指定一个处理模块承担维护业务分发表的功能。当该模块故障时，由用户指定另外一个处理模块进行维护，以避免复杂的令牌转移算法。
以上为本发明所提供的系统的描述，下面对利用该系统所提供的方法进行详细描述。
实施例一、处理模块正常运行时的方案。
如图7所示，实现本发明需要以下步骤步骤701处理模块根据接收到的各信令的特征关键字执行散列算法得到唯一的散列值，并对该值M模取余，将信令业务散列为业务分发表中对应的M个业务组。
步骤702处理模块在业务分发表中查找，判断自身是否为对应业务组的处理模块，如果是，执行步骤703；如果否，执行步骤711。
步骤703处理模块判断信令业务是否为初始信令业务，如果是，执行步骤709；否则，执行步骤704。
步骤704处理模块从已经创建的业务实例中根据关键字查找。
步骤705判断是否存在对应的业务实例，如果是，执行步骤710；否则，执行步骤706。
步骤706处理模块判断业务分发表中对应的从处理模块属性是否为空，如果是，执行步骤707；否则，执行步骤708。
步骤707丢弃该信令业务。
步骤708转发该信令给对应的从处理模块。
步骤709处理模块创建业务实例，并处理该初始信令业务。
步骤710对该信令业务进行处理。
步骤711判断信令发送模块是否为主处理模块，如果是，执行步骤712；否则，执行步骤716。
步骤712根据业务分发表判断自身是否为从处理模块，如果是，执行步骤713；否则，执行步骤715。
步骤713从已经创建的业务实例中根据特征关键字查找，如果存在对应的业务实例，执行步骤714；否则，执行步骤715。
步骤714处理该信令业务。
步骤715丢弃该信令业务。
步骤716转发信令给对应的业务实例。
系统开始工作前同样需要对业务分发表初始化，与系统一相同，不再详细描述。
实施例二、当处理模块发生故障时，首先由功能维护模块负责处理模块维护业务分发表，然后处理模块按照改变后的业务分发表分发信令业务和处理信令业务。处理模块进行信令的分发与业务的处理与实施例一流程相同，以下仅就功能维护模块改变业务分发表的操作进行详细描述，参见图8。
步骤801功能维护模块检测到处理模块F发生故障，首先计算非故障处理模块应该处理的业务组的个数设非故障处理模块的个数为N，第N个处理模块应该处理的业务组的个数为K，则其中M％N个处理模块应该处理M/N+1个业务组，其它的处理模块应该处理M/N个业务组。
步骤802功能维护模块判断N是否大于0，如果是，则执行步骤803；若N＜0，则所有非故障处理模块在业务分发表中都经过调整，执行步骤809。
步骤803为描述方便，设D为下一个非故障处理模块，功能维护模块判断D在业务分发表中作为主处理模块的次数是否大于等于K，如果是，执行步骤808；否则执行步骤804。
步骤804判断是否存在主处理模块为F且从处理模块为D的业务组，如果是，执行步骤807；否则，执行步骤805。
步骤805判断是否存在主处理模块为F且从处理模块为空的业务组，如果是，执行步骤807；如果否，执行步骤806。
步骤806判断是否存在主处理模块F的业务组，如果是，执行步骤807；否则，执行步骤808。
步骤807功能维护模块对选取的业务组进行操作置其主处理模块为D，从处理模块属性为空，TTL值置为0，并执行步骤803，以判定D作为主处理模块属性的次数是否不大于应该处理的业务组的个数，保持负荷均衡。
步骤808N递减一，将非故障处理模块已改变过的及不需要改变的排除在外，并执行步骤801。
步骤809功能维护模块将改变同步给其它所有的处理模块。
业务分发表改变完毕后，处理模块按照改变后的业务分发表来分发信令业务并进行相应处理，步骤与正常工作情况下的流程相同，不再详细描述。
实施例三、当处理模块被隔离时，首先由功能维护模块负改变业务分发表，然后处理模块按照改变后的业务分发表来分发信令业务和处理信令业务。处理模块进行信令的分发与业务的处理与实施例一流程相同，以下仅就功能维护模块改变业务分发表的操作进行详细描述，参见图9。
步骤901功能维护模块检测到处理模块F被隔离，首先计算未被隔离的处理模块应该处理的业务组的个数设未被隔离的处理模块的个数为N，第N个处理模块应该处理的业务组的个数为K，初始化时仍按循环轮流方式将各处理模块地址填入各业务组对应的主处理模块中，则前面M％N个处理模块应该处理M/N+1个业务组，后面的处理模块应该处理M/N个业务组。
步骤902功能维护模块判断N是否大于0，如果是，则执行步骤903；若N＜0，则所有非故障处理模块在业务分发表中都经过调整，执行步骤909。
步骤903为描述方便，设D为下一个未被隔离的处理模块，功能维护模块判断D在业务分发表中作为主处理模块的次数是否大于等于K，如果是，执行步骤908；否则执行步骤904。
步骤904判断是否存在主处理模块为F且从处理模块为D的业务组，如果是，执行步骤907；否则，执行步骤905。
步骤905判断是否存在主处理模块为F且从处理模块为空的业务组，如果是，执行步骤907；如果否，执行步骤906。
步骤906判断是否存在主处理模块F的业务组，如果是，执行步骤907；否则，执行步骤908。
步骤907功能维护模块对选取的业务组进行操作置其主处理模块为D，从处理模块属性为被隔离处理F，TTL值置为预设最大值，并执行步骤903，以判定D作为主处理模块属性的次数是否不大于应该处理的业务组的个数，保持负荷均衡。
步骤908N递减一，将未被隔离的处理模块已改变过的及不需要改变的排除在外，并执行步骤901。
步骤909功能维护模块将改变同步给其它所有的处理模块。
在本实施例中，将所选取业务组的从处理模块属性值设置为被隔离的处理模块，将TTL至为预设最大值，从而使得被隔离处理模块上正在进行的业务不会因为业务分发表的改变而中断，使业务最大限度地不受影响。
业务分发表改变完毕后，处理模块按照改变后的业务分发表分发信令业务并进行相应处理，步骤与正常工作情况下的流程相同，不再详细描述。
实施例四、当处理模块隔离取消时的方案。
参照图10，功能维护模块仍然采取类似的步骤，以下仅描述业务分发表的改变过程。
步骤1001当功能维护模块检测到有被隔离的处理模块需要取消隔离时，首先计算加入取消隔离的处理模块后每个处理模块应该处理的业务组的个数设取消隔离的处理模块为F，N为加入F后处理模块的个数，第N个处理模块应该处理的业务组的个数为K，初始化时轮流将各个处理模块填入业务分发表中各业务组对应的主处理模块中，则前面的M％N个处理模块应该处理M/N+1个业务组，其它的处理模块应该处理M/N个业务组。
步骤1002功能维护模块判断N是否大于0，如果是，执行步骤1003，如果否，执行步骤1009。
步骤1003设D下一个为原来的处理模块，功能维护模块比较D在业务分发表的主处理模块属性中出现的次数是否小于等于K，如果是，则N递减一，并执行步骤1001；否则，执行步骤1004。
步骤1004查找主处理模块D且从处理模块为F的业务组，如果存在，执行步骤1007；否则，执行步骤1005。
步骤1005查找主处理模块为D且从处理模块为空的业务组，如果存在，执行步骤1007；否则，执行步骤1006。
步骤1006查找主处理模块为D的业务组，如果存在，执行步骤1007；否则，执行步骤1008。
步骤1007对查找到的业务组进行操作置其从处理模块为当前主处理模块，置其主处理模块为F，TTL值设置为预设的最大值，并执行步骤1003。
步骤1008N递减一，并执行步骤1001。
步骤1009同步业务分发表给其它的处理模块。
实施例五、当有新的处理模块增加时，功能维护模块与上述实施例四中所采取的措施大致相同，如图11所示，增加新的处理模块G，功能维护模块首先要改变业务分发表中的对应业务组，业务分发表改变完毕后，处理模块进行信令业务的分发及处理，下面仅对业务分发表的改变流程进行详细描述。
步骤1101当功能维护模块检测到有新的处理模块G增加时，首先计算加入G后每个处理模块(包括功能维护模块自身)应该处理的业务组的个数K设加入G后共有N个处理模块，业务分发表轮流将处理模块填入对应业务组的主处理模块属性中，则前面M％N个处理模块应该处理M/N+1个业务组，其它的处理模块应该处理M/N个业务组。
步骤1102功能维护模块判断N是否大于0，如果是，执行步骤1103，如果否，执行步骤1108。
步骤1103设D下一个为原来的处理模块，功能维护模块比较D在业务分发表的主处理模块属性中出现的次数是否小于等于K，如果是，执行步骤1107；否则，执行步骤1104。
步骤1104功能维护模块从业务分发表中查找，如果存在主处理模块属性值D且从处理模块属性为空的业务组，则执行步骤1106；否则，执行步骤1105。
步骤1105功能维护模块继续在业务分发表中查找主处理模块属性值为D的业务组，如果存在，则执行步骤1106；否则，执行步骤1107。
步骤1106对选取的业务组进行操作置其从处理模块属性为当前主处理模块，置其主处理模块属性值为G，TTL值设置为设定的最大值，并执行步骤1103，以确保负荷均衡。
步骤1107N递减一，并执行步骤1101，对下一个原来的处理模块进行处理。
步骤1108功能维护模块将业务分发表同步给其它所有的处理模块，并按正常流程进行信令业务的分发和处理。
当本发明的功能维护模块，即业务分发表维护模块故障时，用户可从剩余的处理模块中指定一个新的业务分发表维护模块。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明。例如，分发模块可以选取任意一个原来的处理模块，而不必对该处理模块应该处理的业务组数进行计算及将计算值与该处理模块作为主处理模块的次数进行比较，也不需要考虑其处理模块的具体情况。事实上，在对原来的处理模块所对应的业务组进行选择时，从处理模块属性值可能为该负荷值较小的处理模块、为空或其它的处理模块，可以按照上述实施例中的顺序选择，也可以仅考虑其中任意一种或多种可能。对增加新的处理模块时，则只需在从处理模块为空或其它的处理模块两种可能的业务组中任意选取。
凡在本发明的精神和原则之内，所作的任何改变、等同替换、改进等，均应包含在本发明的保护范围之内。
权利要求
1.一种分布式系统业务分发的方法，其特征在于，该方法包括步骤1)根据业务特征关键字执行散列算法得到散列值，以大于处理模块个数的值M为模，对所述散列值取余，将业务散列为M个业务组；2)将所述业务组分发到各组分配的处理模块处理。
2.如权利要求1所述的分布式系统业务分发的方法，其特征在于，步骤2)所述的处理模块处理业务的步骤具体为a1)处理模块判断接收到的业务是否为初始业务，如果是，则创建业务实例并处理业务；否则，执行步骤a2)；a2)从已经创建的业务实例中根据关键字查找，如果存在对应的业务实例，则处理业务。
3.如权利要求2所述的分布式系统业务分发的方法，其特征在于，处理模块间进一步建立主从关系，步骤a2)还包括如果不存在对应的业务实例，则执行散列算法得到对应的业务组，若所述业务组建立了从处理模块，则转发业务到该从处理模块处理。
4.如权利要求3所述的分布式系统业务分发的方法，其特征在于，进一步设置有效时限限制从处理模块的存在时间，若有效时限超时，取消对应业务组的从处理模块。
5.如权利要求1至4任一项所述的分布式系统业务分发的方法，其特征在于，若处理模块发生故障/被隔离，在步骤2)之前还包括步骤t1)改变对应业务组分配的处理模块。
6.如权利要求5所述的分布式系统业务分发的方法，其特征在于，所述步骤t1)具体为t11)计算某个非故障/被隔离处理模块当前应处理的业务组数；t12)判断该处理模块作为主处理模块数是否小于所述业务组数，如果是，则选取该模块用于处理故障/被隔离模块对应的业务组。
7.如权利要求6所述的分布式系统业务分发的方法，其特征在于，选取故障/被隔离处理模块对应业务组为当前选出的非故障/未被隔离模块的步骤为b1)如果当前故障/被隔离处理模块所对应业务组的从处理模块为当前选出的非故障/未被隔离处理模块，则改变对应业务组分配的处理模块为该处理模块；否则，执行步骤b2)；b2)如果当前故障/被隔离处理模块所对应业务组的从处理模块不存在，则改变对应业务组分配的处理模块为该处理模块；否则，执行步骤b3)；b3)如果当前故障/被隔离处理模块所对应业务的从处理模块为其它非故障/未被隔离的处理模块，则改变对应业务组分配的处理模块为该处理模块。
8.如权利要求5所述的分布式系统业务分发的方法，其特征在于，对故障处理模块，进一步取消其对应业务组的从处理模块；对被隔离处理模块，进一步置其为对应业务组的从处理模块。
9.如权利要求1至4任一项所述的分布式系统业务分发的方法，其特征在于，若处理模块取消隔离/有新的处理模块增加，在步骤2)之前还包括步骤t2)分配业务组到取消隔离/新增的处理模块。
10.如权利要求9所述的分布式系统业务分发的方法，其特征在于，所述步骤t2)具体为t21)计算某个原来的处理模块当前应处理的业务组数；t22)判断该处理模块作为主处理模块数是否大于所述业务组数，如果是，则选取该模块所对应的业务组分配到取消隔离/新增的处理模块。
11.如权利要求10所述的分布式系统业务分发的方法，其特征在于，选取某个原来的处理模块所对应的业务组分配到取消隔离的处理模块的步骤为c1)如果当前选出的处理模块所对应业务组的从处理模块为取消隔离的处理模块，则分配对应业务组到取消隔离的处理模块；否则，执行步骤c2)；c2)如果当前选出的处理模块所对应业务组的从处理模块不存在，则分配对应业务组到取消隔离的处理模块；否则，执行步骤c3)；c3)如果当前选出的处理模块所对应业务组的从处理模块为其它的处理模块，则分配对应业务组到取消隔离的处理模块。
12.如权利要求10所述的分布式系统业务分发的方法，其特征在于，选取某个原来的处理模块所对应的业务组分配到新增加的处理模块的步骤为d1)如果当前选出的处理模块所对应业务组的从处理模块不存在，则分配对应业务组到新增的处理模块；否则，执行步骤d2)；d2)如果当前选出的处理模块所对应业务组的从处理模块为其它的处理模块，则分配对应业务组到新增的处理模块。
13.如权利要求9所述的分布式系统业务分发的方法，其特征在于，进一步置所述业务组原来的主处理模块为该业务组的从处理模块。
14.一种分布式系统业务分发的系统，其特征在于，该系统包括分发模块、至少两个处理模块，其中分发模块，用于保存各业务组分配的处理模块的标识，根据业务特征关键字执行散列算法得到散列值，以大于处理模块个数的值M为模，对所述散列值取余，将业务散列为M个业务组，将所述业务组分发到各组分配的处理模块处理。处理模块，用于处理接收到的业务。
15.如权利要求14所述的分布式系统业务分发的系统，其特征在于，所述的分发模块还用于建立并保存各业务组的处理模块的主从关系，主处理模块将业务组转发到有该业务组对应业务实例的从处理模块处理。
16.如权利要求14或15所述的分布式系统业务分发的系统，其特征在于，分发模块还用于改变对应业务组分配的处理模块。
17.一种分布式系统业务分发的系统，其特征在于，该系统包括至少两个处理模块，各处理模块保存各业务组分配的处理模块的标识，根据业务特征关键字执行散列算法得到散列值，以大于处理模块个数的值M为模，对所述散列值取余，将业务散列为M个业务组，将所述业务组分发到各组分配的处理模块处理，并对接收到的业务进行处理。
18.如权利要求17所述的分布式系统业务分发的系统，其特征在于，所述的处理模块还用于建立并保存各业务组的处理模块的主从关系，主处理模块将业务组转发到有该业务组对应业务实例的从处理模块处理。
19.如权利要求17或18所述的分布式系统业务分发的系统，其特征在于，系统还包括功能维护模块，用于改变对应业务组分配的处理模块。
全文摘要
本发明属于通信技术领域，公开了分布式系统业务分发的方法和系统，利用本发明所提供的系统，采用如下方法1)根据业务特征关键字执行散列算法得到散列值，以大于处理模块个数的值M为模，对所述散列值取余，将业务散列为M个业务组；2)将所述业务组分发到各组分配的处理模块处理。该方案能够实现负荷的动态调整，简便易行，而不会对其它处理模块上正在进行的业务造成影响，也不影响后续业务的进行。
文档编号H04Q3/00GK1889699SQ200610099299
公开日2007年1月3日 申请日期2006年7月27日 优先权日2006年7月27日
发明者谭平, 曾智礼 申请人:华为技术有限公司