工作上虽然和cdn没关系但是技术方向还是很多相似之处的,例如:负载均衡,缓存,分布式,路由等。
cdn简单的说就是个复杂的大缓存,由于目标用户(包括源和端)广泛直接导致了其复杂性,遍布广节点多则需要分流负载甚至自组织,应用繁杂则需要分流路由,提速则需要缓存,稳定则需要监控调度,为了透明则需要各种映射。
由于接入面广和网络的复杂性,不可能让客户端直接面对源,于是就有了专门接入客户端的边缘服务器/组,这些边缘服务器和后端的调度,监控,源服务器通讯。既然是缓存就 涉及到数据一致性的问题, 最简单的就是各接入端的边缘服务器在需要的时候到后台拉取,或者更智能的他们之间可以相互拉取,甚至后台调度提前推送。
边缘接收到请求后首当其冲的问题就是对请求的内容 “去哪找 ”和“怎么去 ”,想要知道内容的位置,一般缓存的实现不外乎就是统一到一个目录服务器找,或者广播所有自己知道的节点问一圈,更高效的方法是将请求url哈希后直接找到目的地址,当然只要是缓存都会过期也就有TTL的概念。“怎么去”的方式多种多样,由于互联网web服务居多基于DNS的路由使用最广泛,缺点是客户端和中继点会缓存,更新需要一定时间。HTTP重定向,URL改写,也有直接在网络设备路由器上做,直接在路由表中保持路径。这些方法在cdn这个庞杂的系统中根据需要使用,例如边缘服务器为了接收到客户端的请求可以使用dns重定向,然后再用哈希或者url改写转发到后端的源。
现如今的网络内容有许多是动态生成的,对这些无法提前缓存的内容可以直接略过只存静态内容(分段缓存),组装的时候发送回客户端或者直接赋予边缘服务器生成动态内容的能力(边缘计算)当然这对网页的制作有规范。
面向大众的服务都有潮汐效应,在热点时段的访问量是平时的几十上百倍(根据二八理论,80%的问题都是在20%的地方出现的,热点访问量也是大多访问小部分数据,如果能提前将热点缓存于各边缘服务器最直接有效),如果有自适应的动态调整功能整个服务会健壮很多。边缘服务器是离用户最近的,可以将每个节点看成组,组长监控负载自适应的添加删除组员(缓存服务器)以及更新dns,不允许组员跨组拉数据。当然如果客户端之间可以使用P2P相互取数据也是一个办法。
当前出现了基于流媒体的cdn,视频内容分发在后端以文件的形式传输(适合传输的格式更高效),到边缘服务器再以流的形式和客户端传输(不需要全部传完即可开始播放)。同时也要综合考虑时段需求,视频编码策略也很重要。
cdn简单的说就是个复杂的大缓存,由于目标用户(包括源和端)广泛直接导致了其复杂性,遍布广节点多则需要分流负载甚至自组织,应用繁杂则需要分流路由,提速则需要缓存,稳定则需要监控调度,为了透明则需要各种映射。
由于接入面广和网络的复杂性,不可能让客户端直接面对源,于是就有了专门接入客户端的边缘服务器/组,这些边缘服务器和后端的调度,监控,源服务器通讯。既然是缓存就 涉及到数据一致性的问题, 最简单的就是各接入端的边缘服务器在需要的时候到后台拉取,或者更智能的他们之间可以相互拉取,甚至后台调度提前推送。
边缘接收到请求后首当其冲的问题就是对请求的内容 “去哪找 ”和“怎么去 ”,想要知道内容的位置,一般缓存的实现不外乎就是统一到一个目录服务器找,或者广播所有自己知道的节点问一圈,更高效的方法是将请求url哈希后直接找到目的地址,当然只要是缓存都会过期也就有TTL的概念。“怎么去”的方式多种多样,由于互联网web服务居多基于DNS的路由使用最广泛,缺点是客户端和中继点会缓存,更新需要一定时间。HTTP重定向,URL改写,也有直接在网络设备路由器上做,直接在路由表中保持路径。这些方法在cdn这个庞杂的系统中根据需要使用,例如边缘服务器为了接收到客户端的请求可以使用dns重定向,然后再用哈希或者url改写转发到后端的源。
现如今的网络内容有许多是动态生成的,对这些无法提前缓存的内容可以直接略过只存静态内容(分段缓存),组装的时候发送回客户端或者直接赋予边缘服务器生成动态内容的能力(边缘计算)当然这对网页的制作有规范。
面向大众的服务都有潮汐效应,在热点时段的访问量是平时的几十上百倍(根据二八理论,80%的问题都是在20%的地方出现的,热点访问量也是大多访问小部分数据,如果能提前将热点缓存于各边缘服务器最直接有效),如果有自适应的动态调整功能整个服务会健壮很多。边缘服务器是离用户最近的,可以将每个节点看成组,组长监控负载自适应的添加删除组员(缓存服务器)以及更新dns,不允许组员跨组拉数据。当然如果客户端之间可以使用P2P相互取数据也是一个办法。
当前出现了基于流媒体的cdn,视频内容分发在后端以文件的形式传输(适合传输的格式更高效),到边缘服务器再以流的形式和客户端传输(不需要全部传完即可开始播放)。同时也要综合考虑时段需求,视频编码策略也很重要。