Comments 9
У CAP-теоремы есть проблемы ещё и с А, ибо узел, который отвечает через год, после восстановления связности, всё ещё считается доступным, а значит удовлетворяет всем трём CAP-критериям.
рассмотрим интерфейс взаимодействия с мех часами, часы остановились, через год заводим они стали доступны на текущий момент времени и их придётся пользователю донастроить на текущее время, сами часы доступны пока есть запас хода и сам механизм консистентен внутри себя тоесть согласован на показ и установку времени )
значит после отклика через год надо сменить состояние на актуальное что-то такое
Надо добавить что все они сильно влияют на производительность. Чем больше хочется консистентности во всей системе тем больше тормозов
Многие девелоперы считают, что если их система не удовлетворяет ACID, то она по умолчанию BASE. Это роковое заблуждение. BASE -- достаточно сильная гарантия. Реально практически все системы, которые мне встречались, имплементиоруют "страусиный" принцип и zero consistency. И это банковский и телекоммуникационный сектор.
Расскажите поподробнее
Тут особо не о чем рассказывать. Base -- все ещё достаточно сильная гарантия, которая обеспечивает частичную консистентность в некоем будущем. Большинство систем вообще никак не гарантируют консистентность данных, ни в настоящем, ни в будущем, и обеспечивают ее только в случае happy path при отсутствии race condition. Благодаря крайне низкой вероятности подобных сбоев, а также налаженной пользовательской поддержке, данные системы имеют быть место.
ух спасибо, отличный текст!
чего немного не хватает статье, так это списка литератруры, который рекомендовал бы автор, чтобы увидеть все эти принципы в действии и в коде.
ACID, BASE, CAP: Фундамент архитектуры распределенных систем