Akamai 边缘服务器是共享缓存内容，还是去原点？
Do Akamai edge servers share cached content, or go to origin?
如果 Akamai 边缘服务器缓存了 url，它是否会与其他边缘服务器共享该内容，或者没有本地缓存内容的边缘服务器是否会返回原点以获取内容?
我很想为此获得官方的 Akamai 文档，但当然会感谢任何意见！
请注意，我已经对此进行了尝试，并且看到了我期望的答案 - 边缘服务器至少在某些时候会返回原点以获取内容，即使它位于另一台边缘服务器上。
例如，我整个周末都留下了一个curl 运行来请求一个缓存7天的资源，看到我得到了3个不同的缓存响应（响应头不同），并且可以看到origin至少被访问了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
我在这里没有得到答案，所以 I posted this same question on the Akamai Community Forums, and got the following response from Neil Jedrzejewski，Akamai 的高级解决方案架构师。谢谢尼尔！
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.
如果 Akamai 边缘服务器缓存了 url，它是否会与其他边缘服务器共享该内容，或者没有本地缓存内容的边缘服务器是否会返回原点以获取内容?
我很想为此获得官方的 Akamai 文档，但当然会感谢任何意见！
请注意，我已经对此进行了尝试，并且看到了我期望的答案 - 边缘服务器至少在某些时候会返回原点以获取内容，即使它位于另一台边缘服务器上。
例如，我整个周末都留下了一个curl 运行来请求一个缓存7天的资源，看到我得到了3个不同的缓存响应（响应头不同），并且可以看到origin至少被访问了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
我在这里没有得到答案，所以 I posted this same question on the Akamai Community Forums, and got the following response from Neil Jedrzejewski，Akamai 的高级解决方案架构师。谢谢尼尔！
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.