Я правильно уловил особенности распределенных систем?

Чтобы ответить на ваш первый вопрос о распределенных системах, мне нужно увидеть текст или контекст вашего понимания, чтобы подтвердить или исправить его. Поэтому, пожалуйста, предоставьте немного больше информации о том, какие именно особенности распределенных систем вы пытаетесь уловить.

Что касается улучшения читаемости текста, особенно когда он содержит много информации, вот несколько общих советов, которые могут помочь:

1. **Структурируйте текст**: Используйте заголовки и подзаголовки для разделения различных тем или идей. Это помогает читателям находить интересующие их разделы и лучше навигироваться по документу.

2. **Абзацы и четкость**: Убедитесь, что каждый абзац имеет четкую основную идею. Начните абзац с тематического предложения, а затем развивайте и поддерживайте эту идею в последующих предложениях.

3. **Использование списков**: Где это возможно и уместно, используйте маркированные или нумерованные списки для перечисления элементов, этапов, функций и т.д. Это делает информацию более организованной и легко усваиваемой.

4. **Избегайте жаргона и сложной терминологии**: Если вы пишете для широкой аудитории, избегайте использования специфических терминов, или, если их использование неизбежно, обязательно дайте четкое определение при первом упоминании.

5. **Используйте подведение итогов и акценты**: Короткие итоги или выделение ключевых моментов помогают читателям уловить основные моменты текста.

6. **Визуализация**: Картинки, диаграммы, таблицы и графики могут значительно повысить читаемость, особенно если они помогают объяснить сложные идеи или данных много.

7. **Короткие предложения**: Длинные и сложные предложения могут затруднить понимание. Стремитесь к простым и ясным предложениям.

8. **Переходы между идеями**: Используйте переходные слова и фразы для плавного перехода от одной идеи к другой.

9. **Редактирование и корректура**: Перечитайте текст несколько раз, чтобы исправить опечатки, грамматические ошибки и нечеткие места.

10. **Обратная связь**: Получите отзывы от коллег или друзей. Иногда взгляд со стороны может выявить проблемы с читаемостью, которые не были очевидны для вас.

Если вы предоставите конкретный пример текста, я могу дать более точные рекомендации по его улучшению.

1. Ты запутался из-за того что ты смешал CAP с измеряемыми характеристиками (пропускная способность, доступность, итд) 
 


Доступность

Здесь уже появляется неоднозначность.

 
 Это примерно такая же неоднозначность, как в слове "замок". 
 Воспринимай это как разные слова из разных контекстов. 
 HA - это про малое количество сбоев, которые приводят к нулевой доступности. 
 A из CAP - это про сохранении доступности при выпадении узлов из кластера (если забыть про A, то можно сделать строго консистентную систему из нескольких узлов даже в случае потери связи между узлами - просто вся система будет отключаться) 
 
 


По идее, здесь мы поддерживаем согласованность, жертвуя.. доступностью? Но ведь нет же! Мы все равно получим ответ.

 
 Да, мы жертвуем доступностью, так как ответ мы не получим, если какой-то узел выпал из кластера => операция записи просто не будет выполнена. 
 Хотя в реальной жизни мы сразу получим ответ вида "запрос не может быть обработан. Почините кластер" 
 Пример такой системы - etcd, в которой ты заранее указываешь размер кластера и если кластер не может придти в состояние кворума (доступно N/2+1 узел, где N-количество узлов), то весь кластер переходит в аварийный режим без возможности чтения или записи. 
 Таким образом гарантируется консистентность даже на отвалившихся от кластера узлах.

Допускает ли High Availability полный отказ системы или только отказ каких-то компонент с точки зрения функциональности, а не экземпляров?
 
 Доступность исчисляется относительно внешнего клиента - может или нет получить доступ к сервису. Здесь без разницы, что для этого используется кластеризация, бэкапы, стендбаи и т.д. 
 Главное - это то, как систему видит пользователь. Собственно, все SLA на так и рассчитываются. 
 
Какая правильная и полная формулировка Availability из CAP?
 
 На сколько я помню, эту теорему в свое время критиковали и продолжают за неясность определения. Но если в кратце, доступность здесь означает, что ты получишь ответ, даже если связь с другими узлами кластера пропадет. Если в кратце, доступность = можешь получить ответ хоть когда-нибудь. 
 Пример: 
 1. Есть кластер из 2 Postgres мастеров. Связь между ними пропадает и запросы они принимать не могут. Это НЕ Availability, т.к. нам важна консистентность 
 2. Если кластер из 2 Postgres узлов - мастер и слейв. Даже если связь между ними пропадет, то запросы они принимать смогут, но данные могут быть в не согласованном состоянии (мастер принял несколько UPDATE/INSERT/DELETE, а слейв о них не знает). Это Availability, но Consistency мы потеряли 
 3. Если кластер из 2 Mongo узлов. Там используется свой протокол, который позволяет системе быть доступной, даже если связь между мастерами потеряется. Это Availability, но согласованность может потеряться 
 P.S. в последнем используются специальные распределенные структуры данных (чтобы каждый узел мог модифицировать свою версию, а потом смержить с другими узлами) 
 
Отказоустойчивая система не допускает потери функциональности вообще?
 
 Отказоустойчивость - это не дискретная (0 или 1), а непрерывная характеристика. Здесь лучше думать в ключе SLA (99, 99.9, 99.999 т.д.), т.к. никакая система не может быть полностью отказоустойчивой. Но в целом да - отказоустойчивость значит, что функциональность должна работать и клиент может ее использовать. 
 
Как, в двух словах хотя бы, проводится измерение производительности и пропускной способности сервиса?
 
 1+ слово - тестирование (нагрузочное, объемное и т.д.) 
 Здесь нельзя вычислить формулами, сколько и что сможем обслужить. Только экспериментом числа получать. 
 
 UPD: если хочешь призму, чтобы смотреть на распределенные системы, то вот тут скачай "Распределенные системы" от Таненбаума - https://www.distributed-systems.net/index.php/book...