CN100486345C - 基于pc服务器的业务*** - Google Patents
基于pc服务器的业务*** Download PDFInfo
- Publication number
- CN100486345C CN100486345C CNB2006100464105A CN200610046410A CN100486345C CN 100486345 C CN100486345 C CN 100486345C CN B2006100464105 A CNB2006100464105 A CN B2006100464105A CN 200610046410 A CN200610046410 A CN 200610046410A CN 100486345 C CN100486345 C CN 100486345C
- Authority
- CN
- China
- Prior art keywords
- message
- client
- msgswitch
- server
- oid
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
基于PC服务器的业务***,平台包括短信二级网、服务器和业务生成器,平台逻辑结构分为三层,第一层为传输层,第二层为平台层、第三层为业务业层,业务生成器采用IFE集成开发环境,服务器为MsgSwitch消息交换服务器,消息交换服务器MsgSwitch应用环境包括:有多个程序,特别是混合多种语言程序;多个数据源或异构的数据库;在客户/服务器中存在“老的”或者已有的应用;行将进行***的增强、增加和修改;复杂的应用间的通信既有企业内部的通信,又有企业间的通信;本发明的消息代理中间件主要提供应用集成所必须的数据的递送、收集、翻译、过滤、映射和路由等功能,屏蔽不同的硬件平台、数据库、消息格式、通信协议之间的鸿沟与差异,提供应用到应用之间的高效、便捷的通信能力。
Description
(一)技术领域
本发明涉及网络通信技术,特别是涉及短信二级网关及业务环境的一种高效通讯方法,用户只需要掌握简单的接口,就能完成应用到应用之间的高效、便捷的通讯。同时实现了短信二级网关在PC级服务器上运行,但能达到与在小型机上运行同样性能的一种软件实现方法。
(二)背景技术
主要引证涉及背景技术的文献有:
《PHS短消息网关技术规范第一分册短消息网关与服务提供商(SP)接口规范(CNGP)V2.0》;
《PHS短消息网关技术规范(第二分册短消息网关与计费中心接口规范V2.0)》;
《PHS短消息网关技术规范第一分册短消息网关与服务提供商(SP)接口规范(CNGP)V2.0》;
***《YD/T 1291-2003点对点短消息网间互通协议要求》;
目前省级二级网关使用的数据库为通用的大型关系型数据库,为了满足高性能指标的要求***均在小型机上运行。而我们的产品由于采用了自主开发的嵌入式数据库,达到要求的性能指标只需在PC服务器上运行。
现有的***各应用通讯有如下缺点:
1、点对点的应用接口完成应用的集成复杂度高,花费大,严重地限制应用的灵活性。
2、不能提供应用与应用间传递的数据转换,传递按照优先级、实时地或批处理的方式进行。
3、复杂的业务处理逻辑带来应用间、应用与人之间交互的复杂性,不能提供一种支持流管理、处理智能化开发的简便性。
4、集成应用的体系结构不能适应业务逻辑、组织机构的变化。
(三)发明内容
本发明的目的,是针对上述问题,提供一种基于PC服务器的业务***,构成快捷网络服务。
采用的技术方案是:
基于PC服务器的业务***,平台包括短信二级网关、服务器和业务生成器,其特征在于平台逻辑结构分为三层,第一层为传输层,第二层为平台层、第三层为业务层,业务***包括业务生成器IFE,服务器MsgSwitch消息交换服务器,消息交换服务器MsgSwitch应用环境包括:
含有混合多种语言程序的多个程序;
多个数据源或异构的数据库;Only DB嵌入式数据库;
在客户/服务器中存在已有的应用;
行将进行***的增强、增加和修改;
复杂的应用间的通信既有企业内部的通信,又有企业间的通信。
MsgSwitch消息交换服务器可以在32/64位多任务***中编译和运行基于字符界面控制台运行。提供远程调试功能和远程控制台,可以在远程通过TCP网络用telnet或XRC进行远程监控。转发消息基于节点地址。节点地址是IP地址的4个数字,数字之间用“.”开,每个数字范围为1-255。节点用32位整数表示,编号为一个32位的整数,该整数由客户端函数库中的函数AMSAddressToInt来由节点地址转换而来,用AMSIntToAddress来转换一个整数为节点地址。节点地址中的4个数字均不允许为数字0。MsgSwitch消息交换服务器服务程序中保留0。
MsgSwitch消息交换服务器支持消息监视功能,通过消息监视客户端,使用TCP协议交换消息,端口默认为10000。Socket运行模式为异步模式选择模型,可以支持大量网络连接,可以被多数操作***支持。程序采用控制台命令行控制方式,运行时,程序将等候用户输入命令。用户可以通过命令来了解***的运行情况和控制运行。
MsgSwitch消息交换服务器对客户端的识别分为两个逻辑部分,分别是Socket识别部分和Client识别部分,每个socket连接为一个Socket客户,一个Socket客户可以同时支持多个Client节点。Socket客户是操作***自动标识的,Client节点通过节点编号或者节点地址来标识。
客户端接口库可以同时连接两个MsgSwitch消息交换服务器,客户端发送需要转发的消息的时候,会通过两个服务器各发送一个消息,两个服务器都将各自独立地转发消息,接收客户端会同时收到2个相同的消息,这时将删除后到达的消息,而只保留第一个消息,并产生OnMessage事件。客户端可以自动检测失效的服务器,当失效的服务器恢复工作后,客户端可以重新连接、注册Client。MsgSwitch消息交换服务器和客户端Socket支持ActiveTest服务;在启动ActiveTest服务的时候,MsgSwitch消息交换服务器端将定时发送ActiveTest消息给每个Socket客户端,如果客户端也启动ActiveTest。客户端会在接收到ActiveTest消息后自动回复这个消息;MsgSwitch消息交换服务器客户端支持内部消息交换功能(InternalSwitch)在不连接MsgSwitch消息交换服务器的情况下实现消息的交换和消息广播。
上述Only DB嵌入式数据库是一种面向对象和网络模型数据库设计方法的综合。对象在内部是通过唯一的对象ID(OID)来标识的,这种方式可以将对象的ID和自身的属性分离开;使用B+树存储/访问方式。有一种这样的B+树索引,称之为主索引,在一个集合中以OID为主键的串行的形式包含了所有对象。还有附加的B+树来维护索引属性。这些属性提供了一种从属性值到对象OID的映射。主索引和辅助索引的组合使得通过OID或索引属性值进行对象查找。每个对象有一个与其它对象的关系集合。
对Only DB嵌入式数据库采用并发性能锁管理;Only DB写操作,将所有的修改更新入数据库。使用B+树的get,set,和get-next操作;利用了本地引用来改进缓存;对象存储在用OID作为主键的主索引中。在主索引中存储了串行对象数据,索引中的主键是OID且OID是顺序的,并使每个新的对象起先都被赋予一个临时的OID,接着提交时这个临时OID将会被一个持久OID代替。OnlyDB引进了“组提交”功能,这样一来,应用程序要完成相同的功能就不需要做别的动作了。
本发明作为面向消息的中间件(MOM)的一部分,消息代理中间件在企业应用集成(Enterprise Application Integration,EAI)中的作用日趋明显。分布式环境下,业务单位四处散布,消息代理中间件主要提供应用集成所必须的数据的递送、收集、翻译、过滤、映射和路由等功能,屏蔽不同的硬件平台、数据库、消息格式、通信协议之间的鸿沟与差异,提供应用到应用之间的高效、便捷的通信能力。
(四)附图说明
图1是***逻辑结构图。
图2是网通二级网关为例其在整个***中的位置图。
(五)具体实施方式
MsgSwitch消息交换服务器主要提供消息的转发功能。基于自适应通讯环境技术,可以在几乎所有32/64位多任务***中编译和运行基于字符界面控制台运行。提供远程调试功能和远程控制台,在远程通过TCP网络用telnet或XRC(一个同样基于自适应技术的字符方式远程控制工具)进行远程监控。它转发消息基于节点地址。节点地址是IP地址的4个数字,数字之间用”.”分开,每个数字范围为1-255。例如:10.1.1.1就是一个合法的节点地址,节点用32位整数表示,编号为一个32位的整数,该整数由客户端函数库中的函数AMSAddreeeToInt来由节点地址转换而来,用AMSIntToAddress来转换一个整数为节点地址。节点地址中的4个数字均不允许为数字0。例如:10.1.0.1、10.0.0.1、0.1.1.1、10.1.1.0都是非法地址。对于MsgSwitch消息交换服务器服务程序来说,0代表的是广播地址。因此予以保留。例:发送消息到10.1.1.0地址,则表示发送相同的消息到10.1.1.1-10.1.1.255的每一个注册了的节点。发送消息到地址10.1.0.0表示发送相同的消息到10.1.1.1-10.1.255.255。发送消息到0.0.0.0地址则表示发送消息到所有节点。
MsgSwitch消息交换服务器支持消息监视功能,通过消息监视客户端,用户很容易地看到所有经过MsgSwitch消息交换服务器的消息。使用TCP协议交换消息,端口默认为10000。Socket运行模式为异步模式选择模型,连接数量与线程数量无关,支持大量网络连接,被多数操作***支持。程序采用控制台命令行控制方式,运行时,程序将等候用户输入命令。用户通过命令来了解***的运行情况和控制运行。
MsgSwitch消息交换服务器对客户端的识别分为两个逻辑部分,分别是Socket识别部分和Client识别部分,每个socket连接为一个Socket客户,一个Socket客户可以同时支持多个Client节点。Socket客户是操作***自动标识的,Client节点通过节点编号或者节点地址来标识。通过对特殊节点地址的定义,服务器支持广播或者组播服务。
MsgSwitch消息交换服务器本身不需要提供冗余机制,对于需要高可靠性的环境,需要对MsgSwitch消息交换服务器进行热备份冗余容错,这个功能由客户端接口库实现。为了得到冗余容错能力,客户端接口库同时连接两个MsgSwitch消息交换服务器,客户端发送需要转发的消息的时候,会通过两个服务器各发送一个消息,两个服务器都将各自独立地转发消息,接收客户端会同时收到2个相同的消息,这时将删除后到达的消息,而只保留第一个消息,并产生OnMessage事件。当一个服务器出现故障,例如掉电等情况时候,消息仍然可以通过另一个服务器转发,不会对***造成任何影响。客户端可以自动重新检测失效的服务器,当失效的服务器恢复工作后,客户端可以重新连接、注册Client。这种冗余容错机制与其它方式比较,优点是简单,易于维护升级,并可以提供足够高的可靠性和稳定性。缺点是消息都是成对发送的,发送消息数量是没有冗余***的2倍。因此工作效率较低。这种缺点由提高服务器的效率来部分抵消。根据测试,在普通低档服务器,客户端发送速率可以超过10000包/秒。
MsgSwitch消息交换服务器和客户端Socket支持ActiveTest服务(心跳服务),通过ActiveTest服务,客户端和MsgSwitch消息交换服务器本身都可以很容易地发现连接是否因为不可预知的原因而发送中断。在发现中断后,服务器会中断客户端的连接。而客户端将会自动检查服务器是否恢复运行,发现服务器正常运行后,会自动重新连接。在启动ActiveTest服务的时候,MsgSwitch消息交换服务器端将定时发送ActiveTest消息给每个Socket客户端,如果客户端也启动ActiveTest。客户端会在接收到ActiveTest消息后自动回复这个消息,不需要编程或人工干预。如果客户端没有启动ActiveTest服务则需要人工处理ActiveTest消息,并回应这个消息,这样才能实现客户端的断连重连功能。注意:MsgSwitch消息交换服务器没有(因为任何情况下连接中断都会导致发送失败,所以不需要检查是否返回了ActiveTest)超时检测功能,也就是说,即使客户端没有回应ActiveTest消息,服务器也不会主动中断这个连接,除非客户端主动连接。服务器不支持每个Client节点的ActiveTest功能,因为这样做会浪费大量的带宽,使得网络通讯的代价更加昂贵。如果需要这样的功能,需要用户实现。
消息发送到MsgSwitch消息交换服务器后,如果目的地址并没有在服务器中注册,则会返回地址错误消息(ERRORADDRESS),如果在使用双机容错的情况下,可能会因为2个服务器都没有发现这个地址,那么就会返回2个错误消息,如果一个找到了地址,另一个没有找到,那么将只返回一个,这种情况下消息可以被可靠传输到指定的客户端。
MsgSwitch消息交换服务器客户端支持内部消息交换功能(InternalSwitch)可以在不连接MsgSwitch消息交换服务器的情况下实现消息的交换和消息广播。在连接服务器的情况下通过内部交换功能来提高通讯效率。内部交换是通过检测本地注册列表实现的,如果发现地址在本地,则自动激发OnMessage事件,消息不需要通过服务器即可直接转发到指定的客户。
当MsgSwitch消息交换服务器客户端没有连接到服务器的时候,如果有消息发送,也会产生地址错误消息,这时候应该检查客户端的连接情况,如果确定没有连接,则应当在连接后重新发送这个消息。
本发明所要解决的第二个问题是针对短信二级网关的高性能指标要求,在自主开发实现的Only DB嵌入式数据库中如何将复杂而潜在可动态调整的数据模式映射到Only DB的键/数据对的问题。我们的逻辑数据模式包含很多不同的实体类别及它们之间的无数关系,我们就需要某种设计来保证这种模式的适应性。其中最重要的一点是,我们每秒必须能处理至少300笔事务并能在一个数据库中容纳平均对象尺寸为约1KB的15000000个记录/对象。典型的事务将包含对数据库的读写访问以创建一条记录。既然我们的数据库大小已经超过了目标硬件所能提供的内存量,我们必须能支持对硬盘的高效读写访问。
针对嵌入式数据库Only DB我们的解决方案是一种面向对象和网络模型数据库设计方法的综合。我们的数据库将数据暴露为对象一命名属性和关系的集合。关系提供了一种机制来查找相关联的对象,而索引属性则提供了一种通过属性值查找对象的能力。对象在内部是通过唯一的对象ID(OID)来标识的,这一点跟OODBMS的实现非常像。这种方式将对象的ID和自身的属性分离开,并且使得当属性值更新时更加容易且有效地更新逻辑。
在设计中,我们使用了B+树存储/访问方式。有一种这样的B+树索引,称之为主索引,在一个集合中以OID为主键的串行的形式包含了所有对象。
还有附加的B+树来维护索引属性。这些属性提供了一种从属性值到对象OID的映射,从本质上讲,是作为对象查找的辅助索引而存在的。
主索引和辅助索引的组合使得通过OID或索引属性值进行对象查找。
最后,每个对象有一个与其它对象的关系集合。
并发性能锁管理
由于应用中有大量并发操作,在Only DB中我们不得不保证任何时刻都只有一个更新事务。同时,我们也不希望使服务器的客户仅限于使用一个并发的更新事务。我们的解决方案是允许用户级别的并发更新事务,批处理所有的更新,直到提交再把所有的更新以单线程的方式写进数据库。用户级事务产生的所有更新都被我们记录在内存中的一个修改集里。在用户级事务提交时,我们启动一个新的事务执行Only DB写操作,将所有的修改更新入数据库。在实现时,我们为每个B+树索引维护一个修改集,并使用修改集来跟踪用户级事务的每次修改。任何对索引的数据库访问都必须是通过修改集进行的,以保证通过B+树索引访问引起的事务性改变都能得到正确地反映。比如,如果用户删除了一个对象,没有提交,那么同事务中所有的对该对象的查找都将失败。事实上,这是因为修改集已经有记录表明对象已经被这个正在执行中的事务删除了。
单线程访问可能运行起来有些慢,但是在我们的应用中,却看不到任何大的性能下降。这得归功于Only DB的相对快速的原子操作。我们仅使用B+树的get,set,和get-next操作,而且没有复杂的SQL查询。我们还能满足甚至超出每秒钟300笔事务的性能需求。
我们自己操作锁策略也有其它的好处。我们通常使用记录/对象一级的锁粒度,有时,即使是这种粒度也可能显得太粗糙了。因为我们自己控制锁粒度,我们就可以做得非常精巧。定制的锁管理使得我们提高性能,并使我们能在模型和访问模式变化时以更好的适应性来应对并发热区。
解决磁盘读写性能瓶颈
在我们的应用程序中我们要解决的一个主要瓶颈是磁盘读写,以及存储和运行时格式之间的数据传输(串行化)。
OnlyDB有一个内存中的高速缓存,用来记录最常用的页面。然而,面对随机的访问模式和一个大型数据库,这个高速缓存所能做的也就这么多了。结果就是磁盘访问时间(主要是寻道时间)成为性能约束的一个因素。
我们的设计利用了本地引用来改进缓存。本质上,通常一起使用的对象一般是接近同时创建的。对于Only DB的B+树实现,顺序创建的有顺序主键的记录有很大的可能是存储在同一个B+树节点中的,因而也就在相同的磁盘块中。我们的对象存储在用OID作为主键的主索引中。这样,接近同时创建的两个对象,其OID在数值上也是接近的。这就意味着很大可能这两个对象将被存储在相同的磁盘页。如果这些目标同时使用,该页面也只要被从磁盘读取一次就可以了。
另一种改进读性能的途径是改进缓存效率。缓存效率取决于数据的紧密程度和B+树页面的利用情况。当键集确定时,顺序增加才能使利用情况最好。这就是当树增加时,B+树页面分开的原因。
在我们的实现中最大的索引就是主索引,因为它存储了串行对象数据。因为该索引中的主键是OID且OID是顺序的,为达到理想的利用率,我们所要做的就是保证OID的产生顺序与对象提交到数据库的顺序是一致的。为了达到这目标,每个新的对象起先都被赋予一个临时的OID,接着提交时这个临时OID将会被一个持久OID代替。
写磁盘也是我们要解决的一个瓶颈。在提交时,事务日志一个要写到(flush)磁盘以保证持久性。另一方面,写缓冲也使得磁盘以磁头运行最有效的方式来安排时间进程。其中的挑战是如何能写缓冲多个事务而同时又保持事务持久性,这种持久性要求数据在提交操作返回前必须被存储到持久存储器中。
Only DB有一个有用的功能,它支持异步写入事务。提交事务时,不必立刻将数据写入到日志中。接着你可以用后续函数将这些缓冲分别写入。这个特点使得我们可以在单个磁盘中处理多个事务。
Only DB引进了“组提交”功能,这样一来,应用程序要完成相同的功能就不需要做别的动作了。
我们处理的最后一个瓶颈问题涉及到串行化开销。数据串行化是一个将内存中对象表象转换到二进制形式的过程。在我们的例子中,我们需要串行化一个对象和所有它的关系和属性,这些关系和属性可能是复杂类型。
解决这个问题时,我们实现了定制的串行化,并且为所有的重要的类提供了紧凑的预定义的对象类ID。这就使得存储更加紧凑,紧凑的存储又导致更佳的串行化性能,更快的对磁盘的读写,更好的缓存效率,因为现在更多的数据可以被保存在缓存中了。
Claims (1)
1、基于PC服务器的业务***,平台包括短信二级网关、消息交换服务器和业务生成器,其特征在于平台逻辑结构分为三层,第一层为传输层,第二层为平台层、第三层为业务层,业务***包括业务生成器IFE,消息交换服务器MsgSwitch,消息交换服务器MsgSwitch应用环境包括:
含有混合多种语言程序的多个程序;
多个数据源或异构的数据库;Only DB嵌入式数据库;
在客户/服务器中存在已有的应用;
进行***的增强、增加和修改;
复杂的应用间的通信既有企业内部的通信,又有企业间的通信;
MsgSwitch消息交换服务器在32/64位多任务***中编译和运行基于字符界面控制台运行;提供远程调试功能和远程控制台,在远程通过TCP网络用telnet或XRC进行远程监控;转发消息基于节点地址;节点地址是IP地址的4个数字,数字之间用“.”分开,每个数字范围为1-255;节点用32位整数表示,编号为一个32位的整数,该整数由客户端函数库中的函数AMSAddressToInt来由节点地址转换而来,用AMSIntToAddress来转换一个整数为节点地址;节点地址中的4个数字均不允许为数字0;MsgSwitch消息交换服务器服务程序中保留0;
MsgSwitch消息交换服务器支持消息监视功能,通过消息监视客户端,使用TCP协议交换消息,端口默认为10000;Socket运行模式为异步模式选择模型,支持大量网络连接,被多数操作***支持;程序采用控制台命令行控制方式,运行时,程序将等候用户输入命令;用户通过命令来了解***的运行情况和控制运行;
MsgSwitch消息交换服务器对客户端的识别分为两个逻辑部分,分别是Socket识别部分和Client识别部分,每个socket连接为一个Socket客户,一个Socket客户同时支持多个Client节点;Socket客户是操作***自动标识的,Client节点通过节点编号或者节点地址来标识;
客户端接口库同时连接两个MsgSwitch消息交换服务器,客户端发送需要转发的消息的时候,会通过两个服务器各发送一个消息,两个服务器都将各自独立地转发消息,接收客户端会同时收到2个相同的消息,这时将删除后到达的消息,而只保留第一个消息,并产生OnMessage事件;客户端自动检测失效的服务器,当失效的服务器恢复工作后,客户端重新连接、注册Client;MsgSwitch消息交换服务器和客户端Socket支持ActiveTest服务;在启动ActiveTest服务的时候,MsgSwitch消息交换服务器端将定时发送ActiveTest消息给每个Socket客户端,如果客户端也启动ActiveTest;客户端会在接收到ActiveTest消息后自动回复这个消息;MsgSwitch消息交换服务器客户端支持内部消息交换功能InternalSwitch在不连接MsgSwitch消息交换服务器的情况下实现消息的交换和消息广播;
上述Only DB嵌入式数据库是一种面向对象和网络模型数据库设计方法的综合;对象在内部是通过唯一的对象ID OID来标识的,这种方式将对象的ID和自身的属性分离开;使用B+树存储/访问方式;有一种这样的B+树索引,称之为主索引,在一个集合中以OID为主键的串行的形式包含了所有对象;还有附助索引,它是附加的B+树,用来维护索引属性;这些属性提供了一种从属性值到对象OID的映射;主索引和辅助索引的组合使得通过OID或索引属性值进行对象查找;每个对象有一个与其它对象的关系集合;
对Only DB嵌入式数据库采用并发性能锁管理;Only DB写操作,将所有的修改更新入数据库;使用B+树的get,set,和get-next操作;利用了本地引用来改进缓存;对象存储在用OID作为主键的主索引中;在主索引中存储了串行对象数据,索引中的主键是OID且OID是顺序的,并使每个新的对象起先都被赋予一个临时的OID,接着提交时这个临时OID将会被一个持久OID代替;OnlyDB引进了“组提交”功能,这样一来,应用程序要完成相同的功能就不需要做别的动作了。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100464105A CN100486345C (zh) | 2006-04-25 | 2006-04-25 | 基于pc服务器的业务*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100464105A CN100486345C (zh) | 2006-04-25 | 2006-04-25 | 基于pc服务器的业务*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1835607A CN1835607A (zh) | 2006-09-20 |
CN100486345C true CN100486345C (zh) | 2009-05-06 |
Family
ID=37003177
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2006100464105A Expired - Fee Related CN100486345C (zh) | 2006-04-25 | 2006-04-25 | 基于pc服务器的业务*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100486345C (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104788769A (zh) * | 2014-05-29 | 2015-07-22 | 天长市远洋船舶设备有限公司 | 一种船舶用改性丁腈橡胶材料 |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8229902B2 (en) * | 2006-11-01 | 2012-07-24 | Ab Initio Technology Llc | Managing storage of individually accessible data units |
CN101119392B (zh) * | 2007-08-21 | 2012-04-25 | 南京联创科技集团股份有限公司 | Socket统一接入的方法 |
CN102118452B (zh) * | 2011-04-18 | 2016-01-06 | 北京思特奇信息技术股份有限公司 | 一种应用于b/s结构的三层服务器架构 |
CN104794119B (zh) * | 2014-01-17 | 2018-04-03 | 阿里巴巴集团控股有限公司 | 用于中间件消息的存储与传输方法及*** |
-
2006
- 2006-04-25 CN CNB2006100464105A patent/CN100486345C/zh not_active Expired - Fee Related
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104788769A (zh) * | 2014-05-29 | 2015-07-22 | 天长市远洋船舶设备有限公司 | 一种船舶用改性丁腈橡胶材料 |
Also Published As
Publication number | Publication date |
---|---|
CN1835607A (zh) | 2006-09-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101535965B (zh) | 用于提高存储管理***的可伸缩性和可移植性的技术 | |
US20180011874A1 (en) | Peer-to-peer redundant file server system and methods | |
US8234296B1 (en) | Method for distributed RDSMS | |
KR101315330B1 (ko) | 대용량 데이터베이스와 인터페이스하기 위한 다 계층소프트웨어 시스템에서 캐쉬 콘텐츠의 일관성을 유지하는시스템 및 방법 | |
CN101187888A (zh) | 一种异构环境中复制数据库数据的方法 | |
CN102411598B (zh) | 一种实现数据一致性的方法及其*** | |
CN103020257B (zh) | 数据操作的实现方法和装置 | |
US20070061327A1 (en) | Providing local access to managed content | |
CN105393243A (zh) | 事务定序 | |
CN102033912A (zh) | 一种分布式数据库访问方法及*** | |
CN101887388B (zh) | 基于内存数据库的数据备份***和方法 | |
CN105324770A (zh) | 有效读出副本 | |
Walborn et al. | Pro-motion: Management of mobile transactions | |
CN102314506B (zh) | 基于动态索引的分布式缓冲区管理方法 | |
CN101853186A (zh) | 分布式事务恢复***和方法 | |
CN101277212B (zh) | 资源管理平台及资源管理方法 | |
CN103377100B (zh) | 一种数据备份方法、网络节点及*** | |
JP4158534B2 (ja) | 分散型データベースシステム | |
CN100486345C (zh) | 基于pc服务器的业务*** | |
EP4213038A1 (en) | Data processing method and apparatus based on distributed storage, device, and medium | |
CN102624881A (zh) | 一种面向移动设备的服务缓存***架构及开发方法 | |
CN103399894A (zh) | 一种基于共享存储池的分布式事务处理方法 | |
CN101276269B (zh) | 可扩展资源管理平台 | |
CN105468643A (zh) | 分布式文件***的访问方法和*** | |
CN114253929A (zh) | 一种基于分布式文件存储的网盘***架构 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20090506 Termination date: 20160425 |