Оглавление
Принципы, паттерны, практики и подходы разработки ПО
- SOLID.
- Паттерны. Какие знаете? Каких видов бывают? Расскажите парочку (желательно разных видов)? Какие применяли на практике или встречались где-то? Чем декоратор отличается от прокси, а абстрактная фабрика от обычной?
- Что такое coupling и cohesion? Что из них (или оба) должно быть сильным (высоким) и/или слабым (низким)?
- Что такое куб масштабирования?
- Расскажите о CAP-теореме. Как MongoDB (например) удовлетворяет CAP-теореме?
- Чем композиция отличается от агрегации?
- Какие бывают тестовые объекты (заглушки)? Чем стаб отличается от мока?
- Дайте определение полиморфизму
- Что такое REST? Какое API является RESTful? Чем REST отличается от SOAP?
SOLID.
Обычно просто просят расшифровать, что каждая буква означает с минимальным пояснением. Никто из моих интервьюеров не стал размусоливать или обсуждать. Один раз спросили, зачем оно вообще надо. Но, я думаю, чем больше сеньорности в вакансии, тем глубже и интереснее дискуссия может возникнуть.
- S — Принцип единственной ответственности (The Single Responsibility Principle). Каждый класс должен иметь одну и только одну причину для изменений.
- O — Принцип открытости/закрытости (The Open Closed Principle). Сущности должны быть открыты для расширения, но закрыты для модификации.
- L — Принцип подстановки Барбары Лисков (The Liskov Substitution Principle). Объекты должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы. Наследующий класс должен дополнять, а не изменять базовый.
- I — Принцип разделения интерфейса (The Interface Segregation Principle). Много специальных интерфейсов лучше, чем один универсальный.
- D — Принцип инверсии зависимостей (The Dependency Inversion Principle). Зависеть нужно от абстракций, а не от реализаций.
Первоисточником, сформулировавшим данные принципы стал дядюшка «Свет наш чистый код» Боб Мартин, а акроним придумал один из его читателей. Хотите погрузиться глубже? Тогда читайте часть 3 его книги «Чистая архитектура». Книжка годная, читается легко, не пожалеете. Однако пропускайте всё через свой опыт и оценивайте критически, мало ли что 🙂
Сама по себе тема богатая и холиворная, ибо многие начинают трактовать эти принципы по-своему. На этой почве может случиться недопонимание с собеседующим, будьте аккуратны и конструктивны. Достаточно поискать статьи на Хабре по SOLID или каким-нибудь принципам в отдельности и заглянуть в комментарии. Кому-то SOLID вообще не по душе.
Также, могу посоветовать, самостоятельно разобрать каждый принцип на практическом примере, ибо за это тоже могут спросить. Или заглянуть на Baeldung.
к содержанию
Паттерны. Какие знаете? Каких видов бывают? Расскажите парочку (желательно разных видов)? Какие применяли на практике или встречались где-то? Чем декоратор отличается от прокси, а абстрактная фабрика от обычной?
Обычно советуют и в вакансиях пишут про книжку GoF. Но, на мой взгляд, сейчас есть вариант даже лучше — refactoring.guru. Там и сравнение, и на родной мове (русский, украинский, английский, китайский), и примеры на вашем любимом ЯП, прекрасные иллюстрации и диаграммы. Там также можно купить книжку по паттернам. Автору большой-большой респект.
к содержанию
Что такое coupling и cohesion? Что из них (или оба) должно быть сильным (высоким) и/или слабым (низким)?
Coupling (Зацепление) — степень зависимости между программными компонентами. Должна быть низкой.
Cohesion (Связность) — степень сфокусированности методов класса. Должна быть высокой.
Подробнее почитать и посмотреть картинки можно тут на английском или тут на русском.
Тема периодически затрагивается на Хабре в контексте построения хорошей архитектуры и написания качественного кода. Как и всегда, особую ценность составляют комментарии:
- Создание архитектуры программы или как проектировать табуретку
- Принцип единственной ответственности: глубокое погружение. Есть раздел, где тема разобрана с примерами кода.
- Утрата слабой связанности
Также coupling и cohesion часто упоминаются или ведут к обсуждению GRASP. Об этом можно почитать на Хабре: раз и два.
к содержанию
Что такое куб масштабирования?
Куб масштабирования (scale cube, из книги The Art of Scalability) является наглядным изображением трёх ортогональных способов увеличения производительности приложения: sharding, mirrorring и microservices.
- Sharding (data partioning) — разбиение и размещение однотипных данных по разным узлам.
- Mirroring (horizontal duplication) — дублирование или клонирование данных для уменьшения времени отклика.
- Microservices — архитекутрный подход, при котором функциональность системы разбивается на отдельные сервисы по бизнес-задачам.
Наглядно:
Почитать подробнее:
- Упоминание в статье на Хабре.
- В статье на microservices.io.
- Даже в wiki есть с pros и cons.
- SCALING APPLICATIONS : THE SCALE CUBE.
- И вот ещё.
- А тут с картинками.
- Также куб упоминается в книгах Microservice Patterns and Best Practices и Microservices Patterns (есть на русском).
к содержанию
Расскажите о CAP-теореме. Как MongoDB (например) удовлетворяет CAP-теореме?
Теорема CAP — эвристическая теорема, утверждающая, что любая распределённая система может удовлетворять не более двум из трёх свойств:
- Consistency (согласованность) — во всех вычислительных узлах в один момент времени данные не противоречат друг другу — каждое чтение вернёт самую последнюю запись. Подразумевает под собой линеаризуемость — если произошла какая-либо операция, то её результат доступен сразу после того, как был получен ответ о её выполнении.
- Availability (доступность) — любой запрос получает успешный ответ без гарантии, что ответы со всех узлов системы совпадают.
- Partition tolerance (устойчивость к разделению) — система продолжает функционировать, несмотря на потерю (или задержку) произвольного числа сообщений между узлами из-за сетевых проблем (асинхронная сеть).
MongoDB, по мнению большинства (например), это — CP, но вот есть статья… Держим в уме, что теорема эвристическая и носит упрощательный характер. Также вызывает много споров.
Про большинство БД можно найти ответы в статьях по дополнительным ссылкам ниже.
Подробности:
- Есть несколько статей на Хабре: раз, два, три, четыре, пять
- Visual Guide to NoSQL Systems с красивой иллюстрацией треугольника CAP и БД на его сторонах
- The CAP FAQ
- Статья на bigdataschool
- Споры вокруг MongoDB на stackoverflow
- CAP Theorem на портале IBM
- CAP Theorem and Distributed Database Management Systems с картинками
- What is the CAP Theorem? на богомерзком medium
к содержанию
Чем композиция отличается от агрегации?
Композиция (composition) — отношение «является частью» (HAS-A Relationship), при котором целое явно контролирует время жизни своей составной части.
Агрегация (aggregation) — отношение «является частью» (HAS-A Relationship), при котором целое хоть и содержит свою составную часть, время их жизни не связано.
Подробнее:
- Наследование vs Композиция vs Агрегация
- Наследование, композиция, агрегация
- Агрегация и композиция
к содержанию
Какие бывают тестовые объекты (заглушки)? Чем стаб отличается от мока?
Тестовый объект (Test Double) — объекты, которые необходимы в тестах для подмены внешних зависимостей тестируемого кода
Типы тестовых объектов:
- Dummy — объекты, которые передаются в методы, но не используются. Например: заполнение списка параметров, часто это просто null
- Fake — заглушка, являющаяся рабочей имплементацией, но с урезанной функциональностью и неприменима в production-окружении. Например: in-memory БД (fake database)
- Stub — заглушка с жестко заданными ответами на вызовы со стороны тестируемого объекта (system under test — SUT) во время теста
- Spy — это разновидность Stub, которая записывает информацию о произошедшем с ней, какие вызовы её методов были выполнены и сколько раз, как изменилось состояние и т.п.
- Mock — заглушка с ожиданиями определённого набора вызовов, которые будут на ней выполнены в ходе теста
Из данного набора заглушек только Mock используется для верификации поведения, остальные — для верификации состояния тестируемого объекта .
Подробнее:
- В статье на Хабре
- Mock vs Stub
- Mocks Aren’t Stubs от Мартина Фаулера
- Test Double
- Test Stub
- Test Spy
- Mock Object
- Fake Object
- Interaction Based Testing в Spock Framework
- Документация Mockito
- Mockito Mock vs. Spy in Spring Boot Tests
- Tag: Mockito на Bealdung
к содержанию
Дайте определение полиморфизму
В общем виде определение полиморфизма приводит Бенджамин Пирс в своей книге Типы в языках программирования:
Термин “полиморфизм” обозначает семейство различных механизмов, позволяющих использовать один и тот же участок программы с различными типами в различных контекстах.
Полиморфизм бывает следующих видов:
- Универсальный полиморфизм. Он подразделяется на:
- Параметрический полиморфизм — описывает вычисления в общем виде, абстрагируясь от конкретных типов, которые будут использованы. Параметрически полиморфные функции также называются обобщенными (Generic).
- Полиморфизм включений (inclusive) — описывает вычисления не только для конкретного типа, но для и всех его возможных подтипов. Отражает принцип подстановки Барбары Лисков.
- Специальный полиморфизм (или ad-hoc) — диспетчеризация (перенаправление) к одной или нескольким функциям для конкретного типа аргумента. Из него выделяют подтипы:
- Перегрузка (overloading) позволяет объявлять функции с одним и тем же именем, но с разными типами аргументов и их количеством (арностью).
- Неявное приведение типов — преобразование одного типа в другой по определённым правилам, описанным в стандарте языка, и выполняемое компилятором.
Безотносительно к Java полиморфизм хорошо разобран в статье Полиморфизм простыми словами.
В других источниках:
- Java Challengers #3: Полиморфизм и наследование на Хабре
- Как полиморфизм реализован внутри JVM на Хабре
- Все о переопределении в Java на Хабре
- Неформальное введение в теорию типов
- Несколько глав из Java Virtual Machine Specification: Invoking Methods, invokevirtual, Linking
- Несколько глав из Java Language Specification: Inheritance, Overriding, and Hiding, Conversions and Contexts, Type Inference
к содержанию
Что такое REST? Какое API является RESTful? Чем REST отличается от SOAP?
REST – это архитектурный стиль, который можно применить для реализации взаимодействия web-сервисов.
Вот несколько признаков REST, которые хотят услышать большинство интервьюеров:
- Концентрация на ресурсах
- Ресурс имеет уникальный URI
- Формат передачи — обычно JSON, но можно XML
- Транспортный протокол — HTTP. Строго говоря — это необязательно, но по факту и в большинстве случаев так. Следующие пункты тоже.
- Использование различных методов HTTP в соответствии с их семантикой и предназначением. GET: получить информацию о ресурсе; POST: создать новый ресурс; PUT: обновить существующий ресурс; DELETE: удалить ресурс. Иногда спорят об обновлении — PUT vs PATCH vs POST.
- Использование кодов ответа HTTP в соответствии с их семантикой и предназначением. Хорошая картинка по определению HTTP-кода ответа.
- HATEOAS обычно не используют и не спрашивают, но это тоже относится к REST, о чём можно упомянуть
Чаще всего, на моей практике, спрашивают какой HTTP-метод для чего должен использоваться или как назвать URI, чтобы API было RESTful. Однако никакой спецификации или стандарта под это нет. И вообще, строго говоря, изначально REST — это архитектурный стиль, непривязанный ни к каким протоколам. Тема раскрыта в этой статье или в этой на Хабре — комментарии сочные.
Вот принципы REST-архитектуры по Филдингу:
- Модель клиент-сервер (Client–server)
- Отсутствие состояния (Stateless) — у клиента и сервера нет необходимости отслеживать состояние друг друга
- Кэширование (Cacheable) — ответы сервера должны помечаться как кэшируемы и некэшируемые
- Единообразие интерфейса (Uniform interface) — идентификация ресурсов, манипуляция ресурсами через представление, «самодостаточные» сообщения, HATEOAS
- Слои (Layered system) — в системе может быть больше одного слоя, но компоненты системы видит и взаимодействует только с соседним слоем. Кроме клиента и сервера может быть ещё прокси и шлюз
- Код по требованию (необязательное ограничение) (Code on demand (optional)) — отправка сервером исполняемого кода клиенту
SOAP — стандартизованный протокол обмена данными.
Основные характеристики SOAP:
- Формат сообщений — XML (SOAP-XML — Envelope, Header, Body, Fault)
- SOAP-сервис должен иметь описание на языке WSDL(тоже XML)
- SOAP поддерживает множество протоколов — (TCP, UDP, HTTP, SMTP, FTP и т.д.)
- При использовании HTTP, поддерживаются методы GET и POST
Тема горячая, интересная всем web-разработчикам, поэтому на Хабре имеется уйма статей на любой вкус.
Теоритическо-практические:
- Серия постов про REST — введение, REST vs SOAP, Contract First, Code First, HATEOAS, Рекомендации и примеры на Java и Spring
- REST vs SOAP. Часть 1. Почувствуйте разницу и REST vs SOAP. Часть 2. Как проще и эффективнее организовать общение платформ?
- Дао Вебсервиса. (Или да хватит же изобретать велосипеды!)
- REST API Best Practices
- Что такое RESTful на самом деле
- Важные аспекты RESTful API для вашего проекта
- Как построить REST-like API в крупном проекте
- Разработка web API
- RESTful API для сервера – делаем правильно (Часть 1) и RESTful API для сервера – делаем правильно (Часть 2)
- Шпаргалки по безопасности: REST
- 7 вредных советов проектировщику REST API
- Самодокументированный JAX-WS с поддержкой XSD Restrictions
- REST API на Java без фреймворков
- Введение в Spring Boot: создание простого REST API на Java
- Наипростейший RESTful сервис на Kotlin и Spring boot
- SOAP-сервер на Java при участии Apache CXF и Spring
- SOAP Web-сервис средствами Spring-WS
Холиварно-дискусионные:
- REST — это новый SOAP
- REST страсти по 200
- REST API должен основываться на гипертексте
- RESTful API — большая ложь
И на всякий случай:
- Сравнение REST и GraphQL
- REST? Возьмите тупой JSON-RPC
А кроме Хабра:
- A Brief Introduction to REST
- REST CookBook
- RESTful Web APIs
- Introduction to Spring Data REST
- What is REST
- Building REST services with Spring
- Создание SOAP Web-сервиса
- Спецификация SOAP
к содержанию
Finding the ideal database for your application is largely a choice between trade-offs. The CAP theorem is one concept that can help you understand the trade-offs between different databases. The CAP theorem was originally proposed by Eric Brewer in 2000. It was originally conceptualized around network shared data and is often used to generalize the tradeoffs between different databases. The CAP theorem centers around three desirable properties; consistency is where all users get the same data, no matter where they read the data from, availability ensures users can always read from and write to the database, and finally partition tolerance ensures that the database works when divided across network.
The theorem states that at most you can only guarantee two of the three properties simultaneously. So you can have an available partition- tolerant database, a consistent partition-tolerant database or a consistent available database. One thing to note is that not all of these properties are necessarily exclusive of each other. You can have a consistent partition-tolerant database that still has an emphasis on availability, but you’re going to sacrifice either part of your consistency or your partition tolerance.
Relational databases trend towards consistency and availability. Partition tolerance is something that relational databases typically don’t handle very well. Often you have to write custom code to handle the partitioning of relational databases. NoSQL databases on the other hand trend towards partition-tolerance. They are designed with the idea in mind that you’re going to be adding more nodes to your database as it grows. CouchDB, which we looked at earlier in the course, is an available partition-tolerant database.
That means the data is always available to read from and write to, and that you’re able to add partitions as your database grows. In some instances, the CAP theorem may not apply to your application. Depending on the size of your application, CAP tradeoffs may be irrelevant.If you have a small or a low traffic website, partitions may be useless to you, and in somecases consistency tradeoffs may not be noticeable. For instance, the votes on a comment may not show up right away for all users.
This is fine as long as all votes are displayed eventually. The CAP theorem can be used as a guide for categorizing the tradeoffs between different databases. Consistency, availability, and partition tolerance are all desirable properties in a database. While you may not be able to get all three in any single database system, you can use the CAP theorem to help you decide what to prioritize.
По мере того, как вы продвигаетесь по карьерной лестнице в качестве разработчика, вам нужно будет все больше и больше думать об архитектуре программного обеспечения и проектировании систем. Важно уметь разрабатывать эффективные системы и идти на компромисс в масштабах. Системное проектирование — это обширная область, которая включает в себя множество важных концепций. Фундаментальной концепцией системного проектирования является теорема CAP. Понимание теоремы CAP является ключом к пониманию того, как проектировать сильные распределенные системы. Сегодня мы углубимся в теорему CAP, объясняя ее значение, ее компоненты и многое другое.
Содержание
- Что такое теорема CAP?
- Доказательство теоремы CAP
- Объяснение согласованности, доступности и допустимости разделов
- Последовательность
- Доступность
- Допуск на разделение
- CAP-теорема NoSQL базы данных
- Базы данных CA
- Базы данных CP
- Базы данных AP
- Теорема CAP и микросервисы
- Подведение итогов и следующие шаги
Что такое теорема CAP?
Теорема CAP, или теорема Брюера, является фундаментальной теоремой в области проектирования систем. Впервые он был представлен в 2000 году Эриком Брюером, профессором информатики в Калифорнийском университете в Беркли, во время выступления о принципах распределенных вычислений. В 2002 году профессора Массачусетского технологического института Нэнси Линч и Сет Гилберт опубликовали доказательство гипотезы Брюера. Теорема CAP утверждает, что распределенная система может одновременно обеспечивать только два из трех свойств: согласованность, доступность и устойчивость к разделению. Теорема формализует компромисс между согласованностью и доступностью при наличии раздела.
Распределенная система — это совокупность компьютеров, которые работают вместе, образуя единый компьютер для конечных пользователей. Все распределенные машины имеют одно общее состояние и работают одновременно. В распределенных системах пользователи должны иметь возможность связываться с любой из распределенных машин, не зная, что это только одна машина. Сеть распределенной системы хранит свои данные не только на одном узле, но и на нескольких физических или виртуальных машинах одновременно.
Доказательство теоремы CAP
Давайте посмотрим на простое доказательство теоремы CAP. Представьте себе распределенную систему, состоящую из двух узлов:
Распределенная система действует как обычный регистр со значением переменной X. Произошел сетевой сбой, который приводит к разделению сети между двумя узлами в системе. Конечный пользователь выполняет запрос записи, а затем запрос чтения. Давайте рассмотрим случай, когда каждый запрос обрабатывает другой узел системы. В этом случае у нашей системы есть два варианта:
- Может выйти из строя по одному из запросов, нарушив доступность системы
- Он может выполнять оба запроса, возвращая устаревшее значение из запроса на чтение и нарушая согласованность системы.
Система не может успешно обработать оба запроса, одновременно гарантируя, что чтение возвращает последнее значение, записанное при записи. Это связано с тем, что результаты операции записи не могут быть переданы с узла A на узел B из-за сетевого раздела.
Объяснение согласованности, доступности и допустимости разделов
Теперь, когда у нас есть базовое понимание теоремы CAP, давайте разберемся с аббревиатурой и обсудим значения согласованности, доступности и допустимости разделов.
Последовательность
В согласованной системе все узлы одновременно видят одни и те же данные. Если мы выполняем операцию чтения в согласованной системе, она должна возвращать значение самой последней операции записи. При чтении все узлы должны возвращать одни и те же данные. Все пользователи видят одни и те же данные одновременно, независимо от узла, к которому они подключены. Когда данные записываются на один узел, они затем реплицируются на другие узлы в системе.
Доступность
Когда доступность присутствует в распределенной системе, это означает, что система остается работоспособной все время. На каждый запрос будет получен ответ независимо от индивидуального состояния узлов. Это означает, что система будет работать, даже если несколько узлов не работают. В отличие от согласованной системы, нет гарантии, что ответ будет самой последней операцией записи.
Допуск на разделение
Когда распределенная система встречает раздел, это означает разрыв связи между узлами. Если система терпима к разделам, система не откажет, независимо от того, отбрасываются ли сообщения или задерживаются между узлами внутри системы. Чтобы иметь допуск к разделению, система должна реплицировать записи по комбинациям узлов и сетей.
CAP-теорема NoSQL базы данных
Базы данных NoSQL отлично подходят для распределенных сетей. Они позволяют горизонтальное масштабирование и могут быстро масштабироваться на нескольких узлах. Решая, какую базу данных NoSQL использовать, важно помнить о теореме CAP. NoSQL базы данных можно классифицировать на основе двух поддерживаемых ими функций CAP:
Базы данных CA
Базы данных CA обеспечивают согласованность и доступность на всех узлах. К сожалению, базы данных CA не могут обеспечить отказоустойчивость. В любой распределенной системе разделы неизбежны, а это означает, что этот тип базы данных не очень практичный выбор. При этом вы все равно можете найти базу данных CA, если она вам нужна. Некоторые реляционные базы данных, такие как PostgreSQL, обеспечивают согласованность и доступность. Вы можете развернуть их на узлах с помощью репликации.
Базы данных CP
Базы данных CP обеспечивают согласованность и устойчивость к разделам, но не доступность. Когда происходит разделение, система должна отключить несогласованные узлы, пока раздел не будет исправлен. MongoDB — это пример базы данных CP. Это система управления базами данных (СУБД) NoSQL, которая использует документы для хранения данных. Считается, что он не имеет схемы, что означает, что для него не требуется определенная схема базы данных. Он обычно используется в больших данных и приложениях, работающих в разных местах. Система CP структурирована так, что есть только один первичный узел, который получает все запросы на запись в данном наборе реплик. Вторичные узлы реплицируют данные в первичных узлах, поэтому в случае отказа первичного узла вторичный узел может заменить.
Базы данных AP
Базы данных AP обеспечивают доступность и устойчивость к разделам, но не согласованность. В случае раздела доступны все узлы, но не все они обновлены. Например, если пользователь пытается получить доступ к данным с неисправного узла, он не получит самую последнюю версию данных. Когда раздел в конечном итоге будет разрешен, большинство баз данных AP синхронизируют узлы для обеспечения согласованности между ними. Apache Cassandra — это пример базы данных AP. Это база данных NoSQL без первичного узла, что означает, что все узлы остаются доступными. Cassandra обеспечивает возможную согласованность, потому что пользователи могут повторно синхронизировать свои данные сразу после разрешения раздела.
Теорема CAP и микросервисы
Микросервисы определяются как слабо связанные сервисы, которые можно независимо разрабатывать, развертывать и поддерживать. Они включают свой собственный стек, базу данных и модель базы данных и обмениваются данными друг с другом через сеть. Микросервисы стали особенно популярными в гибридных облачных и мультиоблачных средах. А также широко используются в локальных центрах обработки данных. Если вы хотите создать приложение для микросервисов, вы можете использовать теорему CAP, чтобы помочь вам определить базу данных, которая наилучшим образом соответствует вашим потребностям.
Подведение итогов и следующие шаги
Поздравляем с тем, что вы сделали первый шаг в изучении теоремы CAP и распределенных систем! Распределенные системы обеспечивают меньшую задержку, масштабируемость, повышенную взаимосвязь и многое другое. Теорема CAP очень важна для распределенных систем и системного проектирования в целом. Сегодня мы многое рассмотрели, но еще многое предстоит узнать о распределенных системах. Вот некоторые рекомендуемые темы для дальнейшего изучения:
- Распределенные хранилища данных
- Алгоритмы распределенной системы
- Атомарность
Распределенная система (распределенная система) становится все более важной, большие веб-сайты почти все распределены.
Самая большая трудность в распределенной системе — как синхронизировать статус каждого узла. Теорема CAP является основной теоремой в этом отношении и отправной точкой для понимания распределенных систем.
1. Три индикатора распределенных систем
В 1998 году Эрик Брюэр, ученый-компьютерщик из Калифорнийского университета, предложил распределенные системы иметь три индикатора.
- Consistency
- Availability
- Partition tolerance
Их первые буквы — C, A и P соответственно.
Эрик Брюэр сказал, что эти три показателя не могут быть достигнуты одновременно. Этот вывод называется теоремой CAP.
Два, допуск на разделение
Сначала взгляните на «Допуск на разделение», который на китайском языке называется «допуск на разделение».
Большинство распределенных систем распределены по нескольким подсетям. Каждая подсеть называется разделом. Отказоустойчивость раздела означает, что связь между зонами может быть нарушена. Например, если один сервер расположен в Китае, а другой — в США, это два региона, и связь между ними может быть невозможна.
На приведенном выше рисунке G1 и G2 — это два сервера, которые охватывают зоны. G1 отправляет сообщение G2, а G2 может его не получить. Эту ситуацию необходимо учитывать при проектировании системы.
Вообще говоря, отказоустойчивости раздела нельзя избежать, поэтому можно считать, что P CAP всегда действителен. Теорема CAP говорит нам, что оставшиеся C и A не могут быть выполнены одновременно.
Три, последовательность
Последовательность на китайском языке называется «последовательность». Это означает, что операция чтения после операции записи должна вернуть это значение. Например, если запись v0, пользователь инициирует операцию записи в G1 и изменяет ее на v1.
Затем операция чтения пользователя получит v1. Это называется согласованностью.
Проблема в том, что пользователь может инициировать операцию чтения в G2. Поскольку значение G2 не изменилось, возвращается v0. Результаты операций чтения G1 и G2 несовместимы, что не обеспечивает согласованности.
Чтобы G2 изменился на v1, необходимо, чтобы G1 отправлял сообщение G2, когда G1 пишет, запрашивая G2 перейти на v1.
В этом случае, если пользователь инициирует операцию чтения для G2, также может быть получено v1.
Четыре, доступность
Доступность на китайском языке называется «доступностью», что означает, что пока сервер получает запрос пользователя, он должен отвечать.
Пользователь может выбрать запуск операции чтения в G1 или G2. Независимо от того, какой это сервер, пока он получает запрос, он должен сообщать пользователю, является ли он v0 или v1, иначе доступность не будет удовлетворена.
В-пятых, противоречие между согласованностью и доступностью
Почему нельзя обеспечить согласованность и доступность одновременно? Ответ прост, потому что может произойти сбой связи (т.е. возникает отказоустойчивость раздела).
Если согласованность G2 гарантирована, то G1 должен заблокировать операции чтения и записи G2 во время операций записи. Только после синхронизации данных можно будет снова открыть чтение и запись. В течение периода блокировки G2 не может читать или писать, и он недоступен.
Если доступность G2 гарантирована, G2 не может быть заблокирован, поэтому согласованность не устанавливается.
Таким образом, G2 не может добиться согласованности и доступности одновременно. При проектировании системы можно выбрать только одну цель. Если обеспечивается согласованность, доступность всех узлов не может быть гарантирована; если обеспечивается доступность всех узлов, согласованность не может быть достигнута.