У меня есть веб-сайт, разработанный с использованием ASP.NET, а МОЯ БД - MySQL. В настоящее время он размещен на серверах США. Но когда я пытаюсь получить к нему доступ около Индии, динамическое содержимое загружается слишком медленно. Это приемлемо, так как запрос должен идти на другой конец света. В США это действительно быстро. Я уже подключал этот сайт к Cloudflare CDN. Но CDN полезен для статического содержимого. У всех моих страниц почти динамическое содержимое.
Итак, я хочу масштабировать этот сайт. Поэтому, если запрос пришел из Америки, я хочу обработать этот запрос с сервера США, и если запрос пришел из АЗИИ, я хочу, чтобы он обрабатывался с АЗИАТСКОГО сервера. Но имейте в виду, что независимо от того, куда они были перенаправлены, контент должен быть одинаковым на двух серверах. (Два сервера должны быть синхронизированы)
Так как же добиться этой архитектуры?
Как это делают Google, Facebook, Yahoo? Как они служат по всему миру? Я думаю, что у них есть центры обработки данных на каждом континенте. Как они синхронизируются друг с другом?
В дополнение к тому, что ответил @ Gabriel-Talavera, я бы добавил пару примечаний:
Поскольку название вашего вопроса, похоже, сосредоточено на сетевой стороне, я сосредоточусь на первой части (проблемы сетевой маршрутизации).
Как вы сами видите, небольшим компаниям ИКТ сложно удовлетворить требования. Но у «глобальных» компаний (вроде тех, что вы упомянули в своем ОП) не возникнет проблем с его внедрением.
Кстати, я впервые услышал о "anycast" благодаря Сообщение в БЛОГЕ CloudFlare, где они обсуждали (... среди прочего), как anycast можно также использовать в качестве меры противодействия атакам D-DOS.
Вы можете дать выборочные ответы DNS на основе местоположения с BIND Views, если вы используете BIND в качестве внешнего DNS-сервера. Техническая предварительная версия новой версии Windows Server также имеет функцию под названием Политики DNS что выглядит очень многообещающе.
Для обслуживания контента на основе местоположения клиента и других критериев, таких как пользовательский агент или расписания, у F5 есть устройство под названием Global Traffic Manager, которое используется вместе с их балансировщиками нагрузки, чтобы достичь того, что вы ищете. В облачных средах Amazon Route 53 может сделать то же самое.
Чтобы синхронизировать данные, вы должны иметь серверную часть хранилища, способную выполнять синхронную репликацию, или использовать репликацию, предоставляемую MySQL, которая будет поддерживать согласованность реплицированных данных.
Есть ситуации, в которых вы хотели бы иметь:
К сожалению, сочетание всего вышеперечисленного физически невозможно. Вы будете ограничены скоростью света.
Вместо этого вам нужно учитывать ваши точные требования. Для некоторых данных достаточно ограниченной точности. Рассмотрим счетчик просмотров видео на YouTube. Большинству людей все равно, если счетчик просмотров временно отключен. Если просмотры, которые произошли 10 секунд назад на другом конце света, еще не включены, но включены просмотры, которые произошли 5 секунд назад ближе, это все еще достаточно точное. Если вы настолько расслаблены с целостностью счетчика просмотров, вы рискуете, что два разных человека могут подумать, что они были зрителем номер 100 этого конкретного видео. Но большинство людей сочло бы ущерб от этого незначительным.
В других случаях важнее целостность данных. Представьте, что два человека одновременно пытаются зарегистрироваться с одним и тем же именем пользователя. Сообщать обоим людям о том, что они получили имя пользователя, неприемлемо, поэтому в такой ситуации вы должны выбрать более медленный подход с лучшей целостностью. Допустимо сообщить обоим, что имя пользователя было занято, поэтому возможный подход - попытаться зарезервировать имя пользователя для каждой реплики и сообщать об успехе только в том случае, если вы преуспели на более чем 50% реплик. Не исключено, что при таком подходе пользователь будет ждать ответа полсекунды. Но пользователи не проходят через этот процесс достаточно часто, чтобы их беспокоила задержка.
В других случаях вам может потребоваться хорошая целостность и быстрое обновление, но только один человек может обновить этот конкретный фрагмент данных. В этом случае вы можете поместить авторитетную копию данных на сервер, который, по вашему мнению, близок к этому пользователю, и позволить другим серверам иметь кешированную версию, которая в основном актуальна.