多机房存储***
技术领域
本发明涉及互联网技术领域,具体涉及一种多机房存储***。
背景技术
随着网络服务的日益普及,用户的访问量越来越大,如果将业务数据全部存储在一台服务器上,该服务器往往会由于访问量过大而出现故障,而且,受到服务器存储空间的限制,在业务数据量很大的应用场景中,一台服务器往往无法承载全部的业务数据,因此,需要多台服务器共同为用户提供服务。为此,可以将多台共同用于提供某一服务的服务器设置在同一机房内,由该机房向用户提供该项服务。
另外,在实际应用中,还经常需要将一些常用的业务数据同时存储在多个机房内。例如,为了向全国各地的用户提供相同的服务,分别在北京、广州和西藏设置了三个机房,用户通过任一机房节点都能访问到所需的服务,一般情况下用户访问最近的机房节点即可。这时,北京、广州和西藏三个地区的机房中存储的数据均相同。另外,有时为了防止因一个机房中的服务器挂掉而导致服务中断的情况发生,也会同时部署多个存储有相同数据的机房,以便在一个机房挂掉后能够通过另外的机房为用户提供可靠服务。
在上述情况中,多个机房中的数据需要保持一致,一旦各机房中的数据出现了不一致的情况就会影响用户的正常使用。由于业务数据经常发生变更,一旦某机房中的数据变更后,其他机房没有及时进行同步更新就会导致数据不一致的情况发生。而且,如果多个机房同时发生了更新,则更容易导致数据不一致的情况出现。因此,目前还没有一种有效的机制能够确保多个机房中的数据完全一致。
发明内容
鉴于上述问题,提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的多机房存储***。
根据本发明的一个方面,提供了一种多机房存储***,其包括:多个存储有相同业务数据的主机房以及从机房,其中,各个主机房在接收到更新数据后通知其他主机房以及对应的从机房进行同步更新,在同步更新的过程中,各个主机房之间能够进行双向数据传输;并且,该***进一步包括:比对服务器,用于定期对各个主机房中的数据进行比对,当发现数据不一致时,确定数据正确的主机房,并根据数据正确的主机房中存储的数据更新其他主机房中的数据。
可选地,比对服务器每隔预设的第一时间间隔对各个主机房中的全量数据进行一次比对,和/或,每隔预设的第二时间间隔对各个主机房中的增量数据进行一次比对,其中,第一时间间隔大于第二时间间隔。
可选地,比对服务器对各个主机房中的增量数据进行比对时,获取并比对增量数据对应的md5值,当md5值相同时,确定增量数据相同;当md5值不同时,获取并比对与md5值对应的增量数据的真实值,如果真实值相同,则确定增量数据相同,如果真实值不同,则确定增量数据不同。
可选地,进一步包括:检测服务器,用于检测各个主机房的运行状态,当检测到发生故障的主机房时,将该主机房对应的一个从机房设置为主机房,并停用发生故障的主机房。
可选地,检测服务器进一步用于:检测各个主机房的访问量,当检测到一个主机房的访问量超过设定阈值时,将该主机房上的部分访问请求分发给对应的从机房处理。
可选地,各个主机房以及从机房为SSDB服务器。
可选地,SSDB服务器用于在收到访问请求后,根据访问请求中的指定字段来确定访问请求所遵循的协议规范,并按照协议规范解析并处理访问请求;以及,根据协议规范构造并返回与处理结果相应的响应消息。
可选地,访问请求中的指定字段包括第一个字节对应的字段,当访问请求中的第一个字节对应的字段为Redis协议规范中的请求协议规范所规定的内容时,确定访问请求遵循Redis协议规范中的请求协议规范,则按照请求协议规范解析并处理访问请求;并且,根据Redis协议规范中的响应协议规范构造并返回与处理结果相应的响应消息。
可选地,各个机房上进一步设置有用于设置消息传输路径的消息中间件,则在同步更新的过程中,消息中间件使各个主机房之间能够进行双向数据传输,且使主机房与从机房之间能够进行单向数据传输。
可选地,主机房进一步用于:向对应的从机房同步数据;其中,主机房先将全量数据发送给从机房,当全量数据发送完之后,再通过Binlog日志文件将增量数据同步给从机房。
在本发明的多机房存储***中,设置有多个存储有相同业务数据的主机房以及从机房,由于各个主机房之间能够进行双向数据传输,因此,即使有多台主机房同时发生更新,各个主机房也能及时地通知其他主机房进行同步更新。并且,在本***中,还能够通过比对服务器定期比对各个主机房中的数据,及时发现并纠正数据不一致的情况。由此可见,通过本发明提供的多机房存储***,不仅能够实现各机房之间的同步更新,还能在同步更新失败的情况下,对数据不一致的机房进行异步更新,最终确保各机房数据之间的一致性。
上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,而可依照说明书的内容予以实施,并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂,以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本发明的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1示出了根据本发明一个实施例的多机房存储***的结构示意图;以及,
图2示出了根据本发明另一个实施例的多机房存储***的结构示意图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
本发明实施例提供了一种多机房存储***,至少能够解决现有技术中多个机房之间的数据在频繁更新的情况下难以实现一致性的问题。
实施例一、
图1示出了根据本发明一个实施例的多机房存储***的结构示意图,如图1所示,该***包括:多个存储有相同业务数据的主机房11以及多个从机房12。其中,各个主机房11在接收到更新数据后通知其他主机房11以及对应的从机房12进行同步更新。具体地,由于各个主机房都可能会接收到更新数据并主动发起更新,因此,各个主机房11之间能够进行双向数据传输,通过双向传输机制,即使在多台主机房同时发生更新的情况下,各个主机房也能及时地通知其他主机房进行同步更新。
另外,为了防止因某些主机房同步更新失败而导致各机房数据不一致,图1所示的***还进一步包括:比对服务器13,用于定期对各个主机房11中的数据进行比对,当发现数据不一致时,确定数据正确的主机房,并根据数据正确的主机房中存储的数据更新其他主机房中的数据。
在图1所示的***中,主要实现了如下几点功能:(一)、各个主机房在接收到更新数据后能够通知其他主机房进行同步更新;(二)、各个主机房在接收到更新数据后还能通知对应的从机房进行同步更新,并实现主从同步;(三)、通过比对服务器定期比对各个主机房中的数据,以确保各个主机房中的数据完全一致。下面分别针对各个功能进行详细介绍:
(一)、各个主机房在接收到更新数据后通知其他主机房进行同步更新。
假设机房A、机房B和机房C为三个主机房,当其中的一个机房,例如机房A接收到更新数据后,首先,根据这条更新数据对本机房中存储的数据进行相应更新;其次,机房A还要通知机房B和机房C一起更新。
具体地,机房A可以通过多种方式来通知机房B和机房C:
在第一种实现方式中,机房A上存储有机房B和机房C的通信地址,机房A能够根据该通信地址直接与机房B和机房C通信,因而,机房A直接向机房B和机房C发送一个通知消息即可,这种方式适合于机房数量较少的情形。具体实现时可以采用两种类型的通知消息。第一种类型的通知消息中包含更新数据的具体内容,机房B和机房C接收到通知消息后即可根据其中的更新数据进行更新,该类型的通知消息适合于更新数据量较少的情形。第二种类型的通知消息中不包含更新数据的具体内容,机房B和机房C接收到该通知消息后,准备获取更新数据,具体获取时,可以由机房A将更新数据发送给机房B和机房C,更优选地,也可以由机房A将更新数据存储在一台可由机房B和机房C共享的更新服务器上,使机房B和机房C从该更新服务器上获取数据。其中,该更新服务器用于存储各个机房接收到的更新数据,也就是说,只要有一个机房接收到了更新数据,就会将接收到的更新数据存储在该更新服务器上,并向其他的机房发送通知消息,以便通知其他的机房从该更新服务器上获取更新数据。第二种类型的通知消息适合于更新数据量较多的情形。并且,通过更新服务器可以保存各个机房的数据更新记录,以便在某一机房更新失败的情况下进行查询,从而提高可靠性。
在第二种实现方式中,机房A通过更新服务器来发送上述通知消息给机房B和机房C,因此,机房A只需与上述的更新服务器进行通信即可,而不必直接与机房B和机房C通信,因此,机房A不必存储机房B和机房C的通信地址,这种方式更适合于机房数量众多的情形,在机房数量众多时,由每个机房存储其他所有机房的通信地址并与之通信不仅会增加机房的存储成本,还容易影响机房的正常业务运行。具体地,当机房A接收到更新消息之后,将更新消息发送给该更新服务器,然后,由该更新服务器向其他的各个机房发送通知消息,使其他各机房根据该通知消息获取更新数据进行更新。其中,通知消息也可以灵活采取上述的两种类型来实现。
除了上述两种实现方式之外,本领域技术人员还可以灵活采取其他实现方式,只要能够实现通知其他机房共同更新的目的即可。
另外,在上述的实现方式中,由于各个主机房有可能会同时接收到相同或不同的更新数据,因而各个主机房有可能需要同时进行通信。例如,假设在某一时刻,机房A接收到了第一更新数据,需要将第一更新数据发送给机房B和机房C;机房B接收到了第二更新数据,需要将第二更新数据发送给机房A和机房C,其中,第一更新数据和第二更新数据可以相同也可以不同。因此,在该时刻,机房A、B需要相互通信:机房A要向机房B发送第一更新数据,与此同时,机房B要向机房A发送第二更新数据,为了满足机房A、B同时通信的需求,在本发明提供的多机房存储***中,各个主机房之间通过消息中间件能够进行双向数据传输。其中。消息中间件可以通过封装的QBus实现,QBus是一种虚拟的消息总线,也叫分布式消息队列,用于提供消息分发服务,其内部可以进一步包含QBusHandle,QBusHandle是一个用于获取具体数据内容的中间层。通过消息中间件,能够灵活管理消息传输的路径,从而将各个主机房之间的消息传输路径设置为双向的。另外,除了管理消息传输路径之外,消息中间件还可以对接收到的消息进行排序、分类以及状态反馈等管理工作。例如,消息发送方将要发送的消息发送给消息服务器,消息服务器将接收到的各条消息存放在消息队列中,并在合适的时机将消息转发给消息接收方。其中,消息队列中的每条消息至少包含:消息发送方标识和/或消息接收方标识、消息发送时间以及消息处理状态。消息队列中的各条消息可以根据消息发送方标识和/或消息接收方标识以及消息处理状态进行分类,还可以根据消息发送时间进行排序。另外,消息队列中的消息还可以包含优先级标识,一些重要的消息具有较高的优先级,从而排在消息队列的前面,以便优先处理。消息处理状态包括:待发送、已发送、已收到回复等。例如,在本实施例中,消息发送方既可以是机房A,也可以是更新服务器,消息接收方为机房B和机房C。机房A或更新服务器将通知消息发送给消息服务器,消息服务器将该通知消息放到消息队列中,并记录下该通知消息的发送方及接收方,以及该通知消息的发送时间,此时,该通知消息的处理状态为“待发送”。然后,消息服务器将该通知消息分别发送给机房B和机房C,然后,将该通知消息的处理状态修改为“已发送”。之后,消息服务器判断已发送的各条消息是否收到了接收方的回复,当收到回复时,将回复内容转发给消息发送方。另外,只有在收到接收方返回的处理完毕的响应消息之后,消息服务器才会将本条通知消息设置为处理完毕的状态,如果在设定时间内没有收到接收方的反馈,消息服务器则会重新发送该条消息,直到收到来自接收方的回复,或者直到重新发送的次数达到设定次数时向消息发送方报错。通过消息中间件,能够对消息进行分类、排序以及状态管理等工作,从而确保每条消息都能得到有效处理,避免了消息发送方发送消息后,接收方没有收到或没有处理的情况发生。
除了通过消息中间件来传递通知消息,以便实现更加可靠的消息传输之外,在本发明实施例中,还可以在各个机房上安装一个用于订阅消息的装置,当机房A或更新服务器上出现了新的更新数据时,各个机房通过该订阅消息的装置可以立即得到通知,并获取到新的更新数据。
(二)、各个主机房在接收到更新数据后通知对应的从机房进行同步更新,并实现主从同步。
其中,主机房在接收到更新数据后通知对应的从机房进行同步更新时,可以参照主机房通知其他主机房进行同步更新的实现方式来实现,此处不再赘述。由于在本发明的多机房存储***中,只有主机房才会接收到更新数据,并主动发起更新,从机房只需被动地接收主机房发来的数据即可,因此,在本发明提供的多机房存储***中,主机房与从机房之间通过消息中间件能够进行单向数据传输。具体地,在进行同步更新时,消息中间件通过控制消息传输的路径,将主机房向从机房传输消息的路径设置为有效路径,将从机房向主机房传输消息的路径设置为无效路径,从而实现数据的单向传输功能。通过这种单向传输机制,不仅能够满足主机房向从机房同步数据的需求,而且还能防止从机房篡改主机房中的数据,进而确保了主机房数据的可靠性。
另外,为了确保主机房与从机房中的数据完全一致,主机房还可以每隔预定的时间间隔向对应的所有从机房发起主从同步,或者,主机房也可以单独向某一刚从故障状态恢复过来的从机房发起主从同步。在主从同步的过程中,主机房先将全量数据发送给从机房,当全量数据发送完之后,再通过Binlog日志文件将增量数据同步给从机房。
(三)、通过比对服务器定期比对各个主机房中的数据,以确保各个主机房中的数据完全一致。
其中,定期比对的频率可以根据需要灵活设置,例如,当各个主机房的数据更新频繁时,设置较高的比对频率,如每隔一小时比对一次;当各个主机房的数据更新不频繁时,设置较低的比对频率,如每隔一天或一星期比对一次。为了提高比对效率,每次比对时,可以仅比对增量数据。其中,增量数据是指上一次比对之后产生的更新数据。例如,在每天比对一次的应用场景中,当星期一上午九点钟比对完成后,星期二只需比对星期一上午九点钟之后产生的数据内容,而对星期一上午九点钟之前的数据内容则无需再次比对。通过增量比对的方式可以提高比对效率,降低工作量,避免重复比对。在实际应用中,可以仅采用增量比对方式,也可以将增量比对方式与全量比对方式结合使用,即:每隔预设的第一时间间隔对各个主机房中的全量数据进行一次比对,和/或,每隔预设的第二时间间隔对各个主机房中的增量数据进行一次比对,其中,第一时间间隔大于第二时间间隔。例如,每天进行一次增量比对,每周进行一次全量比对,从而防止已比对过的数据被篡改。
另外,在比对时,为了提高比对效率,可以通过比对各条数据记录所对应的md5值的方式实现。由于机房每次更新数据后,会产生至少一条数据记录,每条数据记录对应一个md5值,该md5值是通过一定的算法计算出来的,用于对本条数据记录进行校验。所以,在比对时,可以只比对各条数据记录所对应的md5值,如果md5值相同,则认为数据内容相同。由于md5值较短,通过md5值进行比对速度较快。当md5值不同时,既有可能是数据记录不同,也有可能是数据记录相同,只是md5值计算错误,因此,还要进一步比对与该md5值对应的数据记录的数据内容,即数据的真实值,如果真实值相同,则确定各机房的数据一致;如果真实值不同,则确定各机房的数据不一致,并在发现数据不一致时,确定数据正确的机房,并根据数据正确的机房中存储的数据更新其他各机房中的数据。其中,可以通过数据校验等方式来确定数据正确的机房。例如,在md5值不同的情况下,可以针对md5值不同的数据记录,重新计算该条数据记录所对应的md5值,将md5值正确的数据记录所在的机房确定为数据正确的机房,并根据该机房中存储的数据更新其他各机房中的数据,最终实现多机房数据一致的目的。另外,也可以通过上文提到的更新服务器来确定数据正确的机房,在更新服务器内存储有近期各个机房收到的更新数据,根据相应时刻的更新数据来确定哪个机房中存储的数据内容是正确的。
除了定期比对各个主机房中的数据之外,该比对服务器也可以进一步比对各个从机房中的数据,当发现数据不一致的情况时,根据主机房中的数据修改从机房中的数据,确保主从一致。
实施例二、
图2示出了根据本发明另一个实施例的多机房存储***的结构示意图,图2所示的多机房存储***在图1的基础上进一步增加了检测服务器20。该检测服务器20用于检测各个主机房的运行状态,当检测到发生故障的主机房时,将该主机房对应的一个从机房设置为主机房,并停用发生故障的主机房。
具体地,检测服务器20定期向各个主机房发送检测数据包,并根据是否收到各个主机房的正确响应来判断各个主机房的运行状态,当发现某一主机房出现故障时,检测服务器20将该主机房对应的服务访问地址修改为该主机房的一个从机房的地址,从而使该从机房升级为主机房,并达到停用发生故障的主机房的目的。当发生故障的主机房恢复后,检测服务器20还可以通过将上述服务访问地址恢复为该主机房的地址,来实现重新启用该主机房的目的。并且,如果仅仅是主机房上的一项服务出现了故障,还可以只将该项服务的服务访问地址切换为其他机房的地址,而该主机房上的其他服务的服务访问地址不变,从而能够实现服务(应用)的平滑切换。
另外,为了防止主机房因访问量过大而出现卡死等状况,检测服务器20还可以进一步检测各个主机房的访问量,并在检测到一个主机房的访问量超过设定阈值时,将该主机房上的部分访问请求分发给对应的从机房处理。
综上所述,在上述的实施例一(参见图1)和实施例二(参见图2)所示的多机房存储***中,设置有多个存储有相同业务数据的主机房以及从机房。由于各个主机房之间通过消息中间件能够进行双向数据传输,因此,即使有多个主机房同时发生更新,各个主机房也能及时地通知其他主机房进行同步更新。因此,与传统的在同一时刻只能向一个机房内写入数据的方式不同,本发明提供的***中的各个主机房可以同时接收数据,即:在同一时刻可以同时向多个主机房内写入数据。另外,由于主机房与从机房之间通过消息中间件能够进行单向数据传输,因此,各个主机房还能及时地通知对应的从机房进行同步更新。并且,在本***中,还能够通过比对服务器定期比对各个主机房中的数据,以便及时发现并纠正数据不一致的情况。由此可见,通过本发明提供的多机房存储***,不仅能够实现各机房之间的同步更新,还能在同步更新失败的情况下,对数据不一致的机房进行异步更新,最终确保各机房数据之间的一致性。
另外,在上述的实施例一和实施例二中,各个机房可以通过Redis数据库来存储数据,通过Redis数据库能够高效地处理多种数据类型,例如,需要动态排序的数据类型等。另外,更加优选地,在图1和图2所示的多机房存储***中,各个机房还可以通过SSDB数据库来存储数据。SSDB数据库能够将数据存储在磁盘上,从而避免了对内存的大量占用,且存储容量也不会受到内存容量的制约,能够存储更多的数据内容。
当图1和图2所示的多机房存储***中的各个机房为SSDB服务器时,为了使这些机房能够为更多种类型的客户端服务,这些机房不仅能够接收并处理遵循SSDB协议的访问请求,还能够接收并处理其他多种协议的访问请求。下面给出具体的处理过程:
首先,SSDB服务器接收到访问请求后,根据访问请求中的指定字段来确定该访问请求所遵循的协议规范。其中,访问请求可以通过多种协议规范来实现,例如,可以是通过SSDB协议规范来实现的SSDB访问请求,或者是通过Redis协议规范来实现的Redis访问请求,还可以是遵循HTTP协议的HTTP访问请求等。总之,本发明实施例对访问请求所遵循的具体协议规范不做限定。在确定访问请求所遵循的协议规范时,可以通过预先设定的协议规范对照表来确定访问请求中指定字段的具***置,并根据该位置的字段内容进一步确定访问请求所遵循的协议规范。其中,该协议规范对照表中存储了常用的各种协议规范,以及每种协议规范所对应的指定字段的字段位置及字段特征。例如,以Redis协议规范为例来说,由于在Redis协议规范的请求协议中,第一个字节固定为“*”号,因此,可以在协议规范对照表中,将Redis协议规范中的请求协议的指定字段设定为第一个字节所对应的字段,且该字段的字段特征为“*”号,只要接收到的访问请求的第一个字节为“*”号,就确定其遵循Redis协议规范中的请求协议规范。具体处理时,由于协议规范对照表中存储了多种协议规范,每种协议规范所对应的指定字段的字段位置及字段特征均不相同,因此,可以针对收到的访问请求,按照协议规范对照表中记录的各个协议规范的顺序逐一进行尝试,直到确定其满足某一协议规范为止。为了尽可能高效地确定出该访问请求所遵循的协议规范,可以在协议规范对照表中动态记录每种协议规范的使用频率,并将各种协议规范按照使用频率进行动态排序,将使用频率较高的协议规范排在前面,以便优先尝试。
然后,按照该访问请求所遵循的协议规范解析并处理该访问请求。其中,解析得到的访问请求至少包括以下请求中的一个或多个:读取数据请求、更新数据请求和删除数据请求,其中,读取数据请求中包含get函数,更新数据请求中包含set函数,删除数据请求中包含delete函数。
最后,根据该访问请求所遵循的协议规范构造并返回与处理结果相应的响应消息。其中,响应消息至少包括以下类型中的一个或多个:状态回复类型、错误回复类型、整数回复类型、批量回复类型和多条批量回复类型。
举例来说,假设在协议规范对照表中预先存储了表1所示的部分内容:
表1
协议规范名称 |
指定字段的位置 |
指定字段的特征 |
Redis请求协议 |
第一个字节 |
* |
Redis响应协议(状态回复) |
第一个字节 |
+ |
Redis响应协议(错误回复) |
第一个字节 |
- |
Redis响应协议(整数回复) |
第一个字节 |
: |
Redis响应协议(批量回复) |
第一个字节 |
$ |
Redis响应协议(多条批量回复) |
第一个字节 |
* |
…… |
…… |
…… |
SSDB服务器接收到的访问请求为“*3\r\n$3\r\nset\r\n$1\r\na\r\n$1\r\n1\r\n”。通过查询表1中的第一条记录,判断出该访问请求遵循Redis协议规范中的请求协议规范,则按照Redis协议规范中的请求协议规范解析并处理该访问请求。具体解析过程如下:首先,根据“*3\r\n”字段得到该访问请求中包含的参数数量为3,根据“$3\r\n”字段得到该访问请求中的第一个参数的字节数量为3,根据“set\r\n”字段得到该访问请求中的第一个参数的数据为set,根据“$1\r\n”得到该访问请求中的第二个参数的字节数量为1,根据“a\r\n”字段得到该访问请求中的第二个参数的数据为a,根据“$1\r\n”得到该访问请求中的第三个参数的字节数量为1,根据“1\r\n”字段得到该访问请求中的第三个参数的数据为1。由此可见,该访问请求中共包含3个参数,第一个参数的字节数量为3,内容为set;第二个参数的字节数量为1,内容为a;第三个参数的字节数量为1,内容为1。因此,该访问请求的解析结果为“set a 1”。其中,“set”函数用于更新/设置数据内容,该访问请求用于将a的值设置为1。所以,SSDB服务器根据该访问请求将a的值设置为1。最后,按照Redis协议规范中的响应协议规范构造并返回与处理结果相应的响应消息。该响应消息属于状态回复,根据Redis响应协议规范,该响应消息的第一个字节应为“+”,所以,构造并返回“+ok”。发送上述访问请求的Redis客户端收到该响应消息后,根据Redis响应协议规范解析出“ok”。
通过上述处理方式,本发明中的各个机房能够自动识别访问请求所遵循的协议规范,并执行相应的处理,因此,不仅能够通过SSDB客户端进行访问,还能通过其他多种类型的客户端进行访问。其他类型的客户端无需进行任何改变,只要按照其原本的协议规范即可。例如,对于Redis客户端来说,能够直接按照访问Redis服务器的方式来访问SSDB服务器,从而方便了其他客户端的使用,扩展了SSDB服务器的应用范围。
另外,在本发明的多机房存储***中,访问节点可以通过网络远程访问各个机房。而且,为了提高机房的访问性能,还进行了一些访问细节上的改进。例如,可以对各个机房所连接的访问节点的数量进行限制,使一个机房在同一时刻只能连接不超过预设数量的访问节点,以防止机房因访问量过大而出现问题;还可以对单个访问节点的输出数据量进行限制,使单个访问节点的输出数据量不能大于某一设定阈值,具体原因在于,当一个访问节点发送的访问请求包含的数据量过大时,会导致该访问节点占用大量内存,从而影响其他节点的正常访问。
在此提供的算法和显示不与任何特定计算机、虚拟***或者其它设备固有相关。各种通用***也可以与基于在此的示教一起使用。根据上面的描述,构造这类***所要求的结构是显而易见的。此外,本发明也不针对任何特定编程语言。应当明白,可以利用各种编程语言实现在此描述的本发明的内容,并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的多机房存储***中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如,计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。