Каковы основы распределенных систем в реальном времени?

Question

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

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

Вопрос заключался в том, как отображать данные в реальном времени на вашем интерфейсе. Что нужно сделать на бэкэнде? Я упомянул шаблон "Производитель / Потребитель" для подачи данных в реальном времени. Ему понравилось, но он сказал, что ему нужно больше на втором собеседовании.

Любая помощь могла бы быть полезна,

Answer 1

Каковы основы распределенных систем реального времени?

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

распределенный

Распределенная система связывает ряд независимых вычислительных объектов с локальными свойствами посредством механизма связи. Как следствие, алгоритмы и другие компоненты проектирования должны учитывать синхронность и модель отказов. Полезное резюме (не совсем объективное) проблем распределенных вычислений включено в " Восемь заблуждений распределенных вычислений" Дойча. (См. Это полезное изложение.) Все это полезно рассмотреть в (в реальном времени) распределенном проектировании; каждый из них является отправной точкой для решения важных вопросов проектирования и реализации:

1. Сеть надежна
2. Задержка равна нулю
3. Пропускная способность бесконечна
4. Сеть безопасна
5. Топология не меняется
6. Есть один администратор
7. Транспортная стоимость равна нулю
8. Сеть однородна

Реальное время

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

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

Композиция распространяется в реальном времени

• Явные требования к своевременности - каковы требования, как они соотносятся с действиями, являются ли они истинными требованиями к своевременности трансузла, как будут четко представлены временные ограничения в проектировании и реализациях, и как будут обнаруживаться, сообщаться и устраняться сбои?
• Синхронизация времени - Каковы требования и механизмы для достижения синхронизации часов? Вики по синхронизации часов; многие приложения требуют только NTP; Более строгие требования могут потребовать специального оборудования (например, IRIG-B) или подходов.
• Требования к синхронизации - Какие ограничения по синхронности ограничивают требования к синхронизации системы и какие требования предъявляются к ней? Это связано с синхронизацией часов, но не идентично. Несколько мыслей о формальных моделях от Дуга Дженсена; википедия по асинхронной и синхронной системе; ТАК вопрос о частичном упорядочении событий;
• Шаблоны проектирования - что такое движущиеся части и как они связаны с транспортом? (В частности, как эти отношения влияют на своевременность?)
• Промежуточное программное обеспечение - Как вы собираетесь кодировать распределенные аспекты системы? Примеры включают CORBA в реальном времени (вот хорошая страница из OIS) или DDS.
• Ограничения времени - Как вы собираетесь документировать, измерять и применять ограничения времени в системе?
• Частичный отказ. Система реального времени обычно предъявляет требования к надежности. Одним из уникальных аспектов распределенных систем является возможность возникновения целых классов отказов, называемых "частичными" сбоями, либо из-за реальных сбоев / сбоев связи, либо из-за ошибок своевременности, которые должны рассматриваться как сбои. ТАК вопрос о сбоях подходов;
• ОСРВ - Какие операционные системы в реальном времени будут использоваться?

Несколько ссылок

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

В последнее время концепция (ненадежных) детекторов отказов стала полезной синхронной конструкцией, обеспечивающей полезные теоретические рассуждения и практические методы формулирования / проектирования / конструирования для систем DRT. Основным документом на эту тему является Aguilera, Le Lann и Toueg " О влиянии быстрых детекторов отказов на отказоустойчивые системы реального времени". Эта статья тяжело катается на санях, но вознаграждает каждую унцию интеллектуальных инвестиций.

Answer 2

На высоком уровне есть два основных способа передачи данных в режиме реального времени из серверной части в интерфейсную:

• Push: вы можете "проталкивать" данные клиенту, отправляя сообщения. В прошлом я использовал это для отправки клиенту межпроцессных сообщений, чтобы предупредить пользовательский интерфейс о том, что произошло обновление. Это самый быстрый способ передачи информации, но есть и сложности. Например, вы не можете (пока) отправлять сообщения IPC в веб-приложение, если вы не используете Flash, Silverlight и т. Д. А также вам нужно ограничить эти сообщения, потому что, если вы отправляете слишком много, это может сделать ваш пользовательский интерфейс менее отзывчивым. Вот некоторые из технологий, которые можно посмотреть здесь: MSMQ, TCP/IP и эквиваленты WCF.

• Pull: ваш пользовательский интерфейс может периодически запрашивать данные из серверной части. Преимущество этого метода в том, что его легко кодировать в пользовательском интерфейсе: просто опрашивать источник данных каждый X. Но, конечно, очевидным недостатком является то, что существует разрыв между моментом обновления и моментом получения обновления вашим приложением. Это может быть неприемлемо для обработки в реальном времени. Во всяком случае, в этой модели вы можете позвонить в веб-сервис или позвонить в базу данных.

Это только отправная точка, конечно. Можно использовать оба метода, данные можно кэшировать на клиенте и т. Д. Все зависит от потребностей приложения.