CAP и PACELC
Для начала решил написать почему я об этом пишу. Это же не c# а канал вроде про это. Начиная с мидл плюс/сеньор шарп это конечно хорошо, но хотят увидеть мини архитектора. Человека который может посмтроить систему, с помощью инструмента, инструмент -c#. Соответственно спрашивают именно по c# условно 1/3 или максимум 1/2 часть собеседования, а потом как вообще строить системы. Собственно CAP. Consistency Partition tolerance Aviliability - теорема о том, что если взять какую-то базу данных, то она поддерживает только 2 пункта. Consistency - согласованность. Данные согласованы друг с другом, если с одного счета сняли на другом появилось. Это как раз про хорошую транзакционность. Тут наши классические postgresql, ms-sql. Aviliability - доступность. Каждый живой узел всегда ответит на запрос. Partition tolerance - устойчивость к распределению. Даже если между узлами нет связи, они продолжают работать независимо друг от друга.
Предположим у нас есть распределенная база данных (на нескольких узлах), например cassandra. Если мы разделим ее кластер на 2 отдельных - каждый будет работать отдельно сам по себе. При этом естественно согласованности(consistency) между кластерами не будет. Она будет в конечном итоге (eventual consistency) когда связь восстановится и она засинхронится. cassandra пример ребра AP. MongoDB в режиме write concern majority - если не может получить подтверждение от большинства реплик, операция записи не будет считаться успешной. Согласованная но не высокодоступная CP ребро. Классические реляционки вроде Postgresql AP ребро Все клиенты подключаются к одному серверу. Нет разделения сети, потому что система не распределённая.
PACELC - дополнение к CAP теореме. Это о том, что хорошо конечно рассматривать базы с точки зрения если начнется сбой системы между узлами. Если происходит разделение сети (P), то система выбирает между Доступностью (A) (например кассандра) и Согласованностью (C)(например монго и не отвечающие узлы); А что будет если не начнется ? P — Partition (разделение сети) A — Availability (доступность) C — Consistency (согласованность) E — Else (в остальных случаях, когда нет разделения) L — Latency (задержка) C — Consistency (согласованность)
Else (если разделения нет), система выбирает между Задержкой (L) и Согласованностью (C). Примеры кассандра, Elasticsearch PA/EL При разделении сети: выбирают Доступность (A), жертвуя Согласованностью (C). Без разделения: минимизируют Задержку (L), жертвуя строгой Согласованностью (C). (т е даже без разделения согласованность в конечном итоге) MongoDB (write concern majority),Redis master-slave репликация PC/EC При разделении сети: жертвует Доступностью ради Согласованности. Без разделения: поддерживает строгую Согласованность.(ждет ответа от реплик при записи)
Кстати если присмотреться то заметно что базы или выбираеют всегда A/L (доступность при разделении, минимизацию задержки когда все окей) или PC/EC согласованность при разделении и согласованность (ждем как запишется везде) когда все хорошо
