0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: клиент-серверная архитектура, разработка программного обеспечения, highload, архитектура по, высоконагруженные системы</p>
1
<p>Теги: клиент-серверная архитектура, разработка программного обеспечения, highload, архитектура по, высоконагруженные системы</p>
2
<p>Если сервис недоступен пользователям определённое время, это плохо, но не смертельно. Зато потерять данные клиента - попросту недопустимо. Именно поэтому важно скрупулёзно оценивать применяемые технологии хранения данных. Кроме того,<strong>важно обеспечить избыточность</strong>при построении клиент-серверной архитектуры. Об этом и поговорим.</p>
2
<p>Если сервис недоступен пользователям определённое время, это плохо, но не смертельно. Зато потерять данные клиента - попросту недопустимо. Именно поэтому важно скрупулёзно оценивать применяемые технологии хранения данных. Кроме того,<strong>важно обеспечить избыточность</strong>при построении клиент-серверной архитектуры. Об этом и поговорим.</p>
3
<p>Наиболее простым примером распределённой системы является<strong>классическая клиент-серверная модель</strong>. В нашем случае сервер является точкой синхронизации, которая даёт возможность осуществлять совместные и скоординированные действия сразу нескольким клиентам.</p>
3
<p>Наиболее простым примером распределённой системы является<strong>классическая клиент-серверная модель</strong>. В нашем случае сервер является точкой синхронизации, которая даёт возможность осуществлять совместные и скоординированные действия сразу нескольким клиентам.</p>
4
<p><em>Рассмотрим упрощённую схему клиент-серверного взаимодействия:</em></p>
4
<p><em>Рассмотрим упрощённую схему клиент-серверного взаимодействия:</em></p>
5
<p>Что тут ненадёжного? Все мы знаем, что сервер может упасть. А когда это произойдёт, все клиенты работать не смогут. Дабы избежать этой ситуации, было придумано подключение<strong>master-slave</strong>(теперь его называют<strong>leader-follower</strong>). Суть проста: существуют 2 сервера, клиенты взаимодействуют с главным сервером, а на второй сервер осуществляется репликация данных.</p>
5
<p>Что тут ненадёжного? Все мы знаем, что сервер может упасть. А когда это произойдёт, все клиенты работать не смогут. Дабы избежать этой ситуации, было придумано подключение<strong>master-slave</strong>(теперь его называют<strong>leader-follower</strong>). Суть проста: существуют 2 сервера, клиенты взаимодействуют с главным сервером, а на второй сервер осуществляется репликация данных.</p>
6
<p><em>Схема клиент-серверной архитектуры с репликацией данных на фолловера:</em></p>
6
<p><em>Схема клиент-серверной архитектуры с репликацией данных на фолловера:</em></p>
7
<p>Разумеется, вышеописанная система надёжнее, ведь если главный сервер упадёт, на фолловере есть копия всех данных, которую можно быстро поднять.</p>
7
<p>Разумеется, вышеописанная система надёжнее, ведь если главный сервер упадёт, на фолловере есть копия всех данных, которую можно быстро поднять.</p>
8
<p>Тут имеет значение и то, каким образом устроена репликация. Если репликация синхронная, транзакцию надо сохранять одновременно как на лидере, так и на фолловере, что бывает медленно. Если же репликация асинхронная, после аварийного переключения мы можем потерять часть данных.</p>
8
<p>Тут имеет значение и то, каким образом устроена репликация. Если репликация синхронная, транзакцию надо сохранять одновременно как на лидере, так и на фолловере, что бывает медленно. Если же репликация асинхронная, после аварийного переключения мы можем потерять часть данных.</p>
9
<p>Но давайте представим, что лидер упадет ночью во время спокойного и крепкого сна. Да, данные на фолловере есть, однако никто ведь фолловеру не сказал, что теперь он лидер, следовательно, клиенты к нему подключиться не смогут. Но мы можем наделить фолловер логикой, в результате чего он начнёт считать себя главным, когда будет потеряна связь с лидером. Но и здесь есть подводные камни:<strong>split brain</strong>- конфликт, при котором связь между лидером и фолловером нарушается, и оба начинают думать, что они являются главными.</p>
9
<p>Но давайте представим, что лидер упадет ночью во время спокойного и крепкого сна. Да, данные на фолловере есть, однако никто ведь фолловеру не сказал, что теперь он лидер, следовательно, клиенты к нему подключиться не смогут. Но мы можем наделить фолловер логикой, в результате чего он начнёт считать себя главным, когда будет потеряна связь с лидером. Но и здесь есть подводные камни:<strong>split brain</strong>- конфликт, при котором связь между лидером и фолловером нарушается, и оба начинают думать, что они являются главными.</p>
10
<p>Для решения вышеописанных проблем организуют<strong>auto failover</strong>- в этом случае добавляется третий, "свидетельский" сервер (witness). Такой сервер гарантирует<strong>наличие лишь одного лидера</strong>. Если же лидер отваливается, фолловер включится автоматически в кратчайшие сроки. Разумеется, в такой схеме клиенты должны знать адреса лидера и фолловера заранее. Также должна быть реализована логика автопереподключения между ними.</p>
10
<p>Для решения вышеописанных проблем организуют<strong>auto failover</strong>- в этом случае добавляется третий, "свидетельский" сервер (witness). Такой сервер гарантирует<strong>наличие лишь одного лидера</strong>. Если же лидер отваливается, фолловер включится автоматически в кратчайшие сроки. Разумеется, в такой схеме клиенты должны знать адреса лидера и фолловера заранее. Также должна быть реализована логика автопереподключения между ними.</p>
11
<p><em>На схеме ниже видно, что witness гарантирует наличие одного лидера. И если лидер отваливается, включение фолловера происходит автоматически:</em></p>
11
<p><em>На схеме ниже видно, что witness гарантирует наличие одного лидера. И если лидер отваливается, включение фолловера происходит автоматически:</em></p>
12
<p>Но есть минусы и у этой схемы. Допустим, вы обновляете на лидер-сервере операционную систему. А до этого вручную переключили на фолловера нагрузку - вдруг он падает, и сервис становится недоступен. Это катастрофа… Чтобы от неё застраховаться, надо добавить 3-й резервный сервер - то есть мы говорим об ещё одном фолловере. Вуаля - надёжность увеличивается, то есть<strong>2 сервера - это мало, лучше три</strong>: один на обслуживании, второй упал, но есть третий и катастрофы не происходит.</p>
12
<p>Но есть минусы и у этой схемы. Допустим, вы обновляете на лидер-сервере операционную систему. А до этого вручную переключили на фолловера нагрузку - вдруг он падает, и сервис становится недоступен. Это катастрофа… Чтобы от неё застраховаться, надо добавить 3-й резервный сервер - то есть мы говорим об ещё одном фолловере. Вуаля - надёжность увеличивается, то есть<strong>2 сервера - это мало, лучше три</strong>: один на обслуживании, второй упал, но есть третий и катастрофы не происходит.</p>
13
<p><em>Вот, как это может выглядеть:</em></p>
13
<p><em>Вот, как это может выглядеть:</em></p>
14
<h2>Делаем вывод</h2>
14
<h2>Делаем вывод</h2>
15
<p>Итак, избыточность должна быть. Мало того,<strong>она должна быть равной двум</strong>, так как избыточности, которая равняется единице, явно недостаточно для достижения требуемого уровня надёжности. Кстати, именно поэтому в дисковых массивах стали вместо RAID5 использовать схему RAID6, которая переживает падение сразу 2-х дисков.</p>
15
<p>Итак, избыточность должна быть. Мало того,<strong>она должна быть равной двум</strong>, так как избыточности, которая равняется единице, явно недостаточно для достижения требуемого уровня надёжности. Кстати, именно поэтому в дисковых массивах стали вместо RAID5 использовать схему RAID6, которая переживает падение сразу 2-х дисков.</p>
16
<p><em>Статья подготовлена по материалам блога компании<a>Pyrus</a>.</em></p>
16
<p><em>Статья подготовлена по материалам блога компании<a>Pyrus</a>.</em></p>
17
17