是本发明一部分实施例，而不是全部的实施例。基于本 发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实 施例，都属于本发明保护的范围。
[0057] 如图1所示，本发明实施例提供了一种⑶N网络负载均衡的实现方法，应用于⑶N 系统中的CDN调度服务器，该方法可以包括以下步骤：
[0058] 步骤101 :获取用户发送的访问请求，所述访问请求用于请求访问目标数据。
[0059] 步骤102 :对⑶N系统进行URL定位，得到第一设备集合。
[0060] 步骤103 :对所述第一设备集合中的每一个设备进行过滤，得到第二设备集合。
[0061] 步骤104 :从所述第二设备集合中确定出为用户提供目标数据的目标设备。
[0062] 步骤105 :并将所述访问请求调度给所述目标设备，以实现所述目标数据的访问。
[0063] 根据上述方案，通过定位到第一设备集合中的各个设备之后，继续对第一设备集 合中的各个设备进行过滤，并进一步在过滤后得到的第二设备集合中确定目标设备，通过 层层筛选出的目标设备，其负载性能较优，从而可以提高用户的访问速度。
[0064] 为使本发明的目的、技术方案和优点更加清楚，下面结合附图及具体实施例对本 发明作进一步地详细描述。
[0065] 如图2所示，本发明实施例提供了一种CDN网络负载均衡的实现方法，该方法可以 包括以下步骤：
[0066] 步骤201 :在互联网中构建⑶N系统。
[0067] 为了解决互联网的拥堵问题，在本实施例中，可以构建⑶N系统。
[0068] 构建的该⑶N系统可以包括两级结构，例如，该⑶N系统可以包括：全量点和边缘 节点。其中，全量点用于存储有所有数据内容，不直接对用户提供服务；边缘节点用于存储 部分数据内容，从全量点进行回源，直接对用户提供服务。
[0069] 为了降低全量点的回源压力，构建的该⑶N系统也可以包括三级结构，例如，该 CDN系统可以包括：全量点、区域中心和边缘节点。其中，全量点用于存储所有数据内容，不 直接对用户提供服务器；区域中心是选择的到CDN系统中各个边缘节点连通性比较好的节 点，存储有部分数据内容，从全量点进行回源，不直接对用户提供服务；边缘节点用于存储 少于区域中心所存储数据内容的数据，从区域中心进行回源，直接对用户提供服务。
[0070] 步骤202 :预先设置设备粒度，以及在每一个设备粒度下的定位方式。
[0071] 对于边缘节点中存储的数据内容，可以是直接存储在边缘节点中，可以是存储在 边缘节点所包括的服务器中，也可以是存储在某一个服务器的硬盘中，因此，在本实施例 中，该设备粒度可以包括：节点（Node)、服务器（Server)和硬盘（Storage)三类粒度，这三 类具有共同的父类设备（Device)。
[0072] 其中，该Device的数据结构，请参考图3。该Device数据结构中包括如下参数以 及每一个参数对应的含义：
[0073] name -名称
[0074] status - ENABLE/DISABLE，设备的有效性/设备的无效性，可以在配置文件中设 置
[0075] bandwidth -带宽上限
[0076] strategy - OPTIMISTIC (乐观）/PESSIMISTIC (悲观），监控策略，用于在无法获 取设备的监控结果时，是采用乐观策略界定设备有效，还是采用悲观策略界定设备无效
[0077] 请参考图4,为节点数据结构示意图，其中，图3为该节点数据结构的父级设备。根 据该图4可知，该节点数据结构还可以包括0- 个Server。以及为节点配置的参数信息可 以包括如下参数以及每一个参数的相应含义：
[0078] url -节点的基地址，虚拟节点（第三方⑶N)需要用到
[0079] weight -权重
[0080] priority -优先级
[0081] expand _ NODE/SERVER_HASH/SERVER_RANDOM/STORAGE_HASH/STORAGE_RANDOM，目 标数据URL定位的方式
[0082] upstream -回源节点
[0083] 请参考图5,为服务器数据结构示意图，其中，图3为该服务器数据结构的父级设 备。根据该图5可知，该服务器数据结构还可以包括Ο-m个Storage。以及为服务器配置 的参数信息可以包括如下参数以及每一个参数的相应含义：
[0084] url -服务器的基地址
[0085] stgc - Storage的数量，默认为12,编号0到11
[0086] 请参考图6,为硬盘数据结构示意图，其中，图3为该硬盘数据结构的父级设备。其 中，Storage根据服务器的stgc自动生成，一般不在配置文件中出现，其结构为：index -存 储编号，用来添加到服务器基地址的尾部。
[0087] 由于根据图3_图6可知，Node可以包括〇- 00个Server，Server可以包括〇- 00个 Storage，且Node、Server、Storage具有共同的Device，因此，每一个上级设备的参考可以 用于作为下级设备的参数参考值，例如，Device的status为有效时，表明其下级设备Node、 Server、Storage均有效；再如，Node的priority可以用于作为下级设备Server、Storage 的 priority。
[0088] 如表1所示，为本实施例提供的每一个设备粒度所对应的定位方式：
[0089] 表 1 :
[0091] 根据表1可知，对于设备粒度包括Node时，可以直接定位到CDN系统中的每一个 节点。对于设备粒度包括Server时，可以通过随机方式或计算每一个设备哈希值的方式进 行定位。对于设备粒度包括Storage时，可以通过随机方式或计算每一个设备哈希值的方 式进行定位。
[0092] 步骤203 :获取用户发送的访问请求，该访问请求用于请求访问目标数据。
[0093] 步骤204 :根据预先设置的设备粒度，以及根据该目标数据，对CDN系统进行URL 定位，得到第一设备集合。
[0094] 在本实施例中，可以根据表1中的定位方式对CDN系统进行URL定位，得到的第一 设备集合中可以包括每一个被定位到的设备名称。
[0095] 其中，在设置的设备粒度包括Node时，可以定位到该⑶N系统中的每一个Node，并 将定位的每一个Node添加到所述第一设备集合中；其中，该第一设备集合中可以包括多个 Node名称。
[0096] 在设置的设备粒度包括Server时，可以通过随机方式或计算每一个Server哈希 值的方式，定位到该CDN系统中的每一个Node上的目标Server，并将定位到的目标Server 添加到第一设备集合中；其中，该第一设备集合中可以包括多个Server名称。
[0097] 在设置的设备粒度包括Storage时，可以通过随机方式或计算每一个Storage哈 希值的方式，定位到该⑶N系统中每一个Node上的目标Server的目标Storage，并将定 位到的目标Storage添加到所述第一设备集合中。其中，该第一设备集合中可以包括多个 Storage 名称。
[0098] 其中，在利用随机方式定位设备时，对于同一个目标数据，定位到的设备可能不是 同一个设备，而在利用计算哈希值的方式定位设备时，对于同一个目标数据，每次计算都会 定位到相同的设备。
[0099] 步骤205 :根据预先设定的过滤规则对第一设备集合中的每一个设备进行过滤， 并根据预先设定的处理规则对未被过滤掉的设备进行处理，并将处理后的设备添加到第二 设备集合中。
[0100] 在本实施例中，对于每一个设备都可以包括如下参数信息：
[0101] 在本实施例中，可以预先设定过滤规则，该过滤规则可以包括如下任意一条或多 条：
[0102] 1、设备的CPU负载超过设定负载值，则将该设备过滤掉；
[0103] 2、设备的存活性为0,则将该设备过滤掉。
[0104] 在利用过滤规则对第一设备集合中的每一个当前设备进行过滤时，可以包括如下 步骤：获取当前设备所对应的参数信息，判断该参数信息是否满足该过滤规则，若是，则将 当前设备过滤掉。
[0105] 其中，获取的参数信息可以包括如下每一个数据结构中所对应的参数：
[0106] 请参考图7、图8和图9,分别为Realtime数据结构、IP数据结构和Distance数 据结构。
[0107] 其中，Realtime数据为获取的设备的状态数据，可以根据设定时间段周期性的从 监控系