Здравствуйте, chaotic-kotik, Вы писали:
CK>CAP определяет availability как liveness, формально, определение не очень строгое и под него действительно можно подвести все что ты перечислил, но понимается под этим именно liveness. Consistency из CAP определяется как safety (agreement & validity).
То есть ты согласен, что это совсем не тот availability о котом говорят в контексте HA?
И разу следующий вопрос — в чем ценность свойства liveness? Какие гарантии или преимущества оно дает? На практике никаких.
G>>То есть в грубом приближении AP система это /dev/null.
CK>Можно представить AP систему, работающую как /dev/null, но это не значит, что нельзя создать AP систему, имеющую полезные свойства.
Можно, нужны будут дополнительные гарантии из области Consistency, которые приведут к противоречию с теоремой.
CK>Еще раз, мы обсуждаем NoSQL, можно себе представить (легко) систему, которая полностью работоспособна, никаких ошибок нет и в помине, при этом система может быть недоступной в терминах CAP и запрос на запись у тебя будет отваливаться по таймауту иногда. При этом даунтайма нет, каждый хост пингуется, каждый endpoint принимает входящие подключения и отвечает на запросы.
И? С точки зрения клиента клиента все равно недоступна система или не может выполнить запрос. С точки зрения cap это разные явления
CK>Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success.
Но тогда появляется гораздо интереснее сценарий.
Ты делаешь checkout и проводишь оплату "внутренней валютой". Транзакция с уменьшением баланса улетает на два сервера, один из которых затупил, а второй подумал, что он уже мастер. После синхронизации у тебя дважды сняли деньги.
Ты же сам привел аналогичный пример ниже.
Для любых данных, которые нельзя терять или искажать такой подход не работает.
G>>Availability в CAP — бесполезное на практике свойство и его потеря по факту может не значить вообще ничего.
G>>Partition tolerance кстати тоже. В большинстве случаев partition tolerant системы не могут сохранить согласованность данных даже через любое длительное время.
CK>Wat?
Твои примеры ниже прекрасно иллюстрируют что я говорю.
CK>Статья написана академиками (а не практикующими инженерами) в 2002-м году. В 2014-м году никто в академическом сообществе так больше никто не считал. Рекомендую ознакомиться со статьей Network Is Reliable. Пара цитат:
По-моему из этого всего можно сделать вывод, что ни availability, ни partition tolerance в реальном мире не помогают строить надежные системы.
Единственный живой вариант — делать CA системы, то есть кворумы с node majority.
Только при наличии существенных ограничений на функциональность системы можно где-то ослаблять consistency.
