Очень часто можно услышать примерно такую логику:
«У нас база данных не справляется с записью, давайте сделаем несколько мастеров. Теперь запись можно будет распределить между ними, значит пропускная способность системы вырастет».
На первый взгляд звучит логично. Если серверов стало больше, почему бы просто не отправлять записи в разные узлы? Но проблема в том, что репликация устроена не так.
Представим, что у нас есть два мастера. Пользователь записал данные в первый мастер. Чтобы данные оставались одинаковыми на обоих серверах, эту запись нужно синхронизировать со вторым мастером. Если другой пользователь записал данные во второй мастер, эти изменения нужно передать обратно в первый. В итоге каждый мастер вынужден обрабатывать не только свои записи, но и записи, пришедшие в остальные мастера.
Из-за этого репликация практически не позволяет масштабировать пропускную способность записи. Да, запросы могут приходить в разные серверы, но сами данные все равно приходится распространять между ними. Если каждый узел должен применить все изменения системы, то объем работы никуда не исчезает.
Что тогда дает master-master репликация? В первую очередь отказоустойчивость. Если один узел станет недоступен, система сможет продолжить работу через другой. Кроме того, она может снизить задержки. Например, пользователи из разных регионов могут писать в ближайший датацентр, а синхронизация между регионами будет происходить асинхронно.
Но если цель заключается именно в том, чтобы увеличить количество записей, которые способна обработать система, то обычно смотрят в сторону шардирования. При шардировании разные данные физически размещаются на разных серверах, поэтому каждая запись обрабатывается только своим шардом, а не всеми узлами сразу.
Поэтому когда слышу фразу «давайте добавим еще несколько мастеров и масштабируем запись», обычно задаю простой вопрос: сколько серверов в итоге должны обработать одну запись пользователя? Если ответ «все», то масштабирования записи здесь, скорее всего, не произошло.
Кто я | Навигация | Спасибо