CAP-теорема: типы систем
2012-05-26 02:34 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
waqurПродолжим рассмотрение CAP-теоремы.
Правильные определения были даны в прошлый раз, а теперь рассмотрим CA-, CP- и AP-классы распределённых систем.
(1) Модель распределённой системы:
Простой онлайновый блокнот, рассчитанный на одного пользователя. Пользователь заходит на web-сайт и видит страницу с текстом, которую он может тут же подправить и нажать кнопку Submit.
Стрелочки показывают инициацию запросов, движение данных происходит двунаправлено.
Ограничения модели: web-сервер не может хранить данные (в реальных системах их объём превышает объём ОЗУ web-сервера; web-сервер может быть виртуальной машиной в облаке с эфемерным/readonly жёстким диском).
(2) Модель сбоев:
Мы не вдаёмся в физику сбоев (потеря сетевого пакета, админ об кабель передачи данных споткнулся, незапланированная перезагрузка, kernel panic, админ об силовой кабель споткнулся, останов сервера на замену БП/сетевой карты/жёсткого диска), это всё в рамках модели эквивалентные вещи.
Ограничения модели: web-сервер не сбоит (это неспортивно и неинтересно для исследований: понятно, что система сразу уйдёт в даун), серверы БД не сбоят одновременно (по аналогичным причинам). Особенность модели: как только в момент времени t1 сервер БД 1 восстанавливается, сервер БД 2 сразу же падает. В реальных системах он упадёт не в тот же самый момент времени, но время на репликацию не равно нулю, и репликация может не успеть пройти.
(3) Модель изменения данных
Пользователь в промежуток времени до t0 оставляет в блокноте запись Alpha.
В промежутке времени от t0 до t1 запись меняется на Beta.
В промежутке времени от t1 до t2 запись меняется на Gamma.
(4) AP-система
AP-система жертвует согласованностью данных, допуская запись только на один сервер БД.
В промежутке времени до t0 значение Alpha пишется на оба сервера БД.
В промежутке времени от t0 до t1 Alpha читается со 2-го сервера БД и в него же пишется значение Beta.
В промежутке времени от t1 до t2 Alpha читается с 1-го сервера БД и показывается пользователю (происходит нарушение принципа согласованности данных — loss of consistency), на 1-й сервер пишется значение Gamma.
В промежутке времени после t2 значение Gamma реплицируется на 2-й сервер БД, конфликт данных решается путём сравнения временны́х меток (обеспечивается согласованность в конечном итоге — eventual consistency).
(5) CP-система
CP-система жертвует доступностью. Она будет выдавать ошибку по операциям обновления блокнота во внешний мир, если хотя бы один из серверов БД не доступен на запись (в промежутке времени от t0 до t2).
(6) CA-система
CA-система жертвует устойчивостью к разбиениям. В момент времени t0 она навсегда отторгнет от себя 1-й сервер БД (ему достаточно для этого пропустить хотя-бы один запрос), в момент времени t1 она навсегда отторгнет от себя 2-й сервер БД (по той же причине), после чего перестанет существовать. Если бы моменты сбоя/восстановления серверов БД не наложились, CA-система успела бы сделать репликацию со 2-го сервера БД на 1-й и работать дальше. Согласованность данных и доступность на протяжении всего времени жизни CA-системы не была нарушена ни разу.
Есть популярное мнение, что CA-системы представляют собой чисто теоретический класс, что их невозможно или непрактично строить, но это заблуждение. Если на первом рисунке web-сервер заменить RAID-контроллером, а серверы БД — жёсткими дисками, и добавить требование "CA-система", то получится классическая RAID1-сборка. Таким образом, CA-системы широко применяются на более низком физическом уровне.
Хотя существуют модели сбоев (разбиений, partitions), как на втором рисунке, когда CA-система может внезапно умереть, вероятность наложения событий в момент t1 (неуспевания репликации) мала, а увеличением количества серверов БД (жёстких дисков) вероятность внезапной смерти CA-системы можно сделать произвольно малой.
Вероятность внезапной смерти систем других типов строго равна нулю только в рамках принятой в п.2 модели сбоев, но не в реальной жизни (где одновременно сбоить могут оба сервера БД).
Правильные определения были даны в прошлый раз, а теперь рассмотрим CA-, CP- и AP-классы распределённых систем.
(1) Модель распределённой системы:
Простой онлайновый блокнот, рассчитанный на одного пользователя. Пользователь заходит на web-сайт и видит страницу с текстом, которую он может тут же подправить и нажать кнопку Submit.
+---------------+ +------------------------+
| |----------->| Сервер базы данных 1 |
| | +------------------------+
------->| Web-сервер |
| | +------------------------+
| |----------->| Сервер базы данных 2 |
+---------------+ +------------------------+
Стрелочки показывают инициацию запросов, движение данных происходит двунаправлено.
Ограничения модели: web-сервер не может хранить данные (в реальных системах их объём превышает объём ОЗУ web-сервера; web-сервер может быть виртуальной машиной в облаке с эфемерным/readonly жёстким диском).
(2) Модель сбоев:
| | | |
Web-сервер | UP | UP | UP | UP
| | | |
Сервер базы данных 1 | UP | DOWN | UP | UP
| | | |
Сервер базы данных 2 | UP | UP | DOWN | UP
| | | |
------------------------|---------|---------|---------|---------> время
0 t0 t1 t2
Мы не вдаёмся в физику сбоев (потеря сетевого пакета, админ об кабель передачи данных споткнулся, незапланированная перезагрузка, kernel panic, админ об силовой кабель споткнулся, останов сервера на замену БП/сетевой карты/жёсткого диска), это всё в рамках модели эквивалентные вещи.
Ограничения модели: web-сервер не сбоит (это неспортивно и неинтересно для исследований: понятно, что система сразу уйдёт в даун), серверы БД не сбоят одновременно (по аналогичным причинам). Особенность модели: как только в момент времени t1 сервер БД 1 восстанавливается, сервер БД 2 сразу же падает. В реальных системах он упадёт не в тот же самый момент времени, но время на репликацию не равно нулю, и репликация может не успеть пройти.
(3) Модель изменения данных
Пользователь в промежуток времени до t0 оставляет в блокноте запись Alpha.
В промежутке времени от t0 до t1 запись меняется на Beta.
В промежутке времени от t1 до t2 запись меняется на Gamma.
(4) AP-система
AP-система жертвует согласованностью данных, допуская запись только на один сервер БД.
В промежутке времени до t0 значение Alpha пишется на оба сервера БД.
В промежутке времени от t0 до t1 Alpha читается со 2-го сервера БД и в него же пишется значение Beta.
В промежутке времени от t1 до t2 Alpha читается с 1-го сервера БД и показывается пользователю (происходит нарушение принципа согласованности данных — loss of consistency), на 1-й сервер пишется значение Gamma.
В промежутке времени после t2 значение Gamma реплицируется на 2-й сервер БД, конфликт данных решается путём сравнения временны́х меток (обеспечивается согласованность в конечном итоге — eventual consistency).
(5) CP-система
CP-система жертвует доступностью. Она будет выдавать ошибку по операциям обновления блокнота во внешний мир, если хотя бы один из серверов БД не доступен на запись (в промежутке времени от t0 до t2).
(6) CA-система
CA-система жертвует устойчивостью к разбиениям. В момент времени t0 она навсегда отторгнет от себя 1-й сервер БД (ему достаточно для этого пропустить хотя-бы один запрос), в момент времени t1 она навсегда отторгнет от себя 2-й сервер БД (по той же причине), после чего перестанет существовать. Если бы моменты сбоя/восстановления серверов БД не наложились, CA-система успела бы сделать репликацию со 2-го сервера БД на 1-й и работать дальше. Согласованность данных и доступность на протяжении всего времени жизни CA-системы не была нарушена ни разу.
Есть популярное мнение, что CA-системы представляют собой чисто теоретический класс, что их невозможно или непрактично строить, но это заблуждение. Если на первом рисунке web-сервер заменить RAID-контроллером, а серверы БД — жёсткими дисками, и добавить требование "CA-система", то получится классическая RAID1-сборка. Таким образом, CA-системы широко применяются на более низком физическом уровне.
Хотя существуют модели сбоев (разбиений, partitions), как на втором рисунке, когда CA-система может внезапно умереть, вероятность наложения событий в момент t1 (неуспевания репликации) мала, а увеличением количества серверов БД (жёстких дисков) вероятность внезапной смерти CA-системы можно сделать произвольно малой.
Вероятность внезапной смерти систем других типов строго равна нулю только в рамках принятой в п.2 модели сбоев, но не в реальной жизни (где одновременно сбоить могут оба сервера БД).
