关于分布式服务器的分发技术

理工男海哥 发布于 2012/04/03 18:42
阅读 1K+
收藏 0

现在问题是这样:

比如现在的google应用市场,他们有一个总的服务器来存放用户上传的APP。

但是用户在现在APP的时候,需要重就近的服务器去下载APP。(比如中国的用户下载的APP是香港的服务器,美国的用户下载的APP是来之美国某洲的服务器)。

 

又如:

现在优酷网上有一个总的媒资服务器(存放媒体资源的),同时又在各个cdn节点上有自己的缓存服务器,比如联通100台,分布在北京,天津,上海,重庆等地方。电信100太服务器,也是分布在这些地方,移动100太服务器....

在上海的用户A上传了一个视频,此时这个视频是存放在总的媒资服务器上,现在北京的联通用户B来观看这个视频,这个时候服务器会去 北京的联通cdn节点查找这个视频....

 

现在问题是:

1、总的服务器是如何把媒资分发到这些cdn缓存节点?

2、cdn节点的容量是否和总的服务器容量相等?(才能装得下这些媒资)

3、这里面用到了哪些关键的技术?有相关的参考资料或者demo?

4、这么多的cdn节点,用户只要上穿一个视频,总的媒资服务器不是忙死了?忙于分发视频数据呀..

加载中
0
红薯
红薯

为什么一定要是分发呢,可以是各个分支节点需要什么资源就来中心服务器抓取,squid/varnish 就是干这事的。

理工男海哥
理工男海哥
那节点来总服务器抓取内容是什么时候呢?是用户访问节点服务器的时候?如果是这样,那节点服务器抓取内容后,才反馈给用户响应?这个过程是不是太慢了点?
0
红星xx
红星xx
squid/ varnish 就是干这事的 ,节点 装 squld  , 原理是就 反向代理 ,
0
中山野鬼
中山野鬼

这个事情,无非解决两个问题。

1、存储的利用

2、数据的传输路由。

上面两个问题有时会导致相互矛盾的解决方案出现。由此还有个总策略协调。

存储利用,和电脑的CACHE很像,也就是大家说的缓存镜像。如同你说了,如果就近的结点已经给A传递了内容,结点A如果有存储资源时,可以暂不删除,此时B也需要该内容时,就可以直接提供了,前提是数据没有更新。

而数据传输路由,这个和一般数通的问题很类似。

为什么说上面两个解决方案可能相反呢。比如,北京的客人需要的内容在上海镜像,上海的客人需要的在北京,而总内容都在南京。三点相互都有联通,不存在南京是北京和上海的必过路由结点。而且肯定北京和上海之间独立传输都慢。因此,针对传统方式,肯定都是均访问南京的总服务器。

而这个你也说了,总媚不得累死啊。而且北京和上海的通道还闲着,因此,更好的策略是上海的给北京,南京的给上海。这样总响应时间最好。但这是基于一个前提,北京和上海同时访问南京的方案时间要更长,不是路由问题,是服务器负载的问题。这些还是下载。

你说的上传,实际上也分两个问题。

数据存储,和数据获取,后者就是上面的下载问题。而数据存储,原则上和下载一样,就近存储,动态迁移。

如果你提到总媒就不是个真正对分布式系统,因为存在一个集中中央结点负责所有数据上传的备份。

分布式系统应该是,上海的视频,在上海存放,而成都下载的多 ,则该数据在成都的结点上,而不是上海,平时不会影响,但当成都和上海的服务器不够,知道存在其他结点有相同内容时,决策是否删除时,有用。也就是说,虽然上海成都都有存储,但因为成都访问的多,所以成都作为存储点,上海反而是镜像点,即便这个内容是由上海上传的。

特别是现在的云分布,上述究竟哪个结点对指定内容,作为备份保存点(即除非存在其他备份保存点,实际是个迁移工作,否则禁止删除),是动态发生的。根据访问情况。具体存储位置,是不可预知的。这就是云和传统分布式的差异。

返回顶部
顶部