Akamai 에지 서버는 캐시 된 컨텐츠를 공유합니까?

Question

Akamai Edge Server가 URL을 캐시하면 다른 Edge Server와 해당 콘텐츠를 공유합니까, 아니면 콘텐츠를 가져 오기 위해 로컬로 캐시 된 콘텐츠가없는 에지 서버가 원본으로 돌아갈 것입니까?

저는 공식적인 Akamai 문서를 갖고 싶지만 입력에 감사드립니다.

나는 이것을 시험해보고 답변이 무엇인지 알아보십시오. 가장자리 서버는 다른 에지 서버에 상주하더라도 콘텐츠를 가져 오는 데는 적어도 어느 정도 기원으로 돌아갈 것입니다.

예를 들어, 주말 내내 실행되는 curl을 사용하여 7 일 동안 캐시 된 리소스를 요청하고 캐시 된 응답이 3 가지 (응답 헤더별로 다름)했는지 확인하고 원본이 적어도 3 번 액세스했습니다.

$ cat /t/akamai_dump_requests_all_weekend.txt | grep x-rate-limit-reset| sort | uniq -c 
259 < x-rate-limit-reset: 1489776484 
    1 < x-rate-limit-reset: 1489779291 
12 < x-rate-limit-reset: 1489781137 

그리고 다른 엣지 서버가 내 덤프에 많이 표시되는 것을 볼 수 있습니다.

66 a80-12-96-140.deploy.akamaitechnologies.com 
65 a204-237-142-14.deploy.akamaitechnologies.com 
51 a204-237-142-44.deploy.akamaitechnologies.com 
38 a80-12-96-230.deploy.akamaitechnologies.com 
8 a65-158-180-197.deploy.akamaitechnologies.com 
6 a23-58-92-92.deploy.akamaitechnologies.com 
6 a23-58-92-39.deploy.akamaitechnologies.com 
5 a65-158-180-190.deploy.akamaitechnologies.com 
5 a64-145-68-25.deploy.akamaitechnologies.com 
5 a64-145-68-15.deploy.akamaitechnologies.com 
4 a65-158-180-180.deploy.akamaitechnologies.com 
4 a204-141-247-173.deploy.akamaitechnologies.com 
4 a204-141-247-143.deploy.akamaitechnologies.com 
2 a66-110-100-23.deploy.akamaitechnologies.com 
1 a72-37-154-53.deploy.akamaitechnologies.com 
1 a23-61-206-205.deploy.akamaitechnologies.com 
1 a205-185-195-182.deploy.akamaitechnologies.com 

Answer 1

내가 여기 이렇게 I posted this same question on the Akamai Community Forums을 답을 얻고, Neil Jedrzejewski에서 다음과 같은 응답, 아카 마이에서 수석 솔루션 아키텍트를 가지고 didnt한다. 네일 고마워!

First of all, which edge server answers a request will vary over time based on 
our low-level mapping system and load in a specific network region. Don't read 
too much into the fact that you get many different edge servers - swapping them 
in and out is part and parcel of how we give our customers scale and 
availability. 

To answer your question about shared caching, a high level explanation goes like 
this. 

When a client makes a request our mapping system will return the IP address(es) 
of an edge server best located to honour the request. These edge servers are 
grouped together in what we call network "regions". If a specific edge server 
receives a request and cannot fulfil it from it's own cache, it will send out 
a broadcast message (ICP) on it's back-plane asking if any other edge machine 
peers in the same region has the object. The timeout for a response to this 
request is very short (as the request is local) and if a peer has it, it will 
pass the request to the peer and served the response before caching it 
locally. 

If no local peer is able to satisfy the request, the edge machine will them go 
forward to it's cache parent as a new client request and the parent will attempt 
to satisfy the request (again, checking with it's own ICP peers), serving the 
object out of cache to the edge machine. The edge machine will then serve it 
back to the client and cache it locally for next time. If the object is 
unavailable or invalid (read: TTL expired) along the entire cache hierarchy 
chain, then yes, it will go back to origin to re-validate or reacquire the 
object. 

An important point to remember is that caching is "best effort" only. Although 
your TTL for an object was 7 days, that is simply an instruction to the cache on 
how long to consider the content "fresh" and a valid response for a request. 
However it is not a guarantee that the object will remain in a servers cache. 
Objects can and will drop out of cache if they are infrequently requested or due 
to other operational factors. This is where ICP and parent caches help because 
they help consolidate requests. So although an object may drop out of a specific 
edge cache, it may well still be in the cache parent as many edges are passing 
requests through it thus giving a high cache-hit ratio. 

So in short, our caching system. Will use different edge machines to respond to 
a request over time based on our mapping systems insight into which machine will 
best serve the client request. Will ask a local peer if it has a copy of an 
object if it cannot satisfy the request itself. Will forward the request to a 
cache parent if necessary to fulfil the request. Will go back to origin for the 
object if the object is "stale" or if itself, a peer or parent cannot satisfy 
the request. 

Hope that helps.