это не так легко ответить.Существуют разные подходы и разные мнения, но я постараюсь охватить некоторые общие сценарии.но сначала некоторые основы.
большинство веб-приложений могут быть разделены на приложения и базу данных.Использование базы данных может быть разделено на транзакционную (oltp) и аналитическую (olap)
, в лучшем случае вы можете просто запустить несколько серверов приложений и распределить трафик между ними.все они имеют подключение к одному серверу базы данных и могут работать независимо друг от друга.однако это может быть затруднительно, если у вас есть другие общие данные, сеансы и т. д., вы можете сделать это, просто добавив несколько IP-адресов к вашему имени домена в dns.или вы используете методы балансировки нагрузки для пересылки клиентов на разные серверы.
Масштабирование приложений обычно очень просто.база данных намного сложнее.
первое, что нужно сделать, это обычно настроить один или несколько серверов репликации, которые имеют те же данные, что и основная база данных.они могут быть каскадными, но имеют один серьезный недостаток.их данные не всегда актуальны.как правило, не более нескольких секунд, но он может быть больше под нагрузкой.но для многих случаев использования это хорошо.большие сайты, которые просто отображают информацию, могут просто реплицировать свою базу данных на некоторые подчиненные серверы, настроить несколько серверов приложений (рекомендуется запускать один подчиненный и один сервер приложений на одном сервере и разрешать этому серверу доступа к этой подчиненной базе данных) и каждыйвсе в порядке.
каждый запрос olap может быть направлен на подчиненное устройство.Запросы olap - это те, которые ничего не изменяют и не нуждаются в данных о дате до 100%.
, поэтому все должно быть записано на тот же исходный сервер базы данных, с которого каждый второй сервер получает свою копию.например, каждый комментарий к статье.
если это узкое место становится слишком узким, вы можете пойти в двух направлениях.
- шардинг
- репликация мастер-мастер
означает, что вы решаете на сервере приложений, где хранить и где получать ваши данные.например, каждый комментарий, начинающийся с a, попадает на сервер a, b-> b и так далее.Это глупый пример, но в основном так оно и есть.в основном задействованы некоторые внутренние идентификаторы.если это возможно, хорошо бы защитить данные, чтобы их можно было полностью извлечь с этого сервера.в приведенном выше примере, если бы я хотел получить все комментарии к статье, мне нужно было бы попросить сервер eveyr az и объединить результаты.это неэффективно, но возможно, потому что эти серверы могут быть реплицированы.это называется отображением (вы можете проверить известный алгоритм Google Map-Reduce, который в основном так и делает).
репликация master-master означает, что вы записываете свои данные на разные главные серверы, и они синхронизируют друг друга, и нехранится отдельно, как если бы вы делали шардинг.это необходимо сделать, если ваше приложение не может самостоятельно решить, где хранить и извлекать данные.Вы просто храните на любом главном сервере, каждый сервер получает все, и все счастливы?нет ... потому что это связано с еще одной серьезной проблемой.конфликты!представьте, что два пользователя вводят комментарий.commentA сохраняется на сервере A, commentB хранится на сервере B.какой идентификатор мы должны использовать.какой из них на первом месте?Лучше всего разработать приложение, которое избегает таких случаев и имеет разные ключи и прочее.но обычно происходит разрешение конфликтов, расстановка приоритетов и прочее.У Oracle есть много возможностей на этом уровне, и MySQL остается позади.но тренды переходят в гораздо более сложные структуры данных, такие как облака в одночасье ...
ну, я не думаю, что я хорошо объяснил, но вы должны по крайней мере получить некоторые ключевые слова из текста, которые Ойу может исследовать дальше.