1. Ты запутался из-за того что ты смешал CAP с измеряемыми характеристиками (пропускная способность, доступность, итд)
Доступность
Здесь уже появляется неоднозначность.
Это примерно такая же неоднозначность, как в слове "замок".
Воспринимай это как разные слова из разных контекстов.
HA - это про малое количество сбоев, которые приводят к нулевой доступности.
A из CAP - это про сохранении доступности при выпадении узлов из кластера (если забыть про A, то можно сделать строго консистентную систему из нескольких узлов даже в случае потери связи между узлами - просто вся система будет отключаться)
По идее, здесь мы поддерживаем согласованность, жертвуя.. доступностью? Но ведь нет же! Мы все равно получим ответ.
Да, мы жертвуем доступностью, так как ответ мы не получим, если какой-то узел выпал из кластера => операция записи просто не будет выполнена.
Хотя в реальной жизни мы сразу получим ответ вида "запрос не может быть обработан. Почините кластер"
Пример такой системы - etcd, в которой ты заранее указываешь размер кластера и если кластер не может придти в состояние кворума (доступно N/2+1 узел, где N-количество узлов), то весь кластер переходит в аварийный режим без возможности чтения или записи.
Таким образом гарантируется консистентность даже на отвалившихся от кластера узлах.
Определение доступности из CAP вообще ничего не говорит про задержку (latency).
Потому что CAP не про это.
Резюмируя вопросы:
1. Просто читаем определение:
High availability (HA) is a system's capability to provide services to end users without going down for a specified period of time. High availability minimizes or (ideally) eliminates service downtime regardless of what incident the company runs into (a power outage, hardware failure, unresponsive apps, lost connection with the cloud provider, etc.).
Тоесть да, система вполне может уходить полностью в оффлайн на какое-то время, если это было заранее оговорено.
В пределах разумного, конечно. Если тебе дают гарантированную доступность 1с в год - это какой-то сюр.
Какая правильная и полная формулировка Availability из CAP?
По хорошему тут следует найти первоисточник, но мне лень. Вариант из Википедии достаточно точный, на мой взгляд:
доступность (англ. availability) — любой запрос к распределённой системе завершается откликом, однако без гарантии, что ответы всех узлов системы совпадают;
Любой запрос - любой запрос чтения или записи к любому из работающих узлов системы.
Завершается откликом - значит тебе дают какой-то ответ, который не является ошибкой.
Пример доступной, но не консистентной системы управления кадрами:
Запрос: "Какая зарплата у Иванова?"
Узел 1: 1000 долларов
Узел 2: две тысячи долларов
Узел 3: Иванов у нас не работает
Пример такой же системы, но в которой действует принцип консистентность:
Запрос: Иванов уволен?
Узел 1,2,3: Ошибка: кластер в аварийном режиме.
Либо:
Узел 1,2,3: Иванов не уволен.
Либо:
Узел 1,2: Иванов не уволен
Узел 3: Ошибка: отсутствует кворум.
Запрос: Уволить Иванова.
Узел 1,2,3: Ошибка: кластер в аварийном режиме. Доступно только чтение.
Либо:
Как в третьем варианте, если возможна запись при наличии кворума.
Единственное, как я смог притянуть за уши с существующей формулировкой.
CAP не про это.
Отказоустойчивая система не допускает потери функциональности вообще?
Пуленепробиваемое стекло не допускает пробития пулями вообще?)
В случае катастрофического отказа - возможно всё.
Как, в двух словах хотя бы, проводится измерение производительности и пропускной способности сервиса?
Два слова: нагрузочное тестирование.
Теперь все дополнения тут:
Конфиденциальность. Пользователь уверен, что данные из системы не утекут.
Я не понял, почему конфиденциальность относится к надёжности, если это вообще не технический, а организационный момент.
Управляемость
Это свойство влияет напрямую на доступность. Если система сложная, плохо настроен мониторинг (логи, трейсы, алерты), нет или просто неудобные инструменты для управления инфраструктурой, все это будет отнимать время на ремонт в случае отказа.
Вообще это в англоязычных источниках называется observability/наблюдаемость.
Ну да ладно. Просто опять смешали несколько вещей в одну.
Можно провести небольшое тестирование, собрать метрику по этому эндпоинту, взять среднее арифметическое и вот тебе производительность для конкретно этого эндпоинта.
Я бы поспорил насчёт среднего арифметического )
Здесь вопрос в том, как мерить общую производительность сервиса?
Никак, ведь нет никакой "общей производительности".
Нагрузочное тестирование существует, но его проводят в профиле какой-то конкретной нагрузки/сценария.
Например в банковской системе могут проводить нагрузочную систему по нескольким сценариям:
1. "Чёрная пятница" - резко увеличивается количество карточных операций.
2. "Реклама у крупного блогера" - резко увеличилось количество запросов на выпуск новой карты. Нужно проверить, как вообще выдержит сервис, отвечающий за эмбоссинг.
3. "Экономике в стране «очень плохо»" - смотрим как выдержит клиринг при большом количестве межбанковских переводов.
Все эти профили нагрузки будут задевать разные части системы и мы сможем сказать, как система будет держаться в каждом из сценариев.
Пропускную способность можно увеличить, распараллелив обработку (горизонтальное масштабирование или процессы и потоки в рамках одного сервиса).
Или добавив пакетную обработку.
На задержка напрямую зависит от пропускной способности (производительности) и канала связи. Чем ближе сервер к пользователю, тем меньше задержка.
А вот и нет.
У нас вполне может быть узкий канал с низкой задержкой или же широкий канал с большой задержкой.
А ещё задержка - это время обработки запроса твоей собственной системой.
Например твой сервис вполне может иметь большой latency, но и большой throughput и наоборот.
