場所に基づいてユーザーを別のサーバーにリダイレクトするにはどうすればよいですか？
ASP.NETを使用して開発されたWebサイトがあり、MY DBはMySQLです。現在、USAサーバーでホストされています。しかし、インドの近くでアクセスしようとすると、動的コンテンツの読み込みが遅すぎます。リクエストは世界の別の側に行かなければならないので、それは受け入れられます。アメリカでは本当に速いです。このサイトはすでにcloudflare CDNに接続しています。ただし、CDNは静的コンテンツには役立ちます。私のすべてのページにはほとんど動的なコンテンツがあります。
だから私はこのウェブサイトを拡大したいと思います。したがって、アメリカからのリクエストの場合は、USAサーバーからのリクエストを処理し、アジアからのリクエストの場合は、ASIANサーバーからのリクエストを処理します。ただし、リダイレクトされた場所に関係なく、コンテンツは2つのサーバーで同じである必要があることに注意してください。 （2つのサーバーを同期する必要があります）
では、このアーキテクチャを実現する方法は？
グーグル、フェイスブック、ヤフーはこれをどのように行うのですか？彼らはどのようにして世界中に奉仕しますか？彼らはすべての大陸にデータセンターを持っていると思います。それらはどのように互いに同期しますか？
@ Gabriel-Talaveraが回答した内容に加えて、いくつかのメモを追加します。
- ネットワークルーティング、および地理的負荷分散は、異なるサーバー間の「データ同期」とはまったく関係ありません。それらは、非常に多くの非常に異なるテクノロジーで対処される2つの問題です。
質問のタイトルはネットワーク側に焦点を当てているように思われるので、最初の部分（ネットワークルーティングの問題）に焦点を当てます。
- 厳密なネットワークの観点から、複数の場所/データセンターに負荷を分散するには、「 エニーキャストアドレス指定 "」を使用します。エニーキャストに関する有用なディスカッションは、この他のSF投稿で取得できます。
ご覧のとおり、小規模なICT企業では要件を満たせません。ただし、「グローバル」企業（OPで言及した企業など）は、問題なく採用することができます。
ちなみに、「エニーキャスト」について最初に聞いたのは、 CloudFlare BLOG post のおかげで、（...他の多くのことの中で）エニーキャストをどのように採用できるかについて話し合った。 D-DOS攻撃への対抗策。
外部DNSサーバーとしてBINDを使用している場合は、BINDビューの場所に基づいて 選択的DNS応答 を指定できます。 Windows Serverの新バージョンのテクニカルプレビューには DNSポリシー と呼ばれる機能があり、非常に有望に見えます。
クライアントの場所とユーザーエージェントやスケジュールなどの他の基準に基づいてコンテンツを提供するために、F5にはグローバルトラフィックマネージャーと呼ばれるアプライアンスがあり、ロードバランサーと組み合わせて使用することで目的の機能を実現します。クラウド環境では、AmazonのRoute 53でも同じことができます。
データの同期を維持するには、同期レプリケーションを実行できるストレージバックエンドを用意するか、MySQLが提供するレプリケーションを使用して、レプリケートされたデータの整合性を維持する必要があります。
あなたがしたい状況があります：
- シリアル化可能なトランザクションのデータ整合性が保証されます。
- ユーザーはグローバルにデータを更新できます。
- データは低遅延で更新できます。
残念ながら、上記のすべてを組み合わせることは物理的に不可能です。あなたは光速によって制約されます。
代わりに、正確な要件を検討する必要があります。一部のデータでは、精度を制限するだけで十分です。 YouTubeビデオのビューカウンターについて考えてみましょう。ほとんどの人は、ビューカウンターが一時的に少しずれていても気にしません。 10秒前に世界の反対側で発生したビューがまだ含まれていないが、5秒前に近くで発生したビューが含まれている場合でも、十分に正確です。ビューカウンターの整合性でリラックスしている場合は、2人の異なる人物が両方ともその特定のビデオの視聴者番号100であると考えるリスクがあります。しかし、ほとんどの人はそれによってもたらされる害は無視できると考えるでしょう。
その他の場合、データの整合性がより重要になります。 2人が同じユーザー名で同時にサインアップしようとしていると考えてください。ユーザー名を取得したことを両方の人に伝えることは受け入れられないため、そのような状況では、より完全性の高い、より遅いアプローチを選択します。両方のユーザーにユーザー名が取得されたことを伝えることは許容されます。したがって、考えられるアプローチは、各レプリカでユーザー名を予約し、レプリカの50％以上で成功した場合にのみ成功を報告することです。このアプローチでは、ユーザーが応答を受け取るまで0.5秒待つ可能性があります。しかし、ユーザーはその遅延に悩まされるほど頻繁にこのプロセスを実行しません。
さらに他の場合には、完全性と高速な更新が必要になることがありますが、この特定のデータを更新できるのは1人だけです。その場合、そのユーザーに近いと思われるサーバーにデータの信頼できるコピーを配置し、他のサーバーにキャッシュされたバージョン（ほとんどが最新）を持たせることができます。