CN100385974C - 消息同步的方法 - Google Patents

Abstract

本发明涉及一种消息同步的方法，执行以下步骤：MC向UM server发送同步通知；MC收集用户UM消息信息；UM server收集用户UM消息信息，将其发送给MC；MC对比两方存储的用户UM消息信息的差异；根据对比结果，判断是否存在仅在UM server中存在的用户UM消息，是，执行下一步；否则MC删除仅在其自身存储的用户UM消息；MC向UM server发送获取通知；UMserver在获取通知的响应中将仅在其自身存在的用户UM消息列表发送给MC；结束。本发明解决了MC和UM server之间因连接断开或者MC故障造成的问题。

Description

消息同步的方法

技术领域

本发明涉及一种消息同步的方法，特别是一种在消息中心和统一消息服务器之间同步消息的方法。

背景技术

消息中心(Message Center，简称MC)为用户提供统一的消息存储管理和统一的消息摘要展示。借助MC系统提供的服务，用户可以管理其发送和接收的SMS(Short Message Service，短消息服务)、MMS(Multimedia MessagingService，多媒体短消息服务)和UM(Unification Message，统一消息)，其中UM消息包括Email、Fax和Voicemail。

UM消息实体存储在UM server上。为了实现对用户的UM消息统一存储和管理，MC和UM server之间建立通信接口，通过该接口交换信息，并且在MC中维护用户UM消息的摘要和容量信息。在MC出现功能故障或者两者之间的连接断开期间，UM server或者MC中UM消息发生的变化就不能准确及时的反应到对方系统中，因此造成UM server和MC中的UM消息出现不一致的情况。

出现这样的情况，将对MC系统造成比较严重的影响：

MC系统以容量包月方式提供给用户使用，MC系统在用户设定的时间收集用户的容量信息，并根据用户当前的容量信息生成计费信息，如果用户UM消息删除通知没有及时到达MC，导致用户邮箱容量没有及时减小，有可能给用户造成用户经济上的损失，如果用户UM添加消息通知没有及时到达MC，导致用户邮箱容量没有及时增加，则有可能给运营商造成经济损失。

目前解决这一问题的方案是：

由于MC和UM server之间存储分离，在MC出现故障或者MC与UM server之间连接出现故障的持续时间范围内，由UM server保存UM消息的所有变更。当MC功能恢复并与UM server连接正常建立之后，UM server将保存的变更通知给MC，并由MC完成消息变更处理。UM server通知MC消息的所有变更与实际变更顺序必须完全一致。

在MC与UM server之间的连接断开的持续范围之内，MC需要保存所有用户操作引起的UM消息变更。并在两者连接恢复时，将所有变更通知UMserver，由UM server完成消息变更处理。MC通知UM server的所有变更与实际变更顺序必须完全一致。

该方案的局限如下：

1、增加了UM server和MC的实现的难度。UM server和MC必须保存其故障期间UM消息的所有变更，并且要保证所有变更的顺序均要与实际发生顺序一致。

2、MC功能和两者之间连接恢复正常之后，MC和UM server势必要将各自保存的消息变更通知给对方。如果在发送变更通知时不采用速度控制策略，则必定对对方的业务造成较大的冲击；而如果采用速度控制策略，则会增加双方系统的实现难度。

发明内容

本发明的目的是针对上述现有技术的不足，提供一种消息同步的方法，采用不同的触发方式，对比所述消息中心和所述统一消息服务器两方存储的用户的统一消息信息的差异，完成消息同步，从而解决MC和UM server之间因连接断开或者MC故障造成的问题。

为实现上述目的，本发明提出了一种消息同步的方法，其中执行以下步骤：

消息中心向统一消息服务器发送同步通知；

所述消息中心收集所述消息中心存储的用户的统一消息信息；

所述统一消息服务器接收到所述同步通知后，收集所述统一消息服务器存储的用户的统一消息信息，并将所述用户的统一消息信息发送给所述消息中心；

所述消息中心对比所述消息中心和所述统一消息服务器两方存储的用户的统一消息信息的差异，判断是否存在仅存储在统一消息服务器中的用户统一消息，如果是，则继续步骤A；否则判断是否存在仅存储在统一消息中心的用户统一消息，如果是，则删除仅在统一消息中心存储的用户统一消息，结束消息同步；否则结束消息同步；

步骤A：所述消息中心向统一消息服务器获取仅在统一消息服务器中存在的用户统一消息列表，统一消息服务器将所述仅在统一消息服务器中存在的用户统一消息列表发送给所述消息中心，结束消息同步。

其中在被动同步中，所述消息中心向统一消息服务器发送同步通知具体执行以下步骤：

用户登陆消息中心，消息中心向统一消息服务器发送同步通知。

在主动同步中，所述消息中心向统一消息服务器发送同步通知具体执行以下步骤：

步骤11、用户通过统一消息服务器执行统一消息的修改、删除及添加操作时，如果所述操作的通知未能到达消息中心，则将所述用户的身份标识存入统一消息服务器的数据库中；否则结束同步处理；

步骤12、所述统一消息服务器定时将所述数据库中的用户身份标识列表发送给所述消息中心；

步骤13、所述消息中心接收到所述用户身份标识列表后，将所述用户身份标识列表添加到消息中心的数据库中；

步骤14、如果成功添加，则向所述统一消息服务器返回成功响应消息；否则返回失败响应消息；

步骤15、所述统一消息服务器收到所述成功响应消息，则将所述用户身份标识列表删除；否则结束同步处理；

步骤16、重复执行步骤12到15，直到所述统一消息服务器的数据库中的用户身份标识列表完全发送到消息中心。

所述步骤12具体为：

所述统一消息服务器定时将所述数据库中的用户身份标识列表发送给所述消息中心，并约定所述用户身份标识列表中用户身份标识的最大个数。

所述消息中心收集所述消息中心存储的用户的统一消息信息中的所述统一消息信息具体采用所述用户的统一消息列表及消息大小。

所述对比两方存储的用户的统一消息信息的差异具体采用以下方法：

将所述消息中心存储的统一消息标识的地址存入一个哈希表中；

用所述统一消息服务器中存储的每个统一消息标识作为键值在所述哈希表中查找；

判断所述统一消息标识是否存在，如果是，则清除所述哈希表中的该项，将所述哈希表中保存的统一消息标识存储在仅在消息中心存在的统一消息标识列表中，清除所述哈希表；否则将所述统一消息标识存储在仅在所述统一消息服务器中存在的统一消息标识列表中，结束。

所述统一消息服务器将所述仅在统一消息服务器中存在的用户统一消息发送给所述消息中心之后还包括以下步骤：

所述消息中心收到所述获取通知的响应后，将所述响应保存到所述用户的邮箱中。

被动同步、主动同步处理流程和用户手工同步相结合，有如下的优点：

1、主动同步流程在系统配置的闲时开始，集中处理用户UM消息同步。主动同步在用户信息采集之前对用户的UM消息进行同步，避免因用户UM消息不同步导致系统计费不准确。进行主动同步处理时，不对系统所有用户进行处理，仅对系统记录的可能存在不同步的用户进行处理，而且处理的开始时间为系统的闲时，不会对系统性能造成冲击。

2、被动同步处理流程由用户登陆操作触发，而用户登录操作具有随机性。UM消息同步流程正好利用用户登陆的随机性，使得用户同步操作不是全部集中进行，减小了因同步操作对系统消息入库处理和用户访问的性能影响。

3、被动同步处理，在用户登录系统时完成。如果用户的UM消息存在不一致，则在同步完成之后即可一致。这样避免系统故障降低用户使用MC系统服务体验。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

图1为本发明消息同步的方法的实施例一的流程图；

图2为本发明消息同步的方法的实施例一中UM消息ID hash表的结构图。

具体实施方式

本发明旨在提供一种消息同步的方法，采用不同的触发方式，对比所述消息中心和所述统一消息服务器两方存储的用户的统一消息信息的差异，完成消息同步，从而解决MC和UM server之间因连接断开或者MC故障造成的问题。

由于消息实体存储在UM server，消息摘要存储于MC，该方案以UM server的消息存储为基准，同步的最终结果保持用户在UM server的邮件与MC的消息摘要完全对应。

如图1所示，为本发明消息同步的方法的实施例一的流程图，为被动同步的流程，具体执行以下步骤：

步骤101、用户登陆消息中心，该登陆操作触发UM消息同步，MC向UMsever发送同步通知；

步骤102、所述MC收集所述MC存储的用户的UM信息，该UM信息为UM消息列表及消息的大小；

步骤103、所述UM sever接收到所述同步通知后，收集所述UM server存储的所述用户的UM信息，该UM信息同样为UM消息列表及消息的大小，并以同步通知响应的方式，将所述UM sever存储的所述用户的UM信息发送给所述MC；

步骤104、所述MC收到所述同步通知响应后，对比两方存储的所述用户的UM信息的差异；

本发明在MC端实现了一种高效的对比算法，该算法的输入为：MC和UMserver两侧用户的UM消息ID列表(按照UM Server和MC接口协议，UM消息ID均唯一)；该算法的输出为：仅在对端存在的消息ID列表；

该算法的基本流程如下：

1、将ID个数最少的UM消息ID列表中的ID插入hash表中，此处假设UM server中存在的UM消息ID列表数目最少；

首先使用自定义的hash算法计算出UM消息ID对应的hash值，并根据hash值将UM消息ID地址存入hash表中，如果计算出的hash值无效，则直接将hash值递增，根据hash值将UM消息ID地址存入hash表中；

如图2所示，该hash算法描述如下，图中第一个列表为hash表，第二个列表为UM server中UM消息ID列表地址缓存区，缓存区大小为size，第三个列表为从UM server获取的ID列表，第四个列表为MC中UM消息ID列表：

Hash算法

UINT32 Hash(char*pszStr)

{

  UInt 32 h＝0；

  for(INT I＝0；I＜UM消息ID最大长度&& pszStr[I]！＝0；I++)

  {

    h＝(h＜＜5)+((Char)*pszStr[I]-‘0’)^2*I^2；

  }

返回h；

}

该算法将每个字符的位置信息引入到hash计算中，这样对由完全相同的字符构成的字符串计算出的hash值极少出现一样的情况(如果两个不一样的字符串所得到的hash值一样，就会增加字符串比较的次数，添加消息ID和对比消息ID的算法性能就会受到影响)；

将UM server处获取的UM消息ID列表加入到内存中的处理步骤：

(1)调用Hash()函数，获取UM server中UM消息ID的hash值h；

(2)重新调整hash值：h＝h &(hash表的size-1)；

(3)查看UM server中UM消息ID的地址缓存区中第h项是否有ID地址；

如果无，则填入将UM消息ID地址填入该项；

如果有，则比较该处指向的UM消息ID是否与当前消息ID相同，相同则不添加(异常情况，UM消息需要全局唯一)，否则h++重试步骤3直到找到一个空项填入UM消息ID的地址；

(4)hash表的used项+1；

(5)如果hash表的used项超过了uselimit，则扩展UM server中UM消息ID的地址缓存区的大小为原来的2倍，并重新hash所有已存入的UM消息地址；

2、以MC中UM消息ID列表中的每个ID作为键值从hash表中查找；

对比消息ID的算法：

(1)调用Hash函数，获取MC中UM消息ID的hash值；

(2)重新调整hash值：h＝h &(hash表的size-1)；

(3)查看UM server中UM消息ID的地址缓存区中第h项是否有ID地址；

如果无，表示该UM消息ID仅在MC中存在，将该ID地址填入仅在MC中存在的UM消息ID地址列表中；

如果有，则比较该处指向的UM消息ID是否与当前消息ID相同，相同则表示该UM消息ID在UM server和MC均存在，擦除该项；否则h++重试步骤(3)，直到遇到一个空项；

(4)重复步骤(1)～(3)的直到MC中UM消息ID全部比较完毕；

(5)遍历Hash表，将其中有效项加入仅在UM server中存在的消息ID地址列表中；

如果MC中UM消息ID列表或者UM server中UM消息ID列表为空，则直接输出结果；

该算法引入hash表，并结合UM消息ID唯一性的特点，使得UM消息ID列表的对比操作时间和空间效率均相当高效；

该hash表以UM消息ID字符串作为键，以消息ID地址作为值，并且将UM消息ID通过特殊设计的hash算法转换为整数，该算法可在UM消息ID地址缓冲区一定的条件下，最大限度的避免hash值无效，减少字符串比较；

该hash表用以保存UM消息ID起始指针，不保存UM消息ID列表，额外的存储开销很小，并且缓冲区可根据实际ID个数扩展；

步骤105、根据所述对比的结果，判断是否存在仅在UM sever中存在的用户UM消息，如果是，则执行步骤106；否则执行步骤109；

步骤106、所述MC向UM sever发送获取通知，用于获取所述仅在UM sever中存在的用户UM消息列表；

步骤107、UM sever接收到所述获取通知后，在获取通知的响应中将所述仅在UM sever中存在的用户UM消息列表发送给所述MC；

步骤108、MC收到所述获取通知的响应后，将所述响应消息保存到所述用户的邮箱中，执行步骤110；

步骤109、MC判断是否存在仅存储在MC的用户UM，如果是，则删除仅在MC存储的用户UM；否则执行下一步；

步骤110、结束消息同步。

被动同步处理流程由用户登陆操作触发，而用户登录操作具有随机性。UM消息同步流程正好利用用户登陆的随机性，使得用户同步操作不是全部集中进行，减小了因同步操作对系统消息入库处理和用户访问的性能影响。

被动同步处理在用户登录系统时完成。如果用户的UM消息存在不一致，则在同步完成之后即可一致。这样避免系统故障降低用户使用MC系统服务体验。

该流程还具有以下优点

1、将UM的消息同步启动分散到随机时机，减少对双方系统目前执行的业务处理的冲击，增强了系统的健壮性，增强用户对MC系统的综合使用体验。

2、UM的消息同步过程操作做到了比较大的并行处理，提高系统的运行效率和缩短同步时间。在上述的流程中第102步处理和第103步处理是并行处理的，第106步和第107步处理也是并行处理的。

3、同步的发起均由MC控制，简化了UM server处理逻辑和实现难度。

实施例二为主动同步的流程，它与被动同步的差别主要在于：

同步处理触发的时机不同；

同步处理的用户数量不同，被动同步仅处理当前登陆的用户UM消息同步，主动同步处理UM server报告的可能存在不同步的所有用户；但是主动同步处理在处理每个用户的UM消息同步时与被动同步的相应流程相同；

被动同步仅从UM server侧获取一定数量的UM消息摘要，而主动同步将分多次从UM server中获取该用户的UM消息摘要，直到完全同步。

主动同步执行以下步骤：

步骤201、用户通过UM Server执行UM消息修改、删除和添加操作时，如果未能将该操作通知到MC，则将该用户的MSISDN存入数据库表中，该数据库表要求用户MSISDN唯一；

步骤202、UM Server定时尝试将该数据库表中的内容发送给MC，如果UM Server该次尝试不成功，则等待下次尝试；定时时长可配置，建议为5分钟到30分钟，UM Server和MC同步协议中约定每条消息中最大用户ID个数；

步骤203、MC收到UM Server发送的用户身份标识列表消息，将这些用户的信息保存到数据库表中，该数据库表要求用户MSISDN唯一；如果添加成功则返回UM server成功响应消息，否则返回失败响应消息；

步骤204、UM Server收到MC响应消息，如果MC处理成功则将添加到MC中用户ID列表删除；如果MC数据库操作失败或者异常，则结束该次用户身份标识列表发送，结束同步处理；

步骤205、重复执行步骤202～204，直到将数据库表中的用户身份标识列表完全发送到MC。

MC在系统设定的闲时开始主动同步处理任务。该任务从数据库中获取需要同步的用户ID，并按照被动同步中102～110步骤处理同步。

主动同步流程在系统配置的闲时开始，集中处理用户UM消息同步。主动同步在用户信息采集之前对用户的UM消息进行同步，避免因用户UM消息不同步导致系统计费不准确。进行主动同步处理时，不对系统所有用户进行处理，仅对系统记录的可能存在不同步的用户进行处理，而且处理的开始时间为系统的闲时，不会对系统性能造成冲击。

实施例三为手工同步的流程：

用户登录MC之后，可执行手动同步，由用户主动发起UM消息同步。系统为减少不必要的性能开销，对手工同步设置了如下的约束条件：

如果被动同步任务正在执行过程中，则不启动手工同步；

如果被动同步执行后UM server仍然持有MC中不存在的UM消息，则启动手工同步任务，否则不启动手工同步任务。

手工同步的处理流程与被动同步流程102～110步骤相同。

手工同步处理流程是对被动同步处理流程和主动同步处理流程的补充。主动同步处理的时间是在系统闲时集中进行处理。被动同步由用户登录操作触发，并且为了对减小对系统及网络通信造成过大冲击，每次同步UM消息的数量有限。因此，需要手工同步来弥补前两种同步方式的“盲点”，进一步提升MC用户使用体验。

最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的精神和范围。

Claims (7)

1.一种消息同步的方法，其特征在于，该方法包括：

消息中心向统一消息服务器发送同步通知；

所述消息中心收集所述消息中心存储的用户的统一消息信息；

所述统一消息服务器接收到所述同步通知后，收集所述统一消息服务器存储的用户的统一消息信息，并将所述用户的统一消息信息发送给所述消息中心；

所述消息中心对比所述消息中心和所述统一消息服务器两方存储的用户的统一消息信息的差异，判断是否存在仅存储在统一消息服务器中的用户统一消息，如果是，则继续步骤A；否则判断是否存在仅存储在消息中心的用户统一消息，如果是，则删除仅在消息中心存储的用户统一消息，结束消息同步；

步骤A：所述消息中心向统一消息服务器获取仅在统一消息服务器中存在的用户统一消息列表，统一消息服务器将所述仅在统一消息服务器中存在的用户统一消息列表发送给所述消息中心，结束消息同步。

2.根据权利要求1所述的消息同步的方法，其特征在于，所述消息中心向统一消息服务器发送同步通知进一步包括：

用户登陆消息中心，消息中心向统一消息服务器发送同步通知。

3.根据权利要求1所述的消息同步的方法，其特征在于，所述消息中心向统一消息服务器发送同步通知具体包括：

步骤11、用户通过统一消息服务器执行统一消息的修改、删除及添加操作时，如果所述操作的通知未能到达消息中心，则将所述用户的身份标识存入统一消息服务器的数据库中；否则结束同步处理；

步骤12、所述统一消息服务器定时将所述数据库中的用户身份标识列表发送给所述消息中心；

步骤13、所述消息中心接收到所述用户身份标识列表后，将所述用户身份标识列表添加到消息中心的数据库中；

步骤14、如果成功添加，则向所述统一消息服务器返回成功响应消息；否则返回失败响应消息；

步骤15、所述统一消息服务器收到所述成功响应消息，则将所述用户身份标识列表删除；否则结束同步处理；

步骤16、重复执行步骤12到15，直到所述统一消息服务器的数据库中的用户身份标识列表完全发送到消息中心。

4.根据权利要求3所述的消息同步的方法，其特征在于，所述步骤12具体为：

所述统一消息服务器定时将所述数据库中的用户身份标识列表发送给所述消息中心，并约定所述用户身份标识列表中用户身份标识的最大个数。

5.根据权利要求1、2、3或4所述的消息同步的方法，其特征在于，所述消息中心收集所述消息中心存储的用户的统一消息信息中的统一消息信息具体包含所述用户的统一消息列表及消息大小。

6.根据权利要求1、2、3或4所述的消息同步的方法，其特征在于，所述对比所述消息中心和所述统一消息服务器两方存储的用户的统一消息信息的差异具体采用以下方法：

将所述消息中心存储的统一消息标识的地址存入一个哈希表中；

用所述统一消息服务器中存储的每个统一消息标识作为键值在所述哈希表中查找；

判断所述统一消息标识是否存在，如果是，则清除所述哈希表中的该项，将所述哈希表中保存的统一消息标识存储在仅在消息中心存在的统一消息标识列表中，清除所述哈希表；否则将所述统一消息标识存储在仅在所述统一消息服务器中存在的统一消息标识列表中，结束。

7.根据权利要求1、2、3或4所述的消息同步的方法，其特征在于，所述统一消息服务器将所述仅在统一消息服务器中存在的用户统一消息列表发送给所述消息中心之后还包括以下步骤：

所述消息中心收到所述获取通知的响应后，将所述响应保存到所述用户的邮箱中。