[Akamai] Global Distributed Content Delivery « Ashes of Time
http://repository.cmu.edu/cgi/viewcontent.cgi?article=2112&context=compsci
http://repository.cmu.edu/cgi/viewcontent.cgi?article=2112&context=compsci
一、需求：要又快又好地给user delivery content，就要
1.离得近。这里距离不是地理上的，而是网络上的，round-trip time、丢包率都是需要考虑的因素
2.Available。如果server的负载太大，或者说数据中心的带宽几乎已满，则对user来说，这个server是不available的。
3.似然性。这个概念比较好玩。因为我们不可能在每一台server上分布所有的content（我们必然要达成某种partition），那么我们如何尽快找到合适的server，避免forward就是一个很合理的requirement。
二、解决方案：用一个牛逼哄哄的DNS
Akamai使用了一个极为牛逼的DNS服务，它不断地检测server的各种状况，包括load，流量，并且检测用户的位置，所要求服务/内容的种类，网络状况等等，来将user引导到合适的数据中心。
三、杂七杂八的解决方案
在content provider上传内容时，尤其是媒体内容时，因为数据量较大，容易造成数据丢失，所以实际上上传过程要涉及多个entry point server——文章提到的数量是两个——一旦一个失效，其他的必须马上接过上传。然后entry point server将内容分布到edge server。
说到Availability，基本上首先就是replica，然后再去想别的。所以无论是monitor也好，内容的储存也好，DNS都要有若干的replica。然后就是当故障发生时，我们如何继续试图提供服务。在文章中提到了两个办法来解决用户连接到一个server后，看视频看到一半结果server挂了。这时候，首先服务端肯定要动，DNS要把那个坏掉的entry去掉或者指向其他的server；其次在客户端，因为DNS result可能有一个cache，所以我们需要在最初取DNS结果时，就发给客户端若干冗余信息，于是客户端可以去尝试不同的server；其次在服务端，其他的server应该很快pickup这个坏掉server的ip地址。
然后有一个问题是如何deliver动态内容。有一些根据user信息生成的内容，如广告，可能会嵌入在一个静态网页里。这个时候，需要拆分网页，cdn负责deliver静态内容，而动态内容还是需要服务来提供。
其他的内容不是特别有意思，不提了。
最后说一个文章中提到的数据，web proxy的cache hit rate只有25-40%
Read full article from [Akamai] Global Distributed Content Delivery « Ashes of Time