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

Question

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

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

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

Любая помощь будет очень признательна,

Answer 1

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

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

Распространяется

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

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

Real-Time

Система

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

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

Компоновка, распространяемая в реальном времени

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

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

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

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

Answer 2

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

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

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

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