同一CDN配置文件下同源双CDN端点的工作机制与请求路由咨询

Great question—this is a scenario that trips up a lot of folks when scaling or testing CDN setups. Let’s break down the mechanics clearly:

• Endpoint Independence: Even with the same origin hostname, each CDN endpoint operates as a siloed resource. They have their own unique edge network footprint, cache storage pool, configuration rules (like TTLs or compression settings), and usually a distinct domain name (e.g., cdn-east.yourapp.com and cdn-west.yourapp.com). No automatic cache sync or traffic coordination happens between them unless you explicitly set it up.
• Request Routing Basics: By default, CDNs don’t route requests across multiple endpoints for the same origin on their own. A user’s request only goes to the specific endpoint whose domain they’re accessing. If your app links to cdn-east.yourapp.com for assets, all those requests hit that endpoint’s edge nodes—cdn-west won’t see any traffic unless you direct it there.
• Unified Domain Scenarios: Some CDNs let you attach multiple endpoints to a single custom domain via traffic management tools. For example, you could set up weighted routing to send 60% of traffic to one endpoint and 40% to the other, or geo-routing to send US users to the east endpoint and EU users to the west. But this is a deliberate configuration, not an automatic behavior.

Short answer: No, not by default. Here’s why and how to make it happen if you need to:

• Default Isolation: Without explicit traffic splitting rules, each endpoint operates independently. Users only interact with the endpoint whose domain is resolved by their DNS query.
• How to Distribute Traffic: If you want requests to reach all your endpoints, you’ll need to implement one of these strategies:
  • DNS Round Robin: Configure your domain’s DNS to return both endpoint domains/IP addresses in a rotating order. This is basic load balancing, but it doesn’t account for edge node health or user proximity.
  • CDN Traffic Policies: Use your CDN’s built-in traffic management features (weighted routing, performance-based routing, A/B testing rules) to split traffic between endpoints. This is the most reliable option, as most CDNs adjust routing based on real-time edge performance.
  • Client-Side Splitting: Have your application dynamically direct subsets of users to different endpoints (e.g., 50% to cdn1, 50% to cdn2) for testing or redundancy.

• Cache Sync Issues: Since each endpoint has its own cache, content updates to your origin might propagate at different rates across each endpoint’s edge nodes. For immediate consistency, you’ll need to purge the cache on both endpoints separately.
• Billing & Monitoring: Each endpoint generates its own usage metrics and billing line items. Make sure you track both to avoid unexpected costs and monitor performance across your setup.
• Redundancy Benefits: This setup adds resilience—if one endpoint experiences an outage, the other can continue serving traffic (as long as users are directed to it). Just remember redundancy only works if you’re splitting traffic between endpoints.

内容的提问来源于stack exchange，提问作者chipri