CN101854603A - 一种处理多媒体消息业务的方法及装置 - Google Patents

Abstract

本发明公开了一种处理多媒体消息业务的方法，包括：对cache进行初始化处理；多媒体消息业务中心(MMSC)收到业务发起方提交的彩信体后，依据cache中用于存放彩信体的存储空间循环使用的规则，将提交的彩信体依次存储到cache，并向接收方终端发送获取彩信体的通知；MMSC收到接收方终端发送的获取请求后，从cache中读到请求的彩信体，并向接收方终端返回所述请求的彩信体。本发明同时公开了一种处理多媒体消息业务的装置，采用本发明的方法及装置，能减少对存储设备的I/O读与写操作。

Description

一种处理多媒体消息业务的方法及装置

技术领域

本发明涉及多媒体消息业务中心(MMSC，Multimedia Messaging ServiceCenter)业务处理技术，特别是指一种处理多媒体消息业务的方法及装置。

背景技术

多媒体消息业务是一种全新的、能够在手机与手机之间和手机与E-mail服务器等其它应用之间传送多媒体内容的消息服务。与目前已成功应用的文本形式的短消息业务相比，多媒体消息业务能为用户提供包括图像、声音等多种媒体格式的消息，从而使运营商可以为用户提供丰富的、个性化的服务。举个例子来说，中国移动提供的手机报业务，改变了传统报纸的发行方式。具体地讲，传统的纸质报纸需要印刷，并需要投入大量的人力和物力将报纸投送到用户手中，而手机报则采用彩信形式，直接将报纸内容发送到用户的手机当中，这种方式方便、快捷，而且节约了大量的社会劳动成本。

一条短消息的内容最大只有140个字节(Bytes)，通常采用商用数据库实现消息的存储和管理，现有磁盘阵列的I/O性能可以达到每秒几千条短消息的处理能力。但是，一条多媒体消息的内容要比短消息的内容大得多，目前一般为100Kbytes左右，而且，多媒体消息业务的协议规范并没有对多媒体消息内容的大小做限制，因此，随着终端能力的提高，一条多媒体消息的内容将会越来越大。由于多媒体消息业务是非实时业务，所以通常的处理方法是：当MMSC收到发起方提交的多媒体消息后，先将收到的多媒体消息存储在多媒体消息服务(MMS，Multimedia Messaging Service)存储服务器中，然后再对收到的多媒体消息进行转发。所述多媒体消息即为彩信。具体地，MMS存储服务器收到业务处理模块发来的多媒体消息后，以文件的形式把彩信存储在MMS存储服务器中，并将彩信的索引作为用户数据存放在数据库中；完成对彩信的读取、删除等操作。MMS存储服务器可以是网络附加存储(NAS，Network AttachedStorage)、或者存储局域网(SAN，Storage Area Network)。

但是，无论MMS存储服务器采用上述的哪种方式实现，它的I/O吞吐性能都是有限的，主要表现在以下两个方面：

第一，磁盘的性能限制了I/O吞吐性能。现在业内最大的磁盘转速是15000转/秒，这就在物理上限制了I/O吞吐性能。

其次，从经济的角度考虑，采用高性能I/O的存储服务器需要较高的成本，从而从逻辑上限制了I/O吞吐性能。

从上面的描述中可以看出，只有减少I/O操作，MMSC才能提高对彩信业务的处理速度。

发明内容

有鉴于此，本发明的主要目的在于提供一种处理多媒体消息业务的方法及装置，能大大提高对彩信业务的处理性能，并降低MMSC对MMS存储服务器的I/O吞吐性能的要求。

为达到上述目的，本发明的技术方案是这样实现的：

本发明提供了一种处理多媒体消息业务的方法，对cache进行初始化处理；该方法还包括：

MMSC收到业务发起方提交的彩信体后，依据cache中用于存放彩信体的存储空间循环使用的规则，将提交的彩信体依次存储到cache，并向接收方终端发送获取彩信体的通知；

MMSC收到接收方终端发送的获取请求后，从cache中读到请求的彩信体，并向接收方终端返回所述请求的彩信体。

上述方案中，该方法进一步包括：

将cache中的彩信码流同步存储到物理磁盘。

上述方案中，MMSC确定接收方终端已成功获取所述请求的彩信体后，该方法进一步包括：

删除cache中存储的所述请求的彩信体。

上述方案中，所述对cache进行初始化处理具体为：

读取配置文件，根据配置文件中cache对应的标识，获得cache的大小及彩信体的平均大小，并计算控制节点的个数，之后创建cache；

确定创建成功后，将cache映射到进程空间中；

将cache中的控制节点的索引信息初始化为零，并在cache中生成一个空闲的控制节点队列；

将获得的空闲的控制节点队列的首节点的地址写入cache的第二个单元中；并将获得的全局指针(CurPtr)存入cache的第二个单元。

上述方案中，所述将提交的彩信体依次存储到cache，具体为：

从空闲的控制节点队列中取得一个空闲的控制节点；

判断cache中用于存储彩信码流的存储空间是否为第一次使用、或二次以上循环使用，确定是第一次使用时，判断cache中用于存储彩信码流的剩余存储空间是否能存储下本次需要存储的彩信码流，确定能存储下本次需要存储的彩信码流时，将本次需要存储的彩信码流写入到CurPtr指示的地址，并进行相关信息的更新；

确定不能存储下本次需要存储的彩信码流时，将CurPtr移至cache存放彩信码流的初始位置，判断当前能使用的存储空间是否能存储下本次需要存储的彩信码流，确定能存储下时，将本次需要存储的彩信码流写入到CurPtr指示的地址，并进行相关信息的更新；

确定当前能使用的存储空间不能存储下本次需要存储的彩信码流时，判断已使用的控制节点队列的首节点对应的彩信码流是否已同步到物理磁盘，确定已同步到物理磁盘时，删除首节点信息，相应的，更新红黑树数据库、以及CurPtr；再次判断当前能使用的存储空间是否能存储下本次需要存储的彩信码流，如此循环，直至将本次需要存储的彩信码流写入到CurPtr指示的地址，并进行相关信息的更新。

上述方案中，该方法还包括：

确定cache中用于存储彩信码流的存储空间是二次以上循环使用时，判断当前能使用的存储空间是否能存储下本次需要存储的彩信码流，确定能存储下时，将本次需要存储的彩信码流写入到CurPtr指示的地址，并进行相关信息的更新；

确定当前能使用的存储空间不能存储下本次需要存储的彩信码流时，判断已使用的控制节点队列的首节点对应的彩信码流是否已同步到物理磁盘，确定已同步到物理磁盘时，删除首节点信息，相应的，更新红黑树数据库、以及CurPtr；

判断当前的首节点对应的彩信码流在cache中的地址是否等于cache中存放彩信码流的初始地址，确定等于时，再次判断cache中用于存储彩信码流的剩余存储空间是否能存储下本次需要存储的彩信码流，如此循环，直至将本次需要存储的彩信码流写入到CurPtr指示的地址，并进行相关信息的更新；

确定当前的首节点对应的彩信码流在cache中的地址不等于cache中存放彩信码流的初始地址时，再次判断当前能使用的存储空间是否能存储下本次需要存储的彩信码流，如此循环，直至将本次需要存储的彩信码流写入到CurPtr指示的地址，并进行相关信息的更新。

上述方案中，所述从cache中读到请求的彩信体，具体为：

MMSC收到接收方终端发送的包含网页地址(URL)的链接的获取请求后，根据URL获得相应彩信体对应的msgid；

通过所述msgid查找红黑树数据库中所述msgid对应的控制节点，获得彩信码流在cache中的地址及长度；

将彩信码流从cache中读出，并向接收方终端返回所述请求的彩信体。

上述方案中，所述将cache中的彩信码流同步存储到物理磁盘，具体为：

定时器超时后，判断已使用的控制节点队列的首节点对应的彩信码流是否已同步到物理磁盘，确定没有同步到物理磁盘时，将该节点对应的彩信码流存储到物理磁盘，并将彩信码流已同步到物理磁盘的标识写入该节点信息，同时更新红黑树数据库对应的节点信息；

确定已同步到物理磁盘时，或者，同步过程执行完成后，处理下一个节点；

判断是否处理到已使用的控制节点队列的最后一个控制节点，确定不是时，判断同步过程执行的时间是否超过预设阈值，确定超过时，结束同步过程。

上述方案中，所述删除cache中存储的所述请求的彩信体，具体为：

MMSC判断出接收方终端已成功获取所述请求的彩信体，通过所述请求的彩信体对应的msgid，查找红黑树数据库中所述msgid对应的控制节点；

确定能找到时，判断所述msgid对应的控制节点信息中的接收地址是否是单目的地址；

确定控制节点信息中的接收地址是单目的地址时，判断所述msgid对应的控制节点对应的彩信码流是否已同步到物理磁盘，确定控制节点对应的彩信码流没有同步到物理磁盘时，将彩信码流已同步到物理磁盘的标识写入所述msgid对应的控制节点信息，相应的，更新cache中的相应的控制节点信息。

本发明还提供了一种处理多媒体消息业务的装置，该装置包括：初始化单元、cache、处理单元、以及发送单元；其中，

初始化单元，用于对cache进行初始化处理；

处理单元，用于MMSC收到业务发起方提交的彩信体后，依据cache中用于存放彩信体的存储空间循环使用的规则，将提交的彩信体依次存储到cache，并向接收方终端发送获取彩信体的通知；

发送单元，用于MMSC收到接收方终端发送的获取请求后，从cache中读到请求的彩信体，并向接收方终端返回所述请求的彩信体；

cache，用于被初始化单元进行初始化处理，并存储业务发起方提交的彩信体。

上述方案中，该装置进一步包括：

删除单元，用于MMSC确定出接收方终端已成功获取所述请求的彩信体后，删除cache中存储的所述请求的彩信体；和/或，

同步单元，用于将cache中存储的彩信码流同步存储到物理磁盘；

物理磁盘，用于存储彩信码流。

本发明提供的处理多媒体消息业务的方法及装置，MMSC收到业务发起方提交的彩信体后，依据cache中用于存放彩信体的存储空间循环使用的规则，将提交的彩信体依次存储到cache中，并向接收方终端发送获取彩信体的通知；MMSC收到接收方终端发送的获取请求后，从cache中读到请求的彩信体，并向接收方终端返回所述请求的彩信体，如此，能减少对存储设备的I/O读操作；

另一方面，在接收方终端成功获取彩信体后，将彩信码流已同步到物理磁盘的标识写入所述msgid对应的控制节点信息中，相应的，更新cache中的相应的控制节点信息，彩信码流已同步到物理磁盘的标识写入控制节点信息后，所述msgid对应的控制节点对应的彩信码流即为无效码流，不需要存入存储设备中，如此，能减少对存储设备的I/O写操作。

根据本发明提供的方案，无论是从逻辑上还是从物理上，都不会限制I/O吞吐性能，提高了对彩信业务的处理速度。

附图说明

图1为本发明处理多媒体消息业务的方法流程示意图；

图2为实现图1所示流程图中步骤100的方法流程示意图；

图3为实现图1所示流程图中步骤101的方法流程示意图；

图4为实现图1所示流程图中步骤102的方法流程示意图；

图5为本发明MMSC确定接收方终端已成功获取所述请求的彩信体后的方法流程示意图；

图6为本发明将cache中的彩信码流同步存储到物理磁盘的方法流程示意图；

图7为处理多媒体消息业务的装置结构示意图。

具体实施方式

现有MMSC处理彩信业务的模式是：先存储再转发的模式，即：对业务发起方提交的彩信，MMSC首先需要将彩信体存储到存储设备，然后再下发一个包含URL的链接的通告给接收方终端，接收方终端通过URL的链接到MMSC获取彩信体。MMSC收到接收方终端发来的获取请求后，将彩信体从存储设备上读取出来，返回给接收方终端，从而完成彩信的业务流程。因此，本发明的基本思想是：对业务发起方提交的彩信体，暂时先将彩信体存储到cache中，当MMSC收到接收方终端发来的获取请求后，直接从cache中找到彩信体，返回给接收方终端，如此，可以减少对存储设备的I/O读操作；另一方面，在接收方终端成功获取彩信体后，MMSC触发一条在cache中删除该彩信体的信令，如此，可以减少对存储设备的I/O写操作。

下面结合附图及具体实施例对本发明再作进一步详细的说明。

本发明处理多媒体消息业务的方法如图1所示，包括以下步骤：

步骤100：对cache进行初始化处理。

步骤101：MMSC收到业务发起方提交的彩信体后，依据cache中用于存放彩信体的存储空间循环使用的规则，将提交的彩信体依次存储到cache，并向接收方终端发送获取彩信体的通知。

步骤102：MMSC收到接收方终端发送的获取请求后，从cache中读到请求的彩信体，并向接收方终端返回所述请求的彩信体。

其中，步骤100的实现过程如图2所示，包括以下步骤：

步骤201：读取配置文件，根据配置文件中cache对应的标识(key)，获得cache的大小及彩信体的平均大小，并计算控制节点的个数，之后创建cache；

这里，所述配置文件包括：cache对应的key、cache的大小、以及彩信体的平均大小等；配置文件要预先配置，在配置时，根据MMSC的服务器系统内存的大小配置cache的大小，并为cache设置一个对应的key，以便能根据key找到关于cache的配置参数，所述配置参数包括：cache的大小、以及彩信体的平均大小等。一般，彩信体的平均大小可以根据经验进行设置，比如：现网中彩信体的平均大小约为20k，因此，可以配置彩信体的平均大小约为20k；根据cache的大小及彩信体的平均大小便能够计算出控制节点的个数，每个控制节点对应一条彩信体，有多少个控制节点就代表cache最多能存放的彩信体数目；

创建cache可以通过调用操作系统的创建子系统完成，并在创建完成后会返回创建成功还是失败的结果；

创建时，cache的第一个单元用于存放已使用的控制节点队列的首节点的地址，第二个单元用于存放空闲的控制节点队列的首节点的地址，第三个单元用于存放CurPtr，紧接着的地址用于存放控制节点信息，控制节点信息存放完后的地址到cache的尾部用于存放彩信码流，彩信码流为彩信体的具体内容；所述CurPtr，用于指示当前cache中能写彩信码流的起始位置；其中，第一个单元与第二个单元存放的内容可以称为控制节点的索引信息；

如此创建，可以根据索引信息迅速找到对应的控制节点，相应的，根据找到的控制节点可以迅速地找到控制节点对应的彩信码流。

步骤202：判断创建是否成功，如果成功，则执行步骤203，否则，执行步骤208。

创建成功后，已使用的控制节点队列的首节点的地址会存放在cache的第一个单元中，空闲的控制节点队列的首节点的地址会存放在cache的第二个单元中。

步骤203：将cache映射到进程空间中，之后执行步骤204；

这里，将cache映射到进程空间中后，cache对应的进程就可以访问cache中的内容。

步骤204：将cache中的控制节点的索引信息初始化为零，并在cache中生成一个空闲的控制节点队列；

步骤205～206：空闲的控制节点队列生成后，将获得的空闲的控制节点队列的首节点的地址存入cache的第二个单元；并将获得的CurPtr写入cache的第二个单元，结束初始化过程；

此时，CurPtr为cache中能写彩信码流的初始地址；

由于此时只有空闲的控制节点队列，所以不会创建红黑树数据库。

步骤207：出错退出。

其中，上面描述的创建cache的过程，是指在MMSC的服务器系统内的初次创建；当MMSC的服务器系统发生断电、或死机后重等情况后，也需要重新创建cache，此时，cache中存储的信息不会在MMSC的服务器系统断电、或死机后重启等条件下发生消失，因此，同样需要执行步骤201～203，之后创建红黑树数据库，并将CurPtr存入cache的第三个单元，结束初始化过程；

其中，红黑树数据库中存放的数据包括：每个彩信体的彩信码流的长度、相应的彩信码流在cache中的地址、彩信体对应的key、群发标识、以及彩信码流已同步到物理磁盘的标识等；其中，彩信体对应的key为彩信体的msgid，每个彩信体的msgid是不相同的，因此，每个彩信体对应的key也不相同，如此，在索引所需的彩信体时不会出错；红黑树数据库中存放的数据与cache中控制节点信息相同，即：控制节点信息包括：彩信码流的长度、彩信码流在cache中的地址、群发标识、彩信体对应的key、以及彩信码流已同步到物理磁盘的标识等；其中，key是用于索引彩信体的；

创建红黑树数据库的目的是为了接收方终端在获取彩信时，能根据红黑树数据库的数据，在cache中快速检索到要获取的彩信体；

红黑树数据库中的数据随着cache中控制节点信息的变化动态发生变化，与cache中控制节点信息同步；并且，在MMSC相应的服务器系统断电、或死机重启后，红黑树数据库中的数据也随之消失；

根据cache中已使用的控制节点队列的尾节点信息中的地址、以及彩信体的彩信码流的长度、即可计算出CurPtr。

上述过程中，步骤101的实现过程如图3所示，包括以下步骤：

步骤301：MMSC收到业务发起方提交的彩信体后，从空闲的控制节点队列中取得一个空闲的控制节点，之后执行步骤302；

这里，如果从空闲的控制节点队列中不能得到一个空闲的控制节点，说明cache所存的彩信体已满，此时，MMSC可以直接将提交的彩信体存储到物理磁盘。

步骤302：判断cache中用于存储彩信码流的存储空间是否为第一次使用，如果是，则执行步骤303，否则，执行步骤305；

这里，判断cache中用于存储彩信码流的存储空间是否为第一次使用，具体为：从已使用的控制节点队列的首节点信息中获取对应的彩信码流在cache中的地址(HeadPtr)，判断HeadPtr是否小于CurPtr，如果HeadPtr小于CurPtr，则说明cache中用于存储彩信码流的存储空间是第一次使用，如果HeadPtr大于等于CurPtr，则说明cache中用于存储彩信码流的存储空间不是第一次使用，而是二次以上的循环使用。

步骤303：判断cache中用于存储彩信码流的剩余存储空间是否能存储下本次需要存储的彩信码流，如果是，则执行步骤309；否则，执行步骤304；

这里，所述判断cache中用于存储彩信码流的剩余存储空间是否能存储下本次需要存储的彩信码流，具体为：

CurPtr到cache尾部的长度是否大于本次需要存储的彩信码流的长度(Len)，如果大于，则说明cache中用于存储彩信码流的剩余存储空间能存储下本次需要存储的彩信码流，否则，说明cache中用于存储彩信码流的剩余存储空间不能存储下本次需要存储的彩信码流；

当cache中用于存储彩信码流的存储空间为第一次使用时，要从用于存储彩信码流的存储空间的初始位置依次存放彩信码流，在存放彩信码流之前，需要判断CurPtr到cache尾部的空间是否能放得下当前需要存储的彩信码流；

如果小于，说明CurPtr到cache尾部的空间放不下本次需要存储的彩信码流，需要将CurPtr移至cache存放彩信码流的初始位置。

步骤304：将CurPtr移至cache存放彩信码流的初始位置，之后执行步骤305。

步骤305：判断当前能使用的存储空间是否能存储下本次需要存储的彩信码流，如果是，则执行步骤309，否则，执行步骤306；

这里，所述判断当前能使用的存储空间是否能存放存储下本次需要存储的彩信码流，具体为：判断CurPtr-HeadPtr是否大于等于本次需要存储的彩信码流的Len，如果CurPtr-HeadPtr大于等于本次需要存储的彩信码流的Len，则说明CurPtr到HeadPtr之间缓存区的大小，即：当前能使用的存储空间，可以存放本次需要存储的彩信码流；如果小于，则说明CurPtr到HeadPtr之间的存储空间，即：当前能使用的存储空间，不足以存放本次需要存储的彩信码流，需要对原先存储的已使用的控制节点队列的首节点对应的彩信码流进行覆盖。

步骤306：判断已使用的控制节点队列的首节点对应的彩信码流是否已同步到物理磁盘，如果是，则执行步骤307，否则，执行步骤310；

这里，所述判断已使用的控制节点队列的首节点对应的彩信码流是否已同步到物理磁盘，具体为：从已使用的控制节点队列的首节点信息中获取彩信码流已同步到物理磁盘的标识，如果能获取到，则说明首节点对应的彩信码流已同步到物理磁盘，如果不能获取到，则说明首节点对应的彩信码流没有同步到物理磁盘；

如果已使用的控制节点队列的首节点对应的彩信码流已同步到物理磁盘，则说明已使用的控制节点队列的首节点对应的彩信码流可以被覆盖。

步骤307：删除该控制节点信息，相应的，更新红黑树数据库、以及CurPtr，之后执行步骤308；

这里，所述删除、更新，具体为：

从已使用的控制节点的队列删除该控制节点信息，清空后将该控制节点插入到空闲的控制节点的队列中，同时，根据msgid，从红黑树数据库中删除对应的控制节点信息，并更新CurPtr；

该控制节点信息被删除后，已使用的控制节点的队列的第二个控制节点会成为新的首节点，相应的，cache中的控制节点的索引信息也会发生变化，换句话说，cache中的控制节点的索引信息及CurPtr会随着控制节点的信息及控制节点对应的彩信码流的变化而发生变化。

步骤308：判断当前的HeadPtr是否等于cache中存放彩信码流的初始地址，如果等于，执行步骤303，否则，执行步骤305；

这里，如果当前的HeadPtr等于cache中存放彩信码流的初始地址，说明有效的彩信码流已经转到cache可以存放彩信码流的初始位置，向cache继续写彩信码流的话不存在覆盖原先有效的彩信码流的问题；

所述有效的彩信码流是指还未同步到物理磁盘的彩信码流，即：彩信码流对应的控制节点信息中没有彩信码流已同步到物理磁盘的标识；

已使用的控制节点队列的首节点对应的彩信码流被覆盖后，可使用的存放空间不一定能存储得下本次需要存储的彩信码流，因此，需要执行步骤305，再次判断CurPtr-HeadPtr是否大于等于本次需要存储的彩信码流的Len，此时，HeadPtr为已使用的控制节点的队列的第二个控制节点对应的存放彩信码流的地址。

步骤309：将本次需要存储的彩信码流写入到CurPtr指示的地址，并进行相关信息的更新；

这里，所述进行相关信息的更新，具体为：

将与本次需要存储的彩信码流的相关信息写入控制节点，之后将所述控制节点加入到已使用的控制节点队列，相应的，将控制节点信息插入到红黑树数据库中，并使CurPtr移动至CurPtr+Len的地址；

本步骤动作执行完，说明本次在cache中的存储成功。

步骤310：将本次需要存储的彩信码流存储到物理磁盘；

此时，说明本次在cache中的存储失败。

上述过程中，步骤102的实现过程如图4所示，包括以下步骤：

步骤401：MMSC收到接收方终端发送的包含URL的链接的获取请求后，根据URL获得相应彩信体对应的msgid；

这里，MMSC事先存储URL及URL相应的彩信体对应的msgid。

步骤402：通过所述msgid查找红黑树数据库中所述msgid对应的控制节点，获得彩信码流在cache中的地址及长度，之后执行步骤403；

这里，如果通过所述msgid没有查找红黑树数据库中所述msgid对应的控制节点，说明在获取之前，彩信码流已经被同步到物理磁盘中了，此时，需要根据msgid找到彩信码流对应的文件路径，通过文件路径，从物理磁盘中读出彩信码流，并向接收方终端返回所述请求的彩信体。

步骤403：将彩信码流从cache中读出，并向接收方终端返回所述请求的彩信体。

MMSC确定接收方终端已成功获取所述请求的彩信体后，可以删除cache中存储的所述请求的彩信体，如图5所示，具体包括以下步骤：

步骤501：MMSC判断出接收方终端已成功获取所述请求的彩信体，通过所述请求的彩信体对应的msgid，查找红黑树数据库中所述msgid对应的控制节点，如果能找到，则执行步骤502，如果不能找到，则不做任何处理，结束当前处理流程；

这里，接收方终端成功获取所述请求的彩信体后，会向MMSC返回一个已获取的信息，所述已获取的信息可以是用户话单，MMSC据此可以知道接收方终端已成功获取所述请求的彩信体。

步骤502：判断所述msgid对应的控制节点信息中的接收地址是否是单目的地址，如果是，则执行步骤503，否则，不做任何处理，结束当前处理流程；

这里，如果是多目的地址，则不能根据一次获取情况删除缓存中的彩信码流，此时，应不再做任何处理，结束当前处理流程。

步骤503：判断所述msgid对应的控制节点对应的彩信码流是否已同步到物理磁盘，如果是，则不做任何处理，结束当前处理流程，否则，执行步骤504；

这里，所述判断所述msgid对应的控制节点对应的彩信码流是否已同步到物理磁盘，具体为：从所述msgid对应的控制节点信息中获取彩信码流已同步到物理磁盘的标识，如果能获取到，则说明所述msgid对应的控制节点对应的彩信码流已同步到物理磁盘，如果不能获取到，则说明所述msgid对应的控制节点对应的彩信码流没有同步到物理磁盘。

步骤504：将彩信码流已同步到物理磁盘的标识写入所述msgid对应的控制节点信息中，相应的，更新cache中的相应的控制节点信息，结束当前处理流程；

这里，彩信码流已同步到物理磁盘的标识写入控制节点信息后，表明所述请求的彩信码流为无效码流，可以被其它后续存储的彩信码流覆盖；

彩信码流已同步到物理磁盘的标识写入控制节点信息后，所述msgid对应的控制节点对应的彩信码流即为无效码流，不需要存入物理磁盘中。

上述方案中，还可以包括将cache中的彩信码流同步存储到物理磁盘的过程，如图6所示，包括以下过程：

步骤601：开启定时器，定时器超时后，执行步骤602；

这里，定时器的时长可以依据需要设置，为了使同步存储能快速进行，可以设置定时器的时长为1秒。

步骤602：判断已使用的控制节点队列的首节点对应的彩信码流是否已同步到物理磁盘，如果是，则执行步骤603，否则，执行步骤604；

这里，所述判断已使用的控制节点队列的首节点对应的彩信码流是否已同步到物理磁盘，具体为：从已使用的控制节点队列的首节点信息中获取彩信码流已同步到物理磁盘的标识，如果能获取到，则说明首节点对应的彩信码流已同步到物理磁盘，如果不能获取到，则说明首节点对应的彩信码流没有同步到物理磁盘。

步骤603：处理下一个节点，判断已使用的控制节点队列的下一个节点对应的彩信码流是否已同步到物理磁盘，如果是，则执行步骤605，否则，执行步骤604。

步骤604：将该节点对应的彩信码流存储到物理磁盘，并将彩信码流已同步到物理磁盘的标识写入该节点信息，同时更新红黑树数据库对应的节点信息，之后执行步骤605；

步骤605：判断是否处理到已使用的控制节点队列的最后一个控制节点，如果是，则结束同步过程，否则，执行步骤606。

步骤606：判断同步过程执行的时间是否超过预设阈值，如果是，则结束同步过程，否则，执行步骤603；

这里，在实际应用过程中，定时器可以一直处于开启状态，超时后，则执行步骤602至605；这种情况下，需要记录同步过程执行的时间，以免影响下一次超时后的同步处理过程；此时，可以根据定时器的时长设置阈值，举个例子来说，假设定时器的时长设为1秒，则阈值的大小可以设为900毫秒，也就是说，阈值的大小要小于定时器的时长。

为实现上述方法，本发明还提供了一种处理多媒体消息业务的装置，如图7所示，该装置包括：初始化单元71、cache72、处理单元73、以及发送单元74；其中，

初始化单元71，用于对cache72进行初始化处理；

处理单元73，用于MMSC收到业务发起方提交的彩信体后，依据cache中用于存放彩信体的存储空间循环使用的规则，将提交的彩信体依次存储到cache72，并向接收方终端发送获取彩信体的通知；

发送单元74，用于MMSC收到接收方终端发送的获取请求后，从cache72中读到请求的彩信体，并向接收方终端返回所述请求的彩信体；

cache72，用于被初始化单元71进行初始化处理，并存储业务发起方提交的彩信体。

其中，该装置还可以包括：

删除单元75，用于MMSC确定出接收方终端已成功获取所述请求的彩信体后，删除cache72中存储的所述请求的彩信体；和/或，

同步单元76，用于将cache72中存储的彩信码流同步存储到物理磁盘77；

物理磁盘77，用于存储彩信码流。

所述处理单元73，还用于在确定cache72无法存储提交的彩信体后，将提交的彩信体存储到物理磁盘77；

所述发送单元74，还用于在确定cache72中没有请求的彩信体后，从物理磁盘77中读到请求的彩信体，并向接收方终端返回所述请求的彩信体。

这里，本发明的所述装置中的各个单元的具体处理过程已在上文中详述，不再赘述。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种处理多媒体消息业务的方法，其特征在于，对cache进行初始化处理；该方法还包括：

多媒体消息业务中心(MMSC)收到业务发起方提交的彩信体后，依据cache中用于存放彩信体的存储空间循环使用的规则，将提交的彩信体依次存储到cache，并向接收方终端发送获取彩信体的通知；

MMSC收到接收方终端发送的获取请求后，从cache中读到请求的彩信体，并向接收方终端返回所述请求的彩信体。

2.根据权利要求1所述的方法，其特征在于，该方法进一步包括：

将cache中的彩信码流同步存储到物理磁盘。

3.根据权利要求1或2所述的方法，其特征在于，MMSC确定接收方终端已成功获取所述请求的彩信体后，该方法进一步包括：

删除cache中存储的所述请求的彩信体。

4.根据权利要求1或2所述的方法，其特征在于，所述对cache进行初始化处理具体为：

读取配置文件，根据配置文件中cache对应的标识，获得cache的大小及彩信体的平均大小，并计算控制节点的个数，之后创建cache；

确定创建成功后，将cache映射到进程空间中；

将cache中的控制节点的索引信息初始化为零，并在cache中生成一个空闲的控制节点队列；

将获得的空闲的控制节点队列的首节点的地址写入cache的第二个单元中；并将获得的全局指针(CurPtr)存入cache的第二个单元。

5.根据权利要求1或2所述的方法，其特征在于，所述将提交的彩信体依次存储到cache，具体为：

从空闲的控制节点队列中取得一个空闲的控制节点；

判断cache中用于存储彩信码流的存储空间是否为第一次使用、或二次以上循环使用，确定是第一次使用时，判断cache中用于存储彩信码流的剩余存储空间是否能存储下本次需要存储的彩信码流，确定能存储下本次需要存储的彩信码流时，将本次需要存储的彩信码流写入到CurPtr指示的地址，并进行相关信息的更新；

确定不能存储下本次需要存储的彩信码流时，将CurPtr移至cache存放彩信码流的初始位置，判断当前能使用的存储空间是否能存储下本次需要存储的彩信码流，确定能存储下时，将本次需要存储的彩信码流写入到CurPtr指示的地址，并进行相关信息的更新；

确定当前能使用的存储空间不能存储下本次需要存储的彩信码流时，判断已使用的控制节点队列的首节点对应的彩信码流是否已同步到物理磁盘，确定已同步到物理磁盘时，删除首节点信息，相应的，更新红黑树数据库、以及CurPtr；再次判断当前能使用的存储空间是否能存储下本次需要存储的彩信码流，如此循环，直至将本次需要存储的彩信码流写入到CurPtr指示的地址，并进行相关信息的更新。

6.根据权利要求5所述的方法，其特征在于，该方法还包括：

确定cache中用于存储彩信码流的存储空间是二次以上循环使用时，判断当前能使用的存储空间是否能存储下本次需要存储的彩信码流，确定能存储下时，将本次需要存储的彩信码流写入到CurPtr指示的地址，并进行相关信息的更新；

确定当前能使用的存储空间不能存储下本次需要存储的彩信码流时，判断已使用的控制节点队列的首节点对应的彩信码流是否已同步到物理磁盘，确定已同步到物理磁盘时，删除首节点信息，相应的，更新红黑树数据库、以及CurPtr；

判断当前的首节点对应的彩信码流在cache中的地址是否等于cache中存放彩信码流的初始地址，确定等于时，再次判断cache中用于存储彩信码流的剩余存储空间是否能存储下本次需要存储的彩信码流，如此循环，直至将本次需要存储的彩信码流写入到CurPtr指示的地址，并进行相关信息的更新；

确定当前的首节点对应的彩信码流在cache中的地址不等于cache中存放彩信码流的初始地址时，再次判断当前能使用的存储空间是否能存储下本次需要存储的彩信码流，如此循环，直至将本次需要存储的彩信码流写入到CurPtr指示的地址，并进行相关信息的更新。

7.根据权利要求1或2所述的方法，其特征在于，所述从cache中读到请求的彩信体，具体为：

MMSC收到接收方终端发送的包含网页地址(URL)的链接的获取请求后，根据URL获得相应彩信体对应的msgid；

通过所述msgid查找红黑树数据库中所述msgid对应的控制节点，获得彩信码流在cache中的地址及长度；

将彩信码流从cache中读出，并向接收方终端返回所述请求的彩信体。

8.根据权利要求2所述的方法，其特征在于，所述将cache中的彩信码流同步存储到物理磁盘，具体为：

定时器超时后，判断已使用的控制节点队列的首节点对应的彩信码流是否已同步到物理磁盘，确定没有同步到物理磁盘时，将该节点对应的彩信码流存储到物理磁盘，并将彩信码流已同步到物理磁盘的标识写入该节点信息，同时更新红黑树数据库对应的节点信息；

确定已同步到物理磁盘时，或者，同步过程执行完成后，处理下一个节点；

判断是否处理到已使用的控制节点队列的最后一个控制节点，确定不是时，判断同步过程执行的时间是否超过预设阈值，确定超过时，结束同步过程。

9.根据权利要求3所述的方法，其特征在于，所述删除cache中存储的所述请求的彩信体，具体为：

MMSC判断出接收方终端已成功获取所述请求的彩信体，通过所述请求的彩信体对应的msgid，查找红黑树数据库中所述msgid对应的控制节点；

确定能找到时，判断所述msgid对应的控制节点信息中的接收地址是否是单目的地址；

确定控制节点信息中的接收地址是单目的地址时，判断所述msgid对应的控制节点对应的彩信码流是否已同步到物理磁盘，确定控制节点对应的彩信码流没有同步到物理磁盘时，将彩信码流已同步到物理磁盘的标识写入所述msgid对应的控制节点信息，相应的，更新cache中的相应的控制节点信息。

10.一种处理多媒体消息业务的装置，其特征在于，该装置包括：初始化单元、cache、处理单元、以及发送单元；其中，

初始化单元，用于对cache进行初始化处理；

处理单元，用于MMSC收到业务发起方提交的彩信体后，依据cache中用于存放彩信体的存储空间循环使用的规则，将提交的彩信体依次存储到cache，并向接收方终端发送获取彩信体的通知；

发送单元，用于MMSC收到接收方终端发送的获取请求后，从cache中读到请求的彩信体，并向接收方终端返回所述请求的彩信体；

cache，用于被初始化单元进行初始化处理，并存储业务发起方提交的彩信体。

11.根据权利要求10所述的装置，其特征在于，该装置进一步包括：

删除单元，用于MMSC确定出接收方终端已成功获取所述请求的彩信体后，删除cache中存储的所述请求的彩信体；和/或，

同步单元，用于将cache中存储的彩信码流同步存储到物理磁盘；

物理磁盘，用于存储彩信码流。

Images