Пора синхронизировать согласованность в системах IIoT

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

Во-первых, давайте проясним, что этот блог не о букве «C» в ACID (https://en.wikipedia.org/wiki/ACID). Согласованность ACID гарантирует, что обновления хранилища данных действительны в соответствии с набором ограничений. В этом блоге основное внимание уделяется согласованности, которая описывает, что происходит, когда данные реплицируются между распределенными хранилищами. Как оказалось, ACID делает скажите что-нибудь об этом, но это «Я» (Изоляция), а не «С». Сбивает с толку? Немного, но потерпите меня.

Изоляция также называется сильной согласованностью . . Когда система строго согласована, все операции записи и чтения между распределенными хранилищами выполняются в одном и том же порядке для всех приложений в этой системе. Это сложный способ сказать, что когда одно приложение что-то пишет, все приложения, которые читают после запись, гарантированно увидит новые данные.

Это свойство оказывается невероятно полезным во многих системах. Это гарантирует, что никакие два человека не смогут заказать один и тот же холодильник на веб-сайте покупок, даже если они совершают покупки в одно и то же время. Сильная согласованность обеспечивает одинаковый порядок операций глобально , поэтому две покупки всегда обрабатываются всеми в одном порядке. На практике это означает, что при второй попытке покупки гарантированно обнаружится, что холодильника нет в наличии.

Сильная согласованность звучит неплохо, так почему же не все системы ее используют? Это из-за того, что называется теоремой CAP (https://en.wikipedia.org/wiki/CAP_theorem). Во-первых, небольшое примечание:многие справедливо критикуют CAP за то, что он слишком прост для описания поведения сложных распределенных систем - поэтому будьте осторожны при его использовании - но он действительно обеспечивает полезную основу для обсуждения моделей согласованности. Я не буду вдаваться в подробности CAP, потому что в Интернете есть множество ресурсов, которые делают работу намного лучше, чем я мог бы надеяться сделать здесь.

Таким образом, CAP сообщает нам, что происходит в распределенных системах, когда приложения временно теряют способность «разговаривать», или, другими словами:когда сеть выходит из строя. Оказывается, система не может быть строго согласованной и всегда гарантируем время безотказной работы, независимо от потери связи. Облом.

Это звучит сложно, но на самом деле довольно интуитивно понятно. Помните, насколько сильная согласованность требует глобального порядка для всех операций в системе? Это означает, что прочитать обязательно см. все предыдущие записи, от всех. Если не все приложения подключены, то это невозможно гарантировать. Одна заявка могла разместить заказ на холодильник, но если не все заявки еще получили этот заказ, они не могут разместить новые заказы. Это приводит к простою сайта покупок!

Время простоя можно уменьшить, направив больше ресурсов на решение проблемы, например, выполнив репликацию базы данных (больше места для хранения) или развернув избыточные веб-серверы (больше вычислений). Сегодня это почти тривиально сделать в общедоступных облачных инфраструктурах, хотя это становится довольно дорогим и сложным, когда в системе много движущихся частей, например, в микросервисных архитектурах. Когда система не работает в облаке, добавление дополнительных ресурсов далеко не тривиально, поскольку хранилище, вычислительные ресурсы и пропускная способность гораздо более ограничены в не облачных средах.

Таким образом, хотя сильная согласованность удобна для приложений, она требует больших затрат на инфраструктуру (и на ваш кошелек!). Чтобы обойти эти проблемы, умные люди придумали решения, которые не столь педантичны, когда дело доходит до согласованности, но все же работоспособны с точки зрения приложения. Мы говорим о «возможной согласованности». Время для другого определения.

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

Поскольку приложениям не нужно ждать друг друга, время безотказной работы в конечном итоге согласованной системы теоретически бесконечно - при условии, что ваши приложения не выйдут из строя и не произойдет отключение электроэнергии. Однако бесконечность непрактична; через некоторое время вы действительно ожидаете, что ваши приложения снова подключатся. Поэтому в конечном итоге согласованные системы обычно устанавливают ограничение на время, которое может потребоваться для достижения согласованности. Когда этот предел истекает и приложения не могут синхронизироваться, происходит восстановление после сбоя.

Доступность - не единственное преимущество в конечном итоге согласованных систем. Поскольку чтение и запись не требуют синхронизации, как в случае с строго согласованными системами, они выполняются намного быстрее. Отсутствие синхронизации также обеспечивает прямую одноранговую связь, что дополнительно повышает производительность, а также повышает надежность, поскольку устраняет необходимость в централизованном брокере сообщений, который создает единые точки отказа.

Хотя конечная согласованность не работает для торговых сайтов, при рассмотрении ее преимуществ (доступность, производительность, надежность, эффективность использования ресурсов) неудивительно, что она часто используется в критически важных системах.

Пакет продуктов RTI Connext является ведущей реализацией стандарта OMG DDS, который широко используется в качестве протокола в критически важных промышленных системах Интернета вещей. Большое различие между OMG DDS и другими протоколами связи заключается в том, что DDS ведет себя как распределенная база данных, которая постоянно синхронизируется между приложениями, тогда как другие протоколы обычно предоставляют интерфейс для отправки сообщений и оставляют управление состоянием на усмотрение приложения.

Если вы думаете, что распределенная база данных звучит как нечто, требующее согласованности, вы правы. RTI Connext DDS должен постоянно балансировать между доступностью и производительностью и согласованностью, чтобы иметь возможность работать в самых требовательных критически важных средах. По умолчанию RTI Connext DDS использует конечную согласованность, которая гарантирует, что приложения, созданные с его помощью, не прекращают работу при сбое сети, обеспечивая при этом, что все приложения в конечном итоге будут использовать один и тот же взгляд на «мир».

Теперь вы видите, как нечто такое абстрактное, как «согласованность», имеет далеко идущие последствия и должно рассматриваться как важная тема на раннем этапе проектирования систем. К сожалению, никогда не бывает так просто, чтобы быть либо «строго последовательным», либо «в конечном итоге последовательным». Лямбда-архитектура (https://en.wikipedia.org/wiki/Lambda_architecture) - лишь один из примеров, в котором используется как сильная, так и конечная согласованность, чтобы получить лучшее из обоих миров. Имея такое множество оттенков согласованности, системные архитекторы должны принимать сложные решения о том, какую согласованность может себе позволить их система.

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

Узнайте больше об услугах RTI здесь:https://www.rti.com/services