Как перенаправить пользователей на разные серверы в зависимости от их местоположения?

У меня есть веб-сайт, который разработан с использованием ASP.NET, и МОЯ БД - MySQL. В настоящее время он размещен на серверах США. Но когда я пытаюсь получить доступ к нему около Индии, динамическое содержимое загружается слишком медленно. Это приемлемо, так как запрос должен идти в другую сторону мира. В США это действительно быстро. Я уже связал этот сайт с CDN cloudflare. Но CDN полезен для статического содержимого. Каждые мои страницы почти имеют динамическое содержание.

Поэтому я хочу масштабировать этот сайт. Поэтому, если запрос пришел из Америки, я хочу обработать этот запрос с сервера США, а если запрос пришел из Азии, я хочу, чтобы он обработал с сервера ASIAN. Но имейте в виду, независимо от того, куда они были перенаправлены, контент должен быть одинаковым на двух серверах. (Два сервера должны быть синхронизированы)

Так как же добиться этой архитектуры?

Как Google, Facebook, Yahoo это сделать? Как они служат во всем мире? Я думаю, что у них есть центры обработки данных на каждом континенте. Как они синхронизируются друг с другом?

В дополнение к тому, что ответил @ Gabriel-Talavera, я бы добавил пару заметок:

• Сетевая маршрутизация, а также географическая балансировка нагрузки совершенно не связаны с «синхронизацией данных» между различными серверами. Это две проблемы, решаемые множеством совершенно разных технологий.

Поскольку заголовок вашего вопроса, кажется, сфокусирован на сетевой части, я сосредоточусь на первой части (проблемы сетевой маршрутизации).

• Со строгой точки зрения сетевого взаимодействия распределение нагрузки по нескольким местоположениям / центрам обработки данных может быть достигнуто с помощью « произвольной адресации ». Полезная дискуссия о anycast может быть найдена на других постах SF:
  • Что такое «Anycast» и как это полезно?
  • Что необходимо для использования anycast IP?

Как вы сами видите, небольшие компании, работающие в сфере ИКТ, трудно удовлетворить требованиям. Но у «глобальных» компаний (например, тех, которые вы упомянули в своем ОП) не возникнет проблем с его принятием.

В качестве примечания, я впервые услышал об «anycast» благодаря публикации в блоге CloudFlare , где они обсуждали (... среди множества других вещей), как anycast также может быть принят в качестве меры противодействия D- DOS-атаки.

Вы можете давать выборочные ответы DNS на основе местоположения с помощью BIND Views, если вы используете BIND в качестве внешнего DNS-сервера. В техническом обзоре новой версии Windows Server также есть функция DNS Policies, которая выглядит очень многообещающе.

Чтобы обслуживать контент на основе местоположения клиента и других критериев, таких как пользовательский агент или расписания, у F5 есть устройство под названием Global Traffic Manager, которое используется в сочетании с их балансировщиками нагрузки и достигает того, что вы ищете. В облачных средах Amazon Route 53 может достичь того же.

Чтобы обеспечить синхронизацию данных, у вас должен быть внутренний сервер хранения, способный выполнять синхронную репликацию или использовать репликацию, предоставляемую MySQL, которая будет поддерживать согласованность реплицируемых данных.

Есть ситуации, когда вы хотели бы иметь:

• Целостность данных гарантирует сериализуемые транзакции.
• Данные могут обновляться пользователями по всему миру.
• Данные могут быть обновлены с низкой задержкой.

К сожалению, комбинация всего вышеперечисленного физически невозможна. Вы будете ограничены скоростью света.

Вместо этого вам нужно учитывать ваши точные требования. Для некоторых данных ограниченная точность достаточно хороша. Рассмотрим счетчик просмотров на видео YouTube. Большинству людей все равно, временно ли отключен счетчик просмотров. Если представления, которые произошли 10 секунд назад на другой стороне мира, еще не включены, но включены виды, которые произошли 5 секунд назад ближе, это все еще достаточно точно. Если вы настолько расслаблены целостностью счетчика просмотров, вы рискуете, что два разных человека могут подумать, что они просмотрели номер 100 этого конкретного видео. Но большинство людей сочли бы вред, нанесенный этим, незначительным.

В других случаях целостность данных важнее. Рассмотрим двух человек, одновременно пытающихся зарегистрироваться с одним и тем же именем пользователя. Сказать обоим людям, что они получили имя пользователя, недопустимо, поэтому в такой ситуации вы бы выбрали более медленный подход с большей честностью. Допустимо сообщить обоим лицам, что имя пользователя было взято, поэтому возможный подход состоит в том, чтобы попытаться зарезервировать имя пользователя на каждой реплике и сообщать об успехе только в том случае, если вам удалось более чем на 50% реплик. Весьма вероятно, что при таком подходе пользователь будет ждать полсекунды, чтобы получить ответ. Но пользователи не проходят этот процесс достаточно часто, чтобы беспокоиться о такой задержке.

В других случаях вам может потребоваться хорошая целостность и быстрые обновления, но только один человек может обновить этот конкретный фрагмент данных. В этом случае вы можете поместить достоверную копию данных на сервер, который, по вашему мнению, близок к этому пользователю, и позволить другим серверам иметь кэшированную версию, которая в основном обновлена.