CN101764839B - 一种数据访问方法以及统一资源定位符服务器 - Google Patents
一种数据访问方法以及统一资源定位符服务器 Download PDFInfo
- Publication number
- CN101764839B CN101764839B CN200910252514.5A CN200910252514A CN101764839B CN 101764839 B CN101764839 B CN 101764839B CN 200910252514 A CN200910252514 A CN 200910252514A CN 101764839 B CN101764839 B CN 101764839B
- Authority
- CN
- China
- Prior art keywords
- url
- server
- url server
- resource
- device identification
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims description 34
- 238000012546 transfer Methods 0.000 claims description 22
- 238000001514 detection method Methods 0.000 claims description 16
- 206010033799 Paralysis Diseases 0.000 description 7
- 239000012467 final product Substances 0.000 description 6
- 238000007726 management method Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 230000000052 comparative effect Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 238000012217 deletion Methods 0.000 description 3
- 230000037430 deletion Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000009897 systematic effect Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000003032 molecular docking Methods 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
Images
Landscapes
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明实施例公开了一种数据访问方法以及统一资源定位符服务器，用于提高网络文件系统可靠性、系统性能以及可扩展性。本发明实施例方法包括：第一URL服务器接收用户发送的携带有URL地址的数据访问请求；若第一URL服务器确定URL地址所指向的资源存储在第一URL服务器中，则根据数据访问请求对资源执行相应的读写操作；若不存储在第一URL服务器中，则查询URL地址所指向的资源所在的第二URL服务器，向第二URL服务器转发数据访问请求，以使得第二URL服务器根据数据访问请求对资源执行相应的读写操作。本发明实施例还提供统一资源定位符服务器。本发明实施例可以有效提高网络文件系统可靠性、系统性能以及可扩展性。
Description
技术领域
本发明涉及通信领域，尤其涉及一种数据访问方法以及统一资源定位符服务器。
背景技术
随着大规模网络存储的发展，通过网络来访问存储在变得越来越普遍的同时，也对性能也提出了更高的要求。在互联网上访问数据最常用的方式就是通过浏览器访问，类似于“http://www.myweb.com/html_2/1.html”的统一资源定位符(URL，Uniform Resource Locator)就是网络访问最常用的表示方式。
现有技术中的一种网络文件存储方式为传统的网络分布式存储，若干个数据存储服务器与一个元数据服务器相连，该元数据服务器再与一接口服务器相连，该接口服务器可以向用户提供用户接口，用户可以通过该接口服务器进行数据访问，元数据服务器接收到用户的访问请求后，会向各数据存储服务器进行查询，查询到相应的资源后反馈给用户。
但是上述的技术方案中，元数据都集中保存在元数据服务器内，一旦元数据服务器发生故障，则整个网络文件系统会直接瘫痪；
其次，用户发送的请求的处理和网络文件的处理都由接口服务器完成，这就对接口服务器提出了很高的性能要求，这可能会使得接口服务器成为网络文件系统的瓶颈，从而影响网络文件系统的性能，且当接口服务器故障时，整个网络文件系统也会直接瘫痪。
发明内容
本发明实施例提供了一种数据访问方法以及统一资源定位符服务器，能够提高网络文件系统的可靠性、系统性能以及可扩展性。
本发明实施例提供了一种数据访问方法，包括：
第一统一资源定位符URL服务器接收用户发送的数据访问请求，所述数据访问请求中携带有URL地址；
第一URL服务器判断所述URL地址所指向的资源是否存储在第一URL服务器中；
若第一URL服务器确定所述URL地址所指向的资源存储在第一URL服务器中，则根据所述数据访问请求对所述资源执行相应的读写操作；
若第一URL服务器确定所述URL地址所指向的资源不存储在第一URL服务器中，则查询所述URL地址所指向的资源所在的第二URL服务器；向所述第二URL服务器转发所述数据访问请求，以使得所述第二URL服务器根据所述数据访问请求对所述资源执行相应的读写操作。
本发明实施例还提供了一种URL服务器，包括：
接收模块，用于接收用户发送的数据访问请求，所述数据访问请求中携带有URL地址；
检测模块，用于判断所述接收模块接收的所述访问请求中携带的所述URL地址所指向的资源是否存储在第一URL服务器中；
操作模块，用于当所述检测模块判断所述URL地址所指向的资源存储在第一URL服务器中时，根据所述数据访问请求对所述资源执行相应的读写操作；
查询模块，用于当所述检测模块判断所述URL地址所指向的资源不存储在第一URL服务器中时，查询所述URL地址所指向的资源所在的第二URL服务器；
转发模块，用于向所述查询模块查询到的所述第二URL服务器转发所述数据访问请求，以使得所述第二URL服务器根据所述数据访问请求对所述资源执行相应的读写操作。
从以上技术方案可以看出，本发明实施例具有以下优点：
本发明实施例中，第一URL服务器可以接收到用户发送的数据访问请求，若确定用户需要访问的数据在本地，则执行在本地进行数据处理，若确定用户需要访问的数据在第二URL服务器，则第一URL服务器会将数据访问请求发送至第二URL服务器进行处理，每个URL服务器中都保存有各自独立的数据以及元数据，每个URL服务器中的元数据都仅与本URL服务器中的数据相关联，而不会与第二URL服务器中的数据相关联，因此，即使某一个URL服务器出现故障也不会使得整个网络文件系统瘫痪，从而能够提高网络文件系统的可靠性；
其次，对于各URL服务器而言，若确定用户需要访问的数据不在本地，则会将数据访问请求转发至其他的URL服务器进行处理，即在网络文件系统中并不存在一个专门用于处理数据访问请求以及数据的服务器，因此并不存在瓶颈，从而能够提高系统效率，同时提高网络文件系统的可靠性；
再次，各URL服务器所存储的数据相对独立，数据访问请求也可以根据具体的需要在不同的URL服务器之间进行转发，即在网络文件系统中并不存在一个专门用于管理各URL服务器中的数据的服务器，所以当需要更大的数据容量时，可以直接增添新的URL服务器，只需修改各URL服务器中所保存的对应关系即可，因此在理论上可以无限的增加新的URL服务器，从而大大提高了网络文件系统的可扩展性。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例中网络结构示意图；
图2为本发明实施例中数据访问方法一个实施例示意图；
图3为本发明实施例中数据访问方法另一实施例示意图；
图4为本发明实施例中URL服务器实施例示意图；
图5为本发明实施例中通信系统实施例示意图。
具体实施方式
本发明实施例提供了一种数据访问方法以及统一资源定位符服务器，能够提高网络文件系统的可靠性、系统性能以及可扩展性。
为便于说明，下面介绍本发明的一个具体实施例。如图1所示，为本发明实施例中的网络结构示意图，该网络包括：用户设备、用户接入设备和多个URL服务器，其中，用户设备用于发送用户访问请求，用户接入设备用于将用户设备接入到网络中，URL服务器用于处理用户设备发送的访问请求。
本实施例中，需要预先确定第一URL服务器，下面以第一URL服务器为例，对数据访问方法进行详细介绍。
如图2所示，本发明实施例中数据访问方法一个实施例包括：
201、第一URL服务器接收用户发送的数据访问请求；
本实施例中，当用户请求访问数据时，会通过网络中的用户接入设备发送数据访问请求，该数据访问请求中携带有需要访问的数据的URL地址。
本实施例中的网络文件系统由若干个独立的URL服务器组成，其中的第一URL服务器可以从用户接入设备接收到该用户发送的数据访问请求。
202、第一URL服务器判断该URL地址所指向的资源是否存储在第一URL服务器中，若是，则执行步骤203，若否，则执行步骤204；
当第一URL服务器解析得到数据访问请求中的URL地址之后，则可以判断该URL地址所指向的资源是否存储在第一URL服务器中。
URL地址指向的资源可以是网页页面、数据资源等，例如：HTTP访问时，URL指向一网页页面；FTP访问时，URL指向一数据资源。
203、根据数据访问请求对资源执行相应的读写操作；
若URL地址所指向的资源存储在第一URL服务器中，则第一URL服务器可以根据数据访问请求对该资源进行相应的读写操作，例如根据数据访问请求对资源进行修改，添加，或删除等。
本流程结束。
204、查询URL地址所指向的资源所在的第二URL服务器；
若URL地址所指向的资源不存储在第一URL服务器中，则第一URL服务器根据该URL地址查询对应的第二URL服务器。
205、向第二URL服务器转发数据访问请求。
当查询到对应的第二URL服务器之后，第一URL服务器可以向第二URL服务器转发数据访问请求，以使得第二URL服务器根据数据访问请求对资源执行相应的读写操作。
本流程结束。
本实施例中，第一URL服务器可以接收到用户发送的数据访问请求，若确定用户需要访问的数据在本地，则执行在本地进行数据处理，若确定用户需要访问的数据在第二URL服务器，则第一URL服务器会将数据访问请求发送至第二URL服务器进行处理，每个URL服务器中都保存有各自独立的数据以及元数据，每个URL服务器中的元数据都仅与本URL服务器中的数据相关联，而不会与第二URL服务器中的数据相关联，因此，即使某一个URL服务器出现故障也不会使得整个网络文件系统瘫痪，从而能够提高网络文件系统的可靠性；
其次，对于各URL服务器而言，若确定用户需要访问的数据不在本地，则会将数据访问请求转发至其他的URL服务器进行处理，即在网络文件系统中并不存在一个专门用于处理数据访问请求以及数据的服务器，因此并不存在瓶颈，从而能够提高系统效率，同时提高网络文件系统的可靠性；
再次，各URL服务器所存储的数据相对独立，数据访问请求也可以根据具体的需要在不同的URL服务器之间进行转发，即在网络文件系统中并不存在一个专门用于管理各URL服务器中的数据的服务器，所以当需要更大的数据容量时，可以直接增添新的URL服务器，只需修改各URL服务器中所保存的对应关系即可，因此在理论上可以无限的增加新的URL服务器，从而大大提高了网络文件系统的可扩展性。
为便于理解，下面以一具体实例对本发明实施例中的数据访问方法进行详细描述，请参阅图3，本发明实施例中数据访问方法另一实施例包括：
301、第一URL服务器接收用户发送的数据访问请求；
本实施例中，当用户请求访问数据时，会通过网络中的用户接入设备发送数据访问请求，该数据访问请求中携带有需要访问的数据的URL地址。
本实施例中，第一URL服务器可以为用户接入设备根据本地配置的各URL服务器的信息确定的URL服务器，该第一URL服务器在实际应用中可以有多种情况，例如：
(1)、该第一URL服务器为用户接入设备在各URL服务器中随机选择的一个URL服务器。
该方式下，用户接入设备无需进行计算操作，直接随机选择一个URL服务器即可，这样可以有效的减少用户接入设备的负荷。
(2)、该第一URL服务器为用户接入设备根据各URL服务器的物理位置，选择的与用户之间的物理距离最近的一个URL服务器。
该方式下，用户接入设备选取的URL服务器与用户之间的物理距离最近，所以可以更快的将数据访问请求发送至URL服务器，以便减少数据访问的延迟时间。
(3)、该第一URL服务器为用户接入设备根据各URL服务器当前的负载情况选择的负载最小的一个URL服务器。
该方式下，各URL服务器需要实时向用户接入设备上报各自的负载情况，用户接入设备选取负载最小的URL服务器来处理数据访问请求能够有效的均衡各URL服务器之间的负载。
需要说明的是，本实施例中的各URL服务器所展现的外部地址是相同的，该外部地址可以为互联网协议(IP，Intemet Protocol)地址，或者为非IP类的地址，例如采用线缆转换(InfiniBand)方式的地址等，以IP地址为例，各URL服务器(即整个网络文件系统)向用户体现出的地址可以为192.168.0.1，该地址经过域名转换服务器可以为“www.myweb.com”则用户在请求访问该网络文件系统中的数据时，在数据访问请求中所携带的URL地址可以为“http://www.myweb.com/html_2/dir22/1.html”。
302、使用URL地址在系统目录中进行匹配；
本实施例中，在每个URL服务器中均保存有设备标识与系统目录之间的对应关系，用于表示哪个系统目录的资源存储在哪个设备标识对应的设备中，例如可以如下表所示：
表1
| 设备标识 | 内部地址 | URL文件系统目录 |
| 设备1 | 192.168.0.8 | http://www.myweb.com/html_2/ |
| 设备2 | 192.168.0.9 | http://www.myweb.com/html_2/dir22/ |
第一URL服务器可以根据数据访问请求中的URL地址在表1所示的对应关系中进行匹配。
303、查询URL地址最长匹配到的系统目录对应的设备标识；
当使用URL地址在系统目录中进行匹配之后，可以确定URL地址最长匹配到的系统目录，以URL地址中的斜杠之间的地址为一个比较单位，与该URL地址之间存在最多相同的比较单位的系统目录就是最长匹配到的系统目录。例如“http://www.myweb.com/html_2/dir22/1.html”在第一URL服务器中保存的上述表1中，与系统目录http://www.myweb.com/html_2/相同的比较单位为两个，与系统目录http://www.myweb.com/html_2/dir22/相同的比较单位为三个，因此，最长匹配到的系统目录为“http://www.myweb.com/html_2/dir22/”，之后，第一URL服务器可以再确定该系统目录对应的设备标识为“设备2”。
304、判断查询到的设备标识是否为第一URL服务器的设备标识，若是，则执行步骤305，若否，则执行步骤306；
本实施例中，第一URL服务器查询到设备标识之后，可以判断该查询到的设备标识是否为自身的设备标识，若是，则说明用户请求访问的资源存储在本地，若不是，则说明用户请求访问的数据不存储在本地。
305、根据数据访问请求对资源执行相应的读写操作；
若查询到的设备标识“设备2”是第一URL服务器的设备标识，则第一URL服务器可以根据数据访问请求对该资源进行相应的读写操作，例如根据数据访问请求对资源进行修改，添加，或删除等，具体过程为本领域技术人员的公知常识，此处不再赘述。
306、查询该设备标识对应的第二URL服务器；
若查询到的设备标识“设备2”不是第一URL服务器的设备标识，则再查询该设备标识对应的第二URL服务器，并确定该第二URL服务器的地址，例如根据表1可以确定第二URL服务器的地址为“192.168.0.9”。
需要说明的是，本实施例中是以IP地址作为内部地址为例进行说明的是，在实际应用中，URL服务器的内部地址还可以是其他类型的非IP类地址，例如采用线缆转换(InfiniBand)方式的地址等，在网络文件系统中，每一个URL服务器的内部地址都不相同，以使得不同的URL服务器之间可以进行内部通信。
307、向第二URL服务器转发数据访问请求。
当查询到对应的第二URL服务器的地址之后，第一URL服务器可以向第二URL服务器转发数据访问请求，以使得第二URL服务器根据数据访问请求对资源执行相应的读写操作。
需要说明的是，若某一URL服务器中存储的数据过多，或数据增长速度过快，则可以进行资源的转移，例如：
第一URL服务器判断本地存储的资源中是否存在满足预置的转移条件的待转移资源，若存在，则将待转移资源转移至第三URL服务器，并更新各URL服务器中保存的设备标识与系统目录之间的对应关系。
为便于理解，下面以实际应用为例进行说明：第一URL服务器中保存的是“http://www.myweb.com/html_2/”中的资源，假设“…/html_2/”下还有一级目录“…/html_2/dir33”，若该“…/dir33”目录中存储的资源的数据量达到了预置的门限值(例如为10GB)，或者是该“…/dir33”目录中存储的资源的增长速度达到了预置门限(例如为1GB/天)，为了减轻第一URL服务器的压力，则可以将该“…/dir33”目录中存储的资源确定为待转移资源，将该“…/dir33”目录中存储的资源转移至第三URL服务器，该第三URL服务器可以为现有网络文件系统中负载较轻的URL服务器，或者可以是新增的一个服务器。
本实施例中以第三URL服务器为新增的服务器为例进行说明，当第一URL服务器检测待转移资源时，若第三URL服务器上线，则第一URL服务器会向第三URL服务器发送数据转移请求，得到第三URL服务器的反馈之后，则第一URL服务器向第三URL服务器发送该待转移资源。
需要说明的是，第一URL服务器与第三URL服务器在数据转移的过程中均不可进行数据读写操作，具体可以将第一URL服务器与第三URL服务器暂时离线，或者是设置读写标识为“禁止”，在“禁止”的原因中还可以增加“正在进行数据转移”，当用户发送的数据访问请求正是要求访问第一URL服务器上的数据时，则第一URL服务器会向用户返回读写失败消息，在该读写失败消息中可以携带原因值为“正在进行数据转移”。
资源转移完成后，由于改变了系统目录，则还需要对整个网络文件系统中各URL所保存的设备标识与系统目录之间的对应关系进行更新，具体的更新操作从第一URL服务器开始，第一URL服务器根据待转移的资源以及本地保存的其他资源确定更新后的设备标识与系统目录之间的对应关系，可以如下表2所示：
表2
| 设备标识 | 内部地址 | URL文件系统目录 |
| 设备1 | 192.168.0.8 | http://www.myweb.com/html_2/ |
| 设备2 | 192.168.0.9 | http://www.myweb.com/html_2/dir22/ |
| 设备3 | 192.168.0.10 | http://www.myweb.com/html_2/dir33/ |
当第一URL服务器完成了对应关系的更新之后，可以将该更新后的对应关系发送至第二URL服务器(包括第三URL服务器)，则各URL服务器更新各自保存的对应关系，发送对应关系时，可以只发送其中变化的部分，例如：只发送设备3与URL文件系统目录的对应关系。
需要说明的是，本实施例中，预置的转移条件仅为带转移资源的数据量达到预置门限，或待转移资源的数据量增长速度达到预置门限，可以理解的是，在实际应用中，具体的转移条件还可以有更多的情况，具体情况此处不作限定。
本实施例中，第一URL服务器可以接收到用户发送的数据访问请求，若确定用户需要访问的数据在本地，则执行在本地进行数据处理，若确定用户需要访问的数据在第二URL服务器，则第一URL服务器会将数据访问请求发送至第二URL服务器进行处理，每个URL服务器中都保存有各自独立的数据以及元数据，每个URL服务器中的元数据都仅于本URL服务器中的数据相关联，而不会与第二URL服务器中的数据相关联，因此，即使某一个URL服务器出现故障也不会使得整个网络文件系统瘫痪，从而能够提高网络文件系统的可靠性；
其次，对于各URL服务器而言，若确定用户需要访问的数据不在本地，则会将数据访问请求转发至其他的URL服务器进行处理，即在网络文件系统中并不存在一个专门用于处理数据访问请求以及数据的服务器，因此并不存在瓶颈，从而能够提高系统效率，同时提高网络文件系统的可靠性；
再次，当满足预置的转移条件时，第一URL服务器可以将待转移资源转移至其他的URL服务器，从而能够减少第一URL服务器的负载，均衡各URL服务器的性能；
更进一步，各URL服务器所存储的数据相对独立，数据访问请求也可以根据具体的需要在不同的URL服务器之间进行转发，即在网络文件系统中并不存在一个专门用于管理各URL服务器中的数据的服务器，所以当需要更大的数据容量时，可以直接增添新的URL服务器，只需修改各URL服务器中所保存的对应关系即可，因此在理论上可以无限的增加新的URL服务器，从而大大提高了网络文件系统的可扩展性。
下面介绍本发明实施例中的URL服务器，请参阅图4，本发明实施例中的URL服务器包括：
接收模块401，用于接收用户发送的数据访问请求，数据访问请求中携带有URL地址；
检测模块402，用于判断接收模块401接收到的数据访问请求中携带的URL地址所指向的资源是否存储在第一URL服务器中；
操作模块403，用于当检测模块402判断该URL地址所指向的资源存储在第一URL服务器中时，根据数据访问请求对URL地址所指向的资源执行相应的读写操作；
查询模块404，用于检测模块402判断该URL地址所指向的资源不存储在第一URL服务器中时，查询URL地址所指向的资源所在的第二URL服务器；
转发模块405，用于向查询模块404查询到的第二URL服务器转发数据访问请求，以使得第二URL服务器根据数据访问请求对资源执行相应的读写操作；
其中，检测模块402包括：
匹配单元4021，用于使用该URL地址在系统目录中进行匹配以查询该URL地址最长匹配到的系统目录；
设备标识查询单元4022，用于查询匹配单元4021最长匹配到的系统目录对应的设备标识；
确定单元4023，用于当设备标识查询单元4022查询到的设备标识为第一URL服务器的设备标识时，确定该URL地址所指向的资源存储在第一URL服务器中，若该设备标识不为第一URL服务器的设备标识时，则确定该URL地址所指向的资源不存储在第一URL服务器中。
本实施例中的URL服务器中还可以进一步包括：
转移校验模块406，用于判断是否存在满足预置的转移条件的待转移资源；
资源转移模块407，用于当转移校验模块406确定存在满足预置的转移条件的待转移资源时，将待转移资源转移至其他的URL服务器；
更新模块408，用于在资源转移模块407完成资源转移之后更新各URL服务器中保存的设备标识与系统目录之间的对应关系。
其中，更新模块408包括：
本地更新单元4081，用于根据待转移资源以及自身存储的其他资源更新本地保存的设备标识与系统目录之间的对应关系；
更新通告单元4082，用于将更新后的设备标识与系统目录之间的对应关系发送至第二URL服务器，使得第二URL服务器更新本地保存的设备标识与系统目录之间的对应关系。
为便于理解，下面以一具体应用场景对本发明实施例中的URL服务器实施例进行说明：
本实施例中，当用户请求访问数据时，会发送数据访问请求，该数据访问请求中携带有需要访问的数据的URL地址。
本实施例中的网络文件系统由若干个独立的URL服务器组成，其中的第一URL服务器的接收模块401会接收到该用户发送的数据访问请求。
本实施例中，在每个URL服务器中均保存有设备标识与系统目录之间的对应关系，用于表示哪个系统目录的资源存储在哪个设备标识对应的设备中，检测模块402可以使用URL地址在系统目录中进行匹配，之后可以确定URL地址最长匹配到的系统目录，再确定该系统目录对应的设备标识，从而判断该查询到的设备标识是否为自身的设备标识，若是，则说明用户请求访问的资源存储在本地，若不是，则说明用户请求访问的数据不存储在本地。
若检测模块402确定查询到的设备标识是第一URL服务器的设备标识，则操作模块403可以根据数据访问请求对该资源进行相应的读写操作，例如根据数据访问请求对资源进行修改，添加，或删除等，具体过程为本领域技术人员的公知常识，此处不再赘述。
若检测模块402确定查询到的设备标识不是第一URL服务器的设备标识，则查询模块404再查询该设备标识对应的第二URL服务器，并确定该第二URL服务器的地址。
当查询模块404查询到对应的第二URL服务器的地址之后，转发模块405可以向第二URL服务器转发数据访问请求，以使得第二URL服务器根据数据访问请求对资源执行相应的读写操作。
需要说明的是，若某一URL服务器中存储的数据过多，或数据增长速度过快，则可以进行资源的转移，例如：
转移校验模块406判断本地存储的资源中是否存在满足预置的转移条件的待转移资源，若存在，则资源转移模块407将待转移资源转移至第三URL服务器，更新模块408更新各URL服务器中保存的设备标识与系统目录之间的对应关系。
本实施例中，接收模块401可以接收到用户发送的数据访问请求，若检测模块402确定用户需要访问的数据在本地，则操作模块403执行在本地进行数据处理，若检测模块402确定用户需要访问的数据在第二URL服务器，则查询模块404以及转发模块405会将数据访问请求发送至第二URL服务器进行处理，每个URL服务器中都保存有各自独立的数据以及元数据，每个URL服务器中的元数据都仅于本URL服务器中的数据相关联，而不会与第二URL服务器中的数据相关联，因此，即使某一个URL服务器出现故障也不会使得整个网络文件系统瘫痪，从而能够提高网络文件系统的可靠性；
其次，对于各URL服务器而言，若确定用户需要访问的数据不在本地，则会将数据访问请求转发至其他的URL服务器进行处理，即在网络文件系统中并不存在一个专门用于处理数据访问请求以及数据的服务器，因此并不存在瓶颈，从而能够提高系统效率，同时提高网络文件系统的可靠性；
再次，当满足预置的转移条件时，资源转移模块407可以将待转移资源转移至其他的URL服务器，从而能够减少第一URL服务器的负载，均衡各URL服务器的性能；
更进一步，各URL服务器所存储的数据相对独立，数据访问请求也可以根据具体的需要在不同的URL服务器之间进行转发，即在网络文件系统中并不存在一个专门用于管理各URL服务器中的数据的服务器，所以当需要更大的数据容量时，可以直接增添新的URL服务器，只需修改各URL服务器中所保存的对应关系即可，因此在理论上可以无限的增加新的URL服务器，从而大大提高了网络文件系统的可扩展性。
下面介绍本发明实施例中的通信系统，请参阅图5，本发明实施例中的通信系统实施例包括至少两个URL服务器，分别为第一URL服务器501和第二URL服务器502。
其中，本实施例中的第一URL服务器501以及第二URL服务器502的具体结构以及功能可以与前述图4所示的URL服务器相同，此处不再赘述。
本实施例中仅以两个URL服务器为例进行说明，可以理解的是，在实际应用中还可以有更多的URL服务器，具体数量此处不作限定。
本实施例中，第一URL服务器501可以接收到用户发送的数据访问请求，若确定用户需要访问的数据在本地，则执行在本地进行数据处理，若确定用户需要访问的数据在第二URL服务器502，则第一URL服务器501会将数据访问请求发送至第二URL服务器502进行处理，每个URL服务器中都保存有各自独立的数据以及元数据，每个URL服务器中的元数据都仅于本URL服务器中的数据相关联，而不会与其它URL服务器中的数据相关联，因此，即使某一个URL服务器出现故障也不会使得整个网络文件系统瘫痪，从而能够提高网络文件系统的可靠性；
其次，对于各URL服务器而言，若确定用户需要访问的数据不在本地，则会将数据访问请求转发至其他的URL服务器进行处理，即在网络文件系统中并不存在一个专门用于处理数据访问请求以及数据的服务器，因此并不存在瓶颈，从而能够提高系统效率，同时提高网络文件系统的可靠性；
再次，各URL服务器所存储的数据相对独立，数据访问请求也可以根据具体的需要在不同的URL服务器之间进行转发，即在网络文件系统中并不存在一个专门用于管理各URL服务器中的数据的服务器，所以当需要更大的数据容量时，可以直接增添新的URL服务器，只需修改各URL服务器中所保存的对应关系即可，因此在理论上可以无限的增加新的URL服务器，从而大大提高了网络文件系统的可扩展性。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，上述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上对本发明所提供的一种数据访问方法以及统一资源定位符服务器进行了详细介绍，对于本领域的一般技术人员，依据本发明实施例的思想，在具体实施方式及应用范围上均会有改变之处，因此，本说明书内容不应理解为对本发明的限制。
Claims (8)
1.一种数据访问方法，其特征在于，包括：
第一统一资源定位符URL服务器从用户接入设备接收用户发送的数据访问请求，所述数据访问请求中携带有URL地址；
第一URL服务器判断所述URL地址所指向的资源是否存储在第一URL服务器中；
若第一URL服务器确定所述URL地址所指向的资源存储在第一URL服务器中，则根据所述数据访问请求对所述资源执行相应的读写操作；
若第一URL服务器确定所述URL地址所指向的资源不存储在第一URL服务器中，则查询所述URL地址所指向的资源所在的第二URL服务器；向所述第二URL服务器转发所述数据访问请求，以使得所述第二URL服务器根据所述数据访问请求对所述资源执行相应的读写操作；
所述方法还包括：
第一URL服务器判断本地存储的资源中是否存在满足预置的转移条件的待转移资源，若存在，则将所述待转移资源转移至第三URL服务器；
更新各URL服务器中保存的设备标识与系统目录之间的对应关系；
每个URL服务器中都保存有各自独立的数据和元数据，每个URL服务器中的元数据都仅与本URL服务器中的数据相关联。
2.根据权利要求1所述的方法，其特征在于，第一URL服务器判断所述URL地址所指向的资源是否存储在第一URL服务器中，包括：
第一URL服务器使用所述URL地址在系统目录中进行匹配以查询所述URL地址最长匹配到的系统目录；
查询最长匹配到的系统目录对应的设备标识；
若所述设备标识为所述第一URL服务器的设备标识，则确定所述URL地址所指向的资源存储在第一URL服务器中，若所述设备标识不为所述第一URL服务器的设备标识，则确定所述URL地址所指向的资源不存储在第一URL服务器中。
3.根据权利要求1或2所述的方法，其特征在于，所述更新各URL服务器中保存的设备标识与系统目录之间的对应关系包括：
第一URL服务器根据所述待转移资源以及自身存储的其他资源更新本地保存的设备标识与系统目录之间的对应关系；
第一URL服务器将更新后的设备标识与系统目录之间的对应关系发送至其他URL服务器，使得所述第二URL服务器更新本地保存的设备标识与系统目录之间的对应关系。
4.根据权利要求1或2所述的方法，其特征在于，所述满足预置的转移条件为所述待转移资源的数据量达到预置门限，或所述待转移资源的数据量增长速度达到预置门限。
5.根据权利要求1所述的方法，其特征在于，
所述第一URL服务器为随机选取的URL服务器；
或，
所述第一URL服务器为与所述用户之间的物理距离最近的URL服务器；
或，
所述第一URL服务器为负载最小的URL服务器。
6.一种URL服务器，其特征在于，包括：
接收模块，用于从用户接入设备接收用户发送的数据访问请求，所述数据访问请求中携带有URL地址；
检测模块，用于判断所述接收模块接收的所述访问请求中携带的所述URL地址所指向的资源是否存储在第一URL服务器中；
操作模块，用于当所述检测模块判断所述URL地址所指向的资源存储在第一URL服务器中时，根据所述数据访问请求对所述资源执行相应的读写操作；
查询模块，用于当所述检测模块判断所述URL地址所指向的资源不存储在第一URL服务器中时，查询所述URL地址所指向的资源所在的第二URL服务器；
转发模块，用于向所述查询模块查询到的所述第二URL服务器转发所述数据访问请求，以使得所述第二URL服务器根据所述数据访问请求对所述资源执行相应的读写操作；
所述URL服务器还包括：
转移校验模块，用于判断是否存在满足预置的转移条件的待转移资源；
资源转移模块，用于当存在满足预置的转移条件的待转移资源时，将所述待转移资源转移至其他的URL服务器；
更新模块，用于更新各URL服务器中保存的设备标识与系统目录之间的对应关系；
每个URL服务器中都保存有各自独立的数据和元数据，每个URL服务器中的元数据都仅与本URL服务器中的数据相关联。
7.根据权利要求6所述的URL服务器，其特征在于，所述检测模块包括：
匹配单元，用于使用所述URL地址在系统目录中进行匹配以查询所述URL地址最长匹配到的系统目录；
设备标识查询单元，用于查询所述匹配单元最长匹配到的系统目录对应的设备标识；
确定单元，用于当所述设备标识查询单元查询到的所述设备标识为所述第一URL服务器的设备标识时，确定所述URL地址所指向的资源存储在第一URL服务器中，若所述设备标识不为所述第一URL服务器的设备标识时，则确定所述URL地址所指向的资源不存储在第一URL服务器中。
8.根据权利要求6或7所述的URL服务器，其特征在于，所述更新模块包括：
本地更新单元，用于根据所述待转移资源以及自身存储的其他资源更新本地保存的设备标识与系统目录之间的对应关系；
更新通告单元，用于将更新后的设备标识与系统目录之间的对应关系发送至所述第二URL服务器，使得所述第二URL服务器更新本地保存的设备标识与系统目录之间的对应关系。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910252514.5A CN101764839B (zh) | 2009-12-23 | 2009-12-23 | 一种数据访问方法以及统一资源定位符服务器 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910252514.5A CN101764839B (zh) | 2009-12-23 | 2009-12-23 | 一种数据访问方法以及统一资源定位符服务器 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101764839A CN101764839A (zh) | 2010-06-30 |
| CN101764839B true CN101764839B (zh) | 2013-01-23 |
Family
ID=42495821
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200910252514.5A Active CN101764839B (zh) | 2009-12-23 | 2009-12-23 | 一种数据访问方法以及统一资源定位符服务器 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101764839B (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108241648A (zh) * | 2016-12-23 | 2018-07-03 | 中兴通讯股份有限公司 | 一种数据处理方法及装置 |
Families Citing this family (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101917479A (zh) * | 2010-08-20 | 2010-12-15 | 北京新岸线网络技术有限公司 | 一种用于移动网络中改善分组数据业务的方法及装置 |
| CN102083100B (zh) * | 2010-12-31 | 2014-11-26 | 百度在线网络技术（北京）有限公司 | 一种用于基于站点检测多个资源链接的状态的方法与设备 |
| CN102946449A (zh) * | 2012-11-28 | 2013-02-27 | 网神信息技术（北京）股份有限公司 | Url 的匹配方法、装置及网关 |
| CN104519088A (zh) * | 2013-09-27 | 2015-04-15 | 方正宽带网络服务股份有限公司 | 一种缓存系统的实现方法及缓存系统 |
| CN103560937B (zh) * | 2013-11-01 | 2017-03-15 | 北京蓝汛通信技术有限责任公司 | 数据访问方法和入口服务器 |
| CN104702634B (zh) * | 2013-12-04 | 2018-10-02 | 腾讯科技（深圳）有限公司 | 数据操作请求处理方法、装置及系统 |
| CN104618430A (zh) * | 2014-12-25 | 2015-05-13 | 华为技术有限公司 | 一种实现互联网缓存系统资源回源的方法和系统 |
| CN104935668A (zh) * | 2015-06-26 | 2015-09-23 | 四川长虹电器股份有限公司 | 分布式文件系统及其数据同步的方法 |
| CN106817381A (zh) * | 2015-11-27 | 2017-06-09 | 阿里巴巴集团控股有限公司 | 数据处理方法及装置 |
| CN105741031A (zh) * | 2016-01-28 | 2016-07-06 | 北京恒华伟业科技股份有限公司 | 一种工程设计方案的处理方法和装置 |
| CN105915621A (zh) * | 2016-05-11 | 2016-08-31 | 深圳市永兴元科技有限公司 | 访问数据的方法及预处理服务器 |
| CN107770209B (zh) * | 2016-08-16 | 2021-04-16 | 中兴通讯股份有限公司 | 资源共享方法和装置 |
| CN107819729B (zh) | 2016-09-13 | 2021-06-25 | 腾讯科技（深圳）有限公司 | 一种数据请求方法及其系统、接入设备、存储设备和存储介质 |
| CN107172102A (zh) * | 2017-07-13 | 2017-09-15 | 上海联影医疗科技有限公司 | 数据访问方法、系统以及存储介质 |
| CN107835089B (zh) * | 2017-09-28 | 2020-06-02 | 华为技术有限公司 | 管理资源的方法和装置 |
| CN107835256A (zh) * | 2017-12-08 | 2018-03-23 | 福建润哲网络科技有限公司 | 一种基于HTTP协议的IPv4‑IPv6双栈缓存资源共享方法及装置 |
| CN109542895B (zh) * | 2018-10-25 | 2019-12-06 | 北京开普云信息科技有限公司 | 一种基于元数据自定义扩展的资源管理方法及系统 |
| CN111314414B (zh) * | 2019-12-17 | 2021-09-28 | 聚好看科技股份有限公司 | 数据传输方法、装置及系统 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1794663A (zh) * | 2005-12-31 | 2006-06-28 | 杭州华为三康技术有限公司 | 堆叠系统中文件的访问方法 |
| CN1996843A (zh) * | 2005-12-26 | 2007-07-11 | 北大方正集团有限公司 | 轻量级分布式文件存储系统及文件上传的方法 |
| CN101090401A (zh) * | 2007-05-25 | 2007-12-19 | 金蝶软件（中国）有限公司 | 一种群集环境下的数据缓存方法及系统 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101459571B (zh) * | 2008-12-16 | 2011-04-06 | 北京大学 | 一种网站镜像的方法、系统及装置 |
-
2009
- 2009-12-23 CN CN200910252514.5A patent/CN101764839B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1996843A (zh) * | 2005-12-26 | 2007-07-11 | 北大方正集团有限公司 | 轻量级分布式文件存储系统及文件上传的方法 |
| CN1794663A (zh) * | 2005-12-31 | 2006-06-28 | 杭州华为三康技术有限公司 | 堆叠系统中文件的访问方法 |
| CN101090401A (zh) * | 2007-05-25 | 2007-12-19 | 金蝶软件（中国）有限公司 | 一种群集环境下的数据缓存方法及系统 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108241648A (zh) * | 2016-12-23 | 2018-07-03 | 中兴通讯股份有限公司 | 一种数据处理方法及装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101764839A (zh) | 2010-06-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101764839B (zh) | 一种数据访问方法以及统一资源定位符服务器 | |
| CN102067094B (zh) | 高速缓存优化 | |
| US10374955B2 (en) | Managing network computing components utilizing request routing | |
| CN108319468B (zh) | 灰度发布方法、装置、系统及电子设备 | |
| CN102739720B (zh) | 分布式缓存服务器系统及其应用方法、缓存客户端 | |
| US8250171B2 (en) | Content delivery apparatus, content delivery method, and content delivery program | |
| CN101090371B (zh) | 一种即时通讯系统中用户信息管理的方法及系统 | |
| CN101046806B (zh) | 搜索引擎系统和方法 | |
| US7437461B2 (en) | Load balancing apparatus and method | |
| CN105024839B (zh) | 一种软件版本升级的方法及装置 | |
| CN102143243A (zh) | 动态路由处理方法和装置及其家庭网关 | |
| CN102739717A (zh) | 下载方法、下载代理服务器和网络系统 | |
| CN106464745A (zh) | Dns的服务器、客户端及数据同步方法 | |
| US20120278445A1 (en) | Load balancing system | |
| EP1565839B1 (en) | Index server support to file sharing applications | |
| US9137331B2 (en) | Adaptive replication | |
| CN101325499B (zh) | 静态数据的分发方法、系统和设备 | |
| CN108170745A (zh) | 一种访问web端缓存数据的方法及终端 | |
| CN101170442A (zh) | 软件在线升级方法及系统 | |
| JP2016099969A (ja) | 情報処理装置、データ保存システム、及びデータ保存方法 | |
| KR20150011087A (ko) | 컨텐츠 전송 서비스를 위한 분산 캐싱 관리 방법 및 이를 위한 중앙 관리 장치 | |
| CN106534285A (zh) | 一种访问方法及装置 | |
| CN105554159A (zh) | 一体化智慧社区云存储系统 | |
| US20210173878A1 (en) | Systems and methods of incremented aggregated data retrieval | |
| CN106790458A (zh) | 一种跨局域网的Memcache数据共享方法及系统 |
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 | ||
| C56 | Change in the name or address of the patentee |
Owner name: HUAWEI DIGITAL TECHNOLOGY (CHENGDU) CO., LTD. Free format text: FORMER NAME: CHENGDU HUAWEI SYMANTEC TECHNOLOGIES CO., LTD. |
|
| CP01 | Change in the name or title of a patent holder |
Address after: 611731 Chengdu high tech Zone, Sichuan, West Park, Qingshui River Patentee after: HUAWEI DIGITAL TECHNOLOGIES (CHENG DU) Co.,Ltd. Address before: 611731 Chengdu high tech Zone, Sichuan, West Park, Qingshui River Patentee before: CHENGDU HUAWEI SYMANTEC TECHNOLOGIES Co.,Ltd. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20220907 Address after: No. 1899 Xiyuan Avenue, high tech Zone (West District), Chengdu, Sichuan 610041 Patentee after: Chengdu Huawei Technologies Co.,Ltd. Address before: 611731 Qingshui River District, Chengdu hi tech Zone, Sichuan, China Patentee before: HUAWEI DIGITAL TECHNOLOGIES (CHENG DU) Co.,Ltd. |