具体实施方式

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。

如前所述，目前CDN尚不能对业务方发起的刷新任务实现精细化管理。当刷新任务并发时，没有相应策略应对调度。为此，本文件旨在针对开发一种CDN内容管理系统，能够基于多队列优先级实现对CDN用户刷新任务的精细化调度、处理，从而满足高并发场景的需求。

图1是本发明实施例CDN内容管理系统的结构图，包括：应用程序接口模块110、发布订阅消息系统120、任务管理模块130、代理模块140和包括多个服务节点150的服务节点集群。其中：

应用程序接口模块110用于：接收CDN用户发起的刷新请求，针对刷新请求中待刷新内容的URL创建刷新任务，并将刷新任务发布至发布订阅消息系统120中与CDN用户的优先级相对应的主题队列中，其中，发布订阅消息系统包含有针对至少两种CDN用户的优先级所配置的先进先出的主题队列，且每一主题队列存放刷新任务的数量被设置为多个。

本发明实施例中，CDN用户的优先级可以根据CDN系统的服务策略灵活设置。比如，付费用户的CDN用户的优先级高于非CDN用户的优先级；再比如，来自CDN业务管理平台内部的CDN用户的优先级高于对其他CDN用户。这里，本文不对优先级的实现方式和确定方式作具体限定。

应用程序接口模块110具体可以对CDN用户发起的刷新请求进行解析，并将解析获得的URL进行封装成刷新任务，并将刷新任务发布到发布订阅消息系统110中。这里，发布订阅消息系统110具体配置有至少两个主题队列topic，每个topic对应有一个CDN用户的优先级分类。比如，将CDN用户的优先级设置为5个等级，则发布订阅消息系统110对应配置有5个先进先出规则的topic，即topic1至topic5。也就是说，假设topic1对应CDN用户的第一优先级，则应用程序接口模块110在第一时刻，将其中一个第一优先级的CDN用户A对应的刷新任务添加至topic1，之后，如果有第一优先级的CDN用户B发起刷新请求，则应用程序接口模块110将用户B的刷新任务按序添加至topic1，对于topic1的订阅者来说，会先从topic1中提取用户A的刷新任务后，再提取用户B的刷新任务。

在本发明实施例中，任务管理模块130作为topic的订阅者。任务管理模块130用于：按照优先级由高到低的顺序轮询发布订阅消息系统120中的主题队列以执行：提取刷新任务，将提取得到的刷新任务配置为由服务节点集群中服务节点执行的节点任务，将节点任务分配至代理模块140。

代理模块140用于：将从任务管理模块得到的节点任务转发至服务节点集群中对应的服务节点。

服务节点集群中的服务节点150用于：执行从代理模块140得到的节点任务，完成内容刷新。

本发明实施例的CDN内容管理系统针对CDN用户的优先级，构建发布订阅消息系统中对应的主题队列，在CDN用户发起的刷新请求，为刷新请求中待刷新内容的URL创建刷新任务，并将刷新任务发布至所述发布订阅消息系统中与CDN用户的优先级相对应的主题队列中，从而按照优先级由高到低的顺序轮询主题队列以执行：提取刷新任务，将提取得到的刷新任务配置为由服务节点集群中服务节点执行的节点任务。之后将节点任务通过代理模块分给服务节点完成内容刷新。显然，通过这种发布订阅消息系统的设定，当有大量刷新任务并发时，可以堆积在发布订阅消息系统中对应的主题队列中按照优先级顺序等待处理，从而限制任务管理模块单位时间的最大刷新任务的调度数量，以保证后端服务节点能够平稳完成刷新任务。

具体地，本实施例CDN内容管理系统的服务节点集群可以包含有不同运营商的服务节点。也就是容纳不同运营商的服务节点来组成CDN网络。对应地，任务管理模块可以按照运营商参与，即，同一运营商的任务管理模块负责将同一运营商的服务节点执行的节点任务分配至代理模块。为了避免不同运营商抢占发布订阅消息系统资源，可以将任务管理模块细分为赋能任务管理模块和非赋能任务管理模块。

其中，赋能任务管理模块和非赋能任务管理模块运营商不同，可以将CDN内容管理系统所属运营商下的任务管理模块作为赋能任务管理模块，第三方运营商参与进来的任务管理模块作为非赋能任务管理模块。本发明实施例中，只有赋能任务管理模块按照优先级由高到低的顺序轮询所述发布订阅消息系统中的主题队列，而非赋能任务管理模块不具有针对发布订阅消息系统的访问权限。当赋能任务管理模块在将读取得到的刷新任务配置为由服务节点集群中服务节点执行的节点任务后，将不属于本地运营商服务节点执行的节点任务移交至与该节点任务同一运营商下的非赋能任务管理模块。对应地，非赋能任务管理模块将从赋能任务管理模块获得的节点任务分配至代理模块。

这里，为了确保代理模块能够将节点任务转发到服务节点，代理模块的数量不宜过少。为此，本实施例的CDN内容管理系统可以向不同运营商开放参与代理模块的构建。也就是说，代理模块也以集群形式进行配置。这样一来，服务节点集群中的每个服务节点至少可以对应有一个代理模块负责转发节点任务，且服务节点在对应多个代理模块时，这些代理模块也不限于来自相同的运营商。

当任务管理模块获得刷新任务后，可以针对节点任务配置至少一条由代理模块到该对应的服务节点的路径，并不重复尝试选取一个路径将节点任务发送给该路径对应的代理模块，直至节点任务成功转发至对应的服务节点。其中，这里所述的路径是指代理模块到服务节点的传输路线。对于一个节点任务来讲，执行的服务节点是已经确定好的，但负责将节点任务转发给该服务节点的代理模块不限于一个，每个代理模块到该服务节点的传输路径都可以视为该服务节点下的一条路径。

进一步地，任务管理模块也可以根据节点任务对应的服务节点的路径配置策略，为节点任务配置至少一条由代理模块到该对应的服务节点的路径。比如说，必需包含指定运营商路径以及必需包含指定运营商路径的数量。假设，某个服务节点相对边缘化，为了确保该服务节点相能够收到节点任务，则可以针对该服务节点配置的路径配置策略为：必须包含3条实力较强的指定运营商的代理模块所构成的路径，任务管理模块在生成该服务节点的节点任务后，如果需要从中该服务节点已有的10条可用路径中配置5条路径尝试转发节点任务，则配置的5条路径中需要包含3条指定运营商下的代理模块所构成的路径。

在配置好路径后，任务管理模块还可以基于预先设置的路径选取策略，不重复尝试选取一个路径将节点任务发送给路径对应的代理模块。比如说，对应有资源占用率较低的代理模块的路径先于对应有资源占用率较高的代理模块的路径被选取。假设，某个服务节点配置好5条路径用于转发节点任务，则先选取其中一个代理模块CPU资源占用率最少的路径，尝试发送节点任务，如果服务节点未接收到节点任务，则再选取CPU资源占用第二少的代理模块的路径，以尝试发送节点任务，……，直至服务节点成功接收到节点任务。

此外，为了确保每个处理流程可查，还可以引入一个文件存储数据库于记录待刷新内容的URL对应在应用程序接口模块、任务管理模块、代理模块和服务节点中至少一者的执行状态信息。应理解，通过文件存储数据库记录各个流程的处理结果，可以方便进行故障定位。同时，由于文件存储数据库记录有每次待刷新内容的URL，应用程序接口模块在接收到CDN用户发起的刷新请求后，还可以基于件存储数据库中记录的已完成刷新的URL，对刷新请求中待刷新内容的URL进行去重。

此外，本实施例的CDN内容管理系统系统还可以利用个文件存储数据库记录CDN用户的刷新请求用量。应用程序接口模块在接收到CDN用户发起的刷新请求后，基于文件存储数据库中记录的该CDN用户的刷新请求用量，确定该CDN用户是否达到预先规定的刷新请求限额、且确定未达到刷新请求限额时，针对刷新请求中待刷新内容的URL创建刷新任务。比如，某一CDN用户被限制每天可以发起100次针对目录刷新的刷新请求，则对应地，文件存储数据库以一天为粒度，记录该CDN用户发起针对目录刷新的刷新请求的用量，如果当天该CDN用户已经发起过100次针对目录刷新的刷新请求，则应用程序接口模块不再对其受理目录刷新的刷新请求。在实际应用中，CDN用户的刷新请求限额可以作为用户信息进行维护，这里本文不对刷新请求限额的记录作具体限定。

此外，本实施例的CDN内容管理系统也可以与第三方其他CDN内容管理系统建立业务联系。比如，任务管理模块还可以缓存从发布订阅消息系统120中消费得到的刷新任务，并在满足预设条件时，将缓存的刷新任务对应的待刷新内容的URL提交至其他CDN内容管理系统，使得其他CDN内容管理系统基于待刷新内容的URL完成内容刷新，其中，任务管理模块存储有向其他CDN内容管理系统发送待刷新内容的URL的发送规则，这里，发送规则包括发送频率和/或每次发送待刷新内容的URL的数量上限。

在实际应用中，任务管理模块可以动态更新其他CDN内容管理系统对应的发送规则。比如，任务管理模块定期与其他CDN内容管理系统建立交互，获取其他CDN内容管理系统提供的用于该向其他CDN内容管理系统发送待刷新内容的URL的发送规则，之后任务管理模块将已存储的其他CDN内容管理系统对应的发送规则替换为新接收到的发送规则即可完成更新。

对应地，任务管理模块还可以向其他CDN内容管理系统确定其他CDN内容管理系统针对待刷新内容的URL的刷新执行结果，并将其他CDN内容管理系统针对待刷新内容的URL的刷新执行结果上传至文件存储数据库中进行记录。

下面结合实际的应用场景对本实施例CDN内容管理系统进行详细介绍。

为方便了理解，文中所涉及到名字及解释请参考下表所示。

本应用场景的CDN内容管理系统的架构示意图如图2所示，包括API集群(应用程序接口模块)、Kafka(任务管理模块)、Manager集群(任务管理模块)、Agernt集群(代理模块)、Cluster集群(服务节点)。

其中，如图3所示，API的工作流程如下：

1)接收业务方的刷新请求，根据刷新请求的路径决定任务优先级(详见优先级处理一节)。

2)获取业务方的IP地址(获取方式：X-Forwarded-For或RemoteAddr，前者优先)。

3)为此刷新请求生成一个唯一的TaskID。

4)根据刷新请求的请求路径，判断刷新任务类型Type。

5)解析刷新请求的请求体，获取业务方的KID以及任务中包含的URLs，如果解析失败，则返回错误信息，并将此任务和错误信息存入Mongo的任务表(参考附录Mongo的任务表结构)中，结束处理。

6)检查此刷新请求是否重复，如果是重复请求，则返回错误信息，并将任务和错误信息存入Mongo的任务表中，结束处理。(重复请求的判定条件为一个时间周期内出现过相同的请求，时间周期可配置；相同请求的判定条件是HTTPPOST请求的BODY的MD5值一致)。

7)检查该业务方的该业务类型的已入库URL数量，是否已经超过当日限额，如果超过，则返回错误信息，并将任务和错误信息存入Mongo的任务表中，结束处理。(限额由Console管理，每个业务方CDN用户的各类型业务具有独立的限额)。

8)通过上述检查后，将刷新请求正常存入Mongo的任务表中。

9)依此处理任务中的所有URL，如图4所示，处理一个URL的流程如下：

a)验证上述KID是否有权限操作此URL，如果无权限，则将该URL和权限错误信息存入Mongo的URL表(参考附录Mongo的URL表结构)中，结束本条URL处理，继续处理下一条URL。

b)检查该URL是否为重复URL，如果是重复URL，则将该URL和重复信息存入Mongo的URL表中，结束本条URL处理，继续处理下一条URL。(重复URL的判定条件是一个时间周期内出现过相同的URL，时间周期可配置)。

c)将此URL和任务类型、任务创建时间等基本信息封装为一个刷新任务，刷新任务发送到主Kafka集群。

d)如果发送主Kafka集群失败，发送至备用Kafka集群。

e)如果发送备用Kafka集群失败，则将该URL和出错信息存入Mongo的URL表中，结束本条URL处理，继续处理下一条URL。

f)如果发送正常，则记录一条API刷新任务日志(日志格式参考附录APIAccess日志格式)，将该URL正常存入Mongo的URL表中，并将状态设置为pending(URL状态说明见附录)，继续处理下一条URL。

10)将上述所有正常处理的URL的数量更新到Mongo的用户额度用量表中。

11)将上述所有URL的出错信息放入给业务方的应答中，返回应答(出错信息包含所有出错的URL以及每个URL对应的错误)。

其中，上述流程中权限检查需要的基础数据来自Console，Console上维护着各个业务(域名)的管理员信息，以及管理员的各项限额，API以固定的时间间隔来更新相关信息存储到内存中，供随时检查。上述流程中限额检查需要的用户限额数据来自Console，Console上维护的用户信息表中包含该用户可使用的每日刷新限额，每日预热限额和每日目录刷新限额。API在运行过程中以固定时间间隔来更新相关信息存储到内存中，并在每次处理完任务请求后，将该用户的用量更新到Mongo数据库的用户用量表(参考附录Mongo的用户用量表结构)，每次处理任务请求之前，从Mongo数据库中读取该用户用量并根据本地内存中缓冲的限额信息，判定该用户该类型任务是否已经超过限额。

Kafka(发布订阅消息系统)

本应用场景中，通过Kafka的多队列，来实现多个任务优先级；比如，设计共五个优先级，使用了Kafka的5个不同Topic进行区分。

优先级生效的基本流程是：

1)在API服务之前部署有Nginx7层网关，负责接收业务方或者CDN内容管理系统管理员发送的任务请求。而任务的优先级取决于Nginx网关的路径替换配置，例如业务方请求的路径为/object/purge，则Nginx将其转换为/purge/send3，作用是将所有业务方请求的优先级设定为3。

2)API收到Nginx转发的请求，根据上述/purge/send3路径，将该任务发送到Kafka的Topic3。

3)Manager每次消费Kafka数据，都按照Topic1到Topic5的顺序，保证了按照优先级进行处理。

Manager

如上文所述，API负责解析刷新请求，并将刷新请求拆解成多个刷新任务(每条URL对应一个刷新任务)，将刷新任务发送到Kafka的某个优先及相对应的Topic中，而接下来Manager负责真正的处理这些刷新任务。由于Manager功能复杂，下面分开描述其各项处理流程。

Manager启动时需要进行多项初始化工作，流程图如图5所示，包括：

1)解析配置文件，如果解析失败，则报错退出。

2)打开PID文件，如果失败，则报错退出；如果文件内容已经存在，则报错已经有进程正在运行，退出。

3)将进程放入后台(通过exec启动新的进程，老的进程退出)。

4)将进程编号写入PID文件。

5)根据配置，设定程序使用的最大CPU核数。

6)初始化数据库相关服务：

a)建立Mongo数据库连接。

b)将Manager自身信息(Hostname、IP、ISP)写入Mongo数据库中，用于Manager之间服务发现。

7)初始化路径选择相关服务：

a)从Console获取所有的Agent信息和CDN节点信息。

b)根据上述信息初始化所有路径(一个Agent和一个RS构成一条Path)，简称AllPath。

c)设定定时器(定期执行上面两个步骤，也即更新All Path)，并定时更新所有人工选路策略(所谓人工选路策略是指CDN管理员在Console上为某些小运营商节点手工配置的Agent，支持配置多个并指定优先级)。

8)初始化RPC：

a)从Mongo中获取所有Manager的信息(如上文所述，每个Manager启动时会上报自身信息到Mongo)，并根据每个Manager的运营商信息，与其他Manager建立RPC连接；完成首次操作后，设定定时器定时执行类似操作，目的是自动发现新的Manager，并加入服务。

b)与所有Agent建立RPC连接，完成首次操作后，设定定时器定时执行类似操作，目的是自动发现新的Agent，并加入服务。

c)设定定时器，定时对所有Agent进行CPU idle的探测以及健康检查(定时检查被标记down的路径)。

9)启动主服务：

a)初始化发送器Sender。

i.初始化负责给自建服务节点发送消息的协程池(简称“节点任务协程池”)。

ii.初始化第三方商业CDN服务(获取各家的CDN服务域名列表)，并设定定时器定时更新。

b)启动任务读取，根据配置文件，为每个Kafka Topic创建一个reader，负责读取Kafka消息，并将刷新任务(也即一条URL)放到各自的缓冲区中(缓冲区满会导致相应reader停止读取，缓冲区有空间，reader又自动开始读取)。

c)初始化“刷新任务协程池”，每个“刷新任务协程”负责处理一个刷新任务(URL)。

d)启动主循环，每次循环处理流程如下：

i.根据优先级读取上述多个reader的缓冲区，仅读取一条刷新任务。

ii.唤起一个“刷新任务协程”处理上述刷新任务(“刷新任务任务协程”的处理流程见下文)。

iii.如果本次循环未读取到刷新任务，则sleep 10毫秒，进行下次循环。

10)启动代理服务，代理服务负责接收其他Manager代理过来的节点任务(处理流程见下文)。

刷新任务的处理流程：

如上文所属，每个刷新任务拥有专用的“刷新任务协程”，协程内部的处理流程如下：

1)更新刷新任务(URL)在Mongo数据库中的状态为Processing(URL状态说明见附录)。

2)给自建CDN的三级服务节点发送任务，也即为每个三级服务节点创建一个“节点任务协程”，等待全部发送完毕，其中一个“节点任务协程”的处理流程见下文“节点任务的处理流程”。

3)所有三级服务节点发送完毕后，给自建的所有二级服务节点发送任务，流程同上。

4)所有二级服务节点发送完毕后，给自建的所有边缘节点发送任务，流程同上。

5)在发送给边缘节点的同时，将该URL发送给其他第三方商业CDN，发送给一家第三方商业CDN的流程见下文“第三方商业CDN的发送流程”

6)等待三级，二级和边缘节点都发送完毕，记录一条刷新任务处理完毕日志。

节点任务的处理流程：

如上文所述，所谓节点任务是指，Manager为了将刷新任务(URL)发送到一个服务节点而创建的任务协程(“节点任务协程”)。

如图6所示，具体流程描述如下：

1)判断目标服务节点与manager是否属于同一个运营商(小运营商有专用的Manager，其运营商信息为other)。

2)如果不属于同一个运营商，则将节点任务通过Manager集群间的RPC连接，代理到其他负责此运营商的Manager上，由该Manager处理完成，再将结果返回；如果结果正常，则本次节点任务结束，如果代理结果失败，则继续。

3)请求“路径分配器”，获取N条路径，N取决于本地配置或Console配置，Console配置优先。其中“路径分配器”的工作原理见下文。

4)依次尝试上述N条路径，所谓尝试是指通过RPC将节点任务发送给路径中的Agent，等待Agent返回处理结果，如果Agent超时未返回，或者返回失败信息，则更新相关路径的健康信息。(如果一条路径在一个时间窗口内连续失败次数达失败次数上限，则标记为down，时间窗口和失败次数限制可配置)

5)如果Agent返回正常结果，则结束尝试，否则继续尝试剩余路径。

6)以上每次尝试都会记录一条Manager Access日志(日志格式见附录ManagerAccess日志格式)。

路径分配器的工作流程：

如上文所述，当Manager发送一个“节点任务”的时候，会调用路径分配器，获取N条网络路径以供尝试。也就是说路径分配器决定了一个“节点任务”的网络下发路径，也就决定了该“节点任务”的成功率。路径分配器的调用参数为目标节点的运营商和节点名，以及索取的路径条数N。

如图7所以，路径分配器的路径选择流程图如下：

1)查询“人工选路策略”，如果发现Console为此节点指定了策略，或者Console为此服务节点所在的运营商指定了策略，则从指定策略(节点策略优先)中，按照优先级依次循环创建多条路径，创建一条路径的流程如下：

a)从略中选取一个Agent，然后随机从节点中选取一个RS，通过Agent+RS查询此条路径的状态是否被健康检查功能标记为Down，如果Down，则忽略本Agent，进入下次循环。

b)如果UP，则将此路径放入待返回的路径集合中。

c)如果路径集合中数量达到N，则结束循环。

2)如果上述流程处理完，路径集合中数量已经达到N，则直接返回该路径集合给调用者；否则继续。

3)上述流程处理完，仅获取到M条人工路径(0<＝M<N)，那么仍需获取N-M条智能路径，具体流程如下：

a)如果目标服务节点为实力较强的大运营商(可指定)，则多次随机选择一个同运营商的Agent，并搭配一个随机的RS，如果该Agent+RS路径状态异常，则跳过；如果状态正常，则假如临时集合，直到临时集合的路径数量达到N-M或者该运营商的所有Agent都被遍历。结束该循环后，将临时集合中的所有路径按照Agent的CPU空闲都进行排序，CPU空闲的排在前面；之后将排序后的所有路径按照顺序放入待返回路径集合中。

b)如果目标运服务节点为小运营商，如上文所述，这里仍需获取N-M条智能路径，首先尝试获取(N-M+1)/2条同运营商路径，假设成功获取K条，然后再获取大运营商备用路径N-M-K条，获取流程为随机选择一个大运营商，然后按照与上述相同的流程，获取N-M-K条路径。

4)上述所有流程处理结束后，将路径集合返回给调用者，集合中的路径数量大于等于0，小于等于N。

代理服务的处理的流程：

如上文所述，Manager会将其他运营商的节点任务代理给其他运营商的Manager，其他运营商收到该节点任务后的处理流程如下：

1)请求“路径分配器”，获取N条路径，N取决于本地配置或Console配置，Console配置优先。

2)依次尝试上述路径，所谓尝试是指通过RPC将节点任务发送给路径中的Agent，等待Agent返回处理结果，如果Agent超时未返回，或者返回失败信息，则更新相关路径的健康信息。

3)如果Agent返回正常结果，则结束尝试，否则继续尝试剩余路径。

4)以上每次尝试都会记录一条Manager Access日志(日志格式见附录ManagerAccess日志格式)。

第三方商业CDN的发送流程：

1)如前所述，“刷新任务协程”会在合适的实际将URL发送给商业CDN，这里所谓的发送，只是将该URL放入任务缓冲区(每家商业CDN，每种任务类型，都有独立的缓冲区)。

2)每家商业CDN的服务协程(在初始化时已经创建好)会不断的读取相关任务缓冲区，如果发现任务达到批量限制或者举例上次提交任务已经超过1秒，则会将缓冲区中的任务分批提交，其中各家CDN各种业务类型的批量限制维护在Manager的配置文件中。

3)在提交任务后，每家商业CDN的服务协程会定时查询相关任务的处理结果，查询间隔和最大查询次数维护在Manager的配置文件中和Console中，Console配置优先级高于本地配置文件。

4)查询结束后，将状态更新到Mongo的URL表中(每家商业CDN都有专属的一列状态信息)，更新后状态可能为timeout、failed、complete。

Agent

如上文所述，Agent的作用是在Manager和RS之间充当RPC到HTTP的协议转换代理，也就是说Manager通过RPC将URL和目标RS发给Agent，Agent把URL通过HTTP协议将URL发送给指定RS，然后将发送结果通过RPC应答给Manager。另外如上文所述，Manager在分配路径的时候会参考Agent的CPU空闲度，所以Manager还会通过RPC请求Agent的CPU空闲度。因此Agent的工作流程分为两部分描述。

获取CPU空闲度：

为了能够获取CPU空闲度，Agent在启动时会进行CPU监控服务，具体来说每隔一分钟获取CPU的各项统计信息，并按照差值计算CPU的空闲程度。之后Agent启动RPC服务，接收相关请求，并访问CPU监控服务的数据，再通过RPC返回给Manager。

Agent处理节点任务：

处理节点任务是Agent的核心功能，如图8所示，具体处理流程描述如下：

1)接收RPC请求，根据请求中的任务类型(刷新、预热、目录刷新)来调用不同的处理逻辑。

2)刷新和目录刷新的处理逻辑：

a)创建HTTP请求。

b)设置Method为PURGE。

c)修改User-Agent为sinaedge-purge-agent。

d)添加CDN内容管理系统的鉴权信息。

e)如果是目录刷新，则添加”PurgeType:Directory”头部以指示任务类型为目录刷新。

f)发送请求(超时时间3秒)。

3)预热的处理逻辑：

a)创建HTTP请求。

b)设置Method为GET。

c)修改User-Agent为sinaedge-purge-agent。

d)根据URL域名信息，添加业务防盗链信息。

e)添加“Range:bytes＝0-1”的头部信息，以限定文件中需要请求的字节。

f)发送请求(超时时间3秒)。

4)通过RPC返回上述处理的结果。

附录

Mongo的任务表结构：

Mongo的URL表结构：

URL状态说明：

上述URL表中有Edge1Status等共3列自建CDN进度，ALIStatus等共4列商业CDN进度；这些“进度”(status)的可能值有：

1)invalid(API识别到URL有误，无法处理，同时标记上述7个status为invalid)。

2)kafkafailed(API发送URL到kafka失败，同时标记上述7个status为kafkafailed)。

3)pending(API将任务发送kafka后，同时标记上述7个status为pending)。

4)processing(Manager从kafka中取出URL，开始处理前，同时标记上述7个status为processing)。

5)complete(自建发送完所有节点，或者商业CDN明确告知处理完成)。

6)timeout(仅商业CDN的status会出现timeout，当查询一直获取不到结果时标记)。

7)failed(仅商业CDN的status会出现failed，当发送失败或者第三方明确告知失败时标记)。

8)needless(仅商业CDN的status会出现needless，当发现商业CDN不服务此域名时标记)。

Mongo的用户用量表结构：

API Access日志格式

access.log日志示例：

2020/03/24 14:54:13.068[A][task.go:321]"s3kid＝""s3key＝-""user＝guangsheng""create_time＝2020-03-24 14:54:12""taskid＝45138e96-6d9c-11ea-86e1-5cb90196be28""url＝http://wx2.sinaimg.cn/mw2000/0067NLi6ly1gd50uiimufj308w06oaa6.jpg""type＝""path＝/task/send3"

字段含义如下：

Manager Access日志格式

access.log日志示例：

2020/03/24 03:00:01.065[A][sender.go:75]"createTime＝2020/03/2402:59:45.379""user＝guangsheng""agentName＝all""usedProxy＝false""clusterName＝all""clusterLevel＝0""taskId＝76040745-6d38-11ea-9be0-5cb90196be28""url＝http://wx3.sinaimg.cn/bmiddle/007xK4P4ly1gd4g6ufouoj30rs0fndiy.jpg""type＝1""serverName＝all""usedTime＝16""waitTime＝0""agentUsedTime＝0""retry＝0""code＝200""status＝complete""err＝-"

为了上报方便，日志集合了3种类型的日志，某些字段被复用，可能导致理解上的问题，相关字段会特殊说明。

日志类型说明：

1)发送一次自建服务节点的日志。

2)针对一个URL，发送完自建所有节点后的一条URL结束日志。

3)针对一个URL，获取完一个商业CDN后的一条商业CDN处理日志。

为了方便理解，简单描述一条URL的处理流程以及何时生成日志：

1)开始处理一条URL。

2)获取所有的自建节点，每个节点都要发送该URL，假设节点数为100，则至少生成100条第一类日志，如果有重试，则会多于100条；也即每次尝试都有一条日志。

3)所有节点发送完毕后，生成一条第二类日志，也即一个URL只有一条第二类日志。

4)在上述处理过程中，对商业CDN的调用和结果查找也在进行，每家商业CDN生成一条日志。也即一个URL会生成N条第三类日志，N＝商业CDN数量。

以下该日志内具体字段的解释

综上所述，本应用场景的CDN内容管理系统具有以下优点：

1)架构可靠，经常导致调度过程任务丢失。

2)具备优先级处理和限额等功能，实现对业务方的精细管理。

3)具有智能选择网络路径的能力，提高刷新执行的成功率。

4)具备可靠的反馈和数据搜集机制，能够进行准确的数据分析和问题排查。

5)对第三方商业CDN的智能批量发送功能，并获知第三方商业CDN的处理结果。

6)具备重复任务识别能力，避免执行过多重复任务耗费系统资源。

7)可分离CDN成为独立的系统，不同运营商的CDN可以通过一套本发明实施例的系统实现内容管理。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上仅为本说明书的实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。此外，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本文件的保护范围。