Здравствуйте, gandjustas, Вы писали:
G>То есть односерверная машина у нас априори available?
Да, но CAP не применяют для анализа односерверных систем. Ну ты можешь попробовать, конечно, но это странно.
G>То есть пофиг что внутри происходит, главное ОК вернуть?
Формально — да.
G>То есть пофиг сколько ждать перед тем как ОК вернуть?
Конечно, тем не менее это не опровергает корректность CAP (это было показано в статье Нэнси Линч и еще какого-то чувака, которую ты в своей статье для хабра цитируешь).
G>И какой смысл в этом определении?
CAP определяет availability как liveness, формально, определение не очень строгое и под него действительно можно подвести все что ты перечислил, но понимается под этим именно liveness. Consistency из CAP определяется как safety (agreement & validity).
На практике это означает, что CP система может обрабатывать запрос на запись или чтение произвольное время, так как на каждый запросу будет запущен раунд консенсуса (raft, zab, paxos), положительный результат при этом не гарантирован, т.е. на свой запрос ты можешь получить ответ, означающий что кворум не получен и запись(или чтение) не прошла. AP система не будет гонять консенсус на каждый запрос чтения/записи, она может, например, в ответ на запрос на запись, записать данные в локальное хранилище, вернуть положительный ответ, а потом, асинхронно (например через gossip протокол) распространить твое изменение по кластеру (или его части).
G>Но это не означает, что потом можно будет прочитать. То есть в грубом приближении AP система это /dev/null.
Можно представить AP систему, работающую как /dev/null, но это не значит, что нельзя создать AP систему, имеющую полезные свойства.
G>Availability это не свойство железа, а свойство системы (железа, каналов связи, логики серверов, логики клиентов). Определяется как процент времени когда система способна отвечать на запросы за разумное (заранее определённое) время и сохранять работоспособность. Для этого нужно в первую очередь поддерживать аптайм железа, чтобы серваки не падали и поддерживать логику работы.
G>При этом вовсе не требуется, чтобы на каждый запрос возвращался ОК, вполне возможно повторение запроса на клиенте, если сервер недоступен или отвечает "обратитесь позже". Так устроены многие протоколы от REST до TCP\IP.
Еще раз, мы обсуждаем NoSQL, можно себе представить (легко) систему, которая полностью работоспособна, никаких ошибок нет и в помине, при этом система может быть недоступной в терминах CAP и запрос на запись у тебя будет отваливаться по таймауту иногда. При этом даунтайма нет, каждый хост пингуется, каждый endpoint принимает входящие подключения и отвечает на запросы.
Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success.
G>Availability в CAP — бесполезное на практике свойство и его потеря по факту может не значить вообще ничего.
G>Partition tolerance кстати тоже. В большинстве случаев partition tolerant системы не могут сохранить согласованность данных даже через любое длительное время.
Wat?
G>Писал об этом на хабре https://habrahabr.ru/post/231703/
Статья очень спорная.
Вот это понравилось:
Разделение сети — крайне редкое явление в наше время. Гилберт и Линч прямо заявляют, что системы, работающие в локальной сети, можно считать не подверженными разделению.
Статья написана академиками (а не практикующими инженерами) в 2002-м году. В 2014-м году никто в академическом сообществе так больше никто не считал. Рекомендую ознакомиться со статьей
Network Is Reliable. Пара цитат:
Stop-the-world garbage collection and blocking for disk I/O can cause runtime latencies on the order of seconds to minutes. As Searchbox IO and several other production users (https://github.com/elasticsearch/elasticsearch/issues/2488) have found, GC (garbage collection) pressure in an ElasticSearch cluster can cause secondary nodes to declare a primary dead and to attempt a new election. Because of nonmajority quorum configuration, ElasticSearch elected two different primaries, leading to inconsistency and downtime. Surprisingly, even with majority quorums, due to protocol design, ElasticSearch does not currently prevent simultaneous master election; GC pauses and high IO_WAIT times due to I/O can cause split-brain behavior, write loss, and index corruption.
On July 18, 2013, Twilio's billing system, which stores account credits in Redis, failed.19 A network partition isolated the Redis primary from all secondaries. Because Twilio did not promote a new secondary, writes to the primary remained consistent. When the primary became visible to the secondaries again, however, all secondaries simultaneously initiated a full resynchronization with the primary, overloading it and causing Redis-dependent services to fail.
The ops team restarted the Redis primary to address the high load. Upon restart, however, the Redis primary reloaded an incorrect configuration file, which caused it to enter read-only mode. With all account balances at zero, and in read-only mode, every Twilio API call caused the billing system to recharge customer credit cards automatically, resulting in 1.1 percent of customers being overbilled over a period of 40 minutes. For example, Appointment Reminder reported that every SMS message and phone call it issued resulted in a $500 charge to its credit card, which stopped accepting charges after $3,500.
