C #: лучший способ обмена данными между несколькими процессами и / или потоками - PullRequest
0 голосов
/ 17 октября 2018

AC # Веб-службе Restful (в Windows Server 2012 Standard) необходимо отправлять команды оборудованию через программу сервера моего сокета C #, которая работает на том же сервере.Когда веб-службы пытаются отправить команду выбранному оборудованию, поток связанного оборудования может забрать команду и отправить ее этому оборудованию.После того, как это выбрано, это должно быть удалено этой темой.В то же время Поток n, который связан с Оборудованием n, также может получить команду Оборудования n, а Поток n может удалить эту команду после того, как эта команда будет поднята и отправлена.Пожалуйста, обратитесь к диаграмме архитектуры системы ниже.

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

System architecture image

Ответы [ 3 ]

0 голосов
/ 17 октября 2018

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

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

Некоторые преимущества использования стороннихброкер сообщений:

  • Они могут буферизировать сообщения для получателей, которые в данный момент не подключены
  • Большинство из них предоставляют простой в использовании пакет C #, поэтому настройка очень мала
  • Как правило, они обеспечивают SLA на 99,99% и более

Некоторые недостатки по сравнению с чисто межпроцессным решением на одном хосте:

  • У них более высокая задержка из-за их связи с внешним сервером брокера сообщений
  • У них более низкая максимальная пропускная способность, опять же из-за их связи с внешним сервером
  • Они обычно стоят денег (иногда естьразрешение на отправку, например, 100 000 сообщений бесплатно)
0 голосов
/ 18 октября 2018

Использование вашей базы данных

Есть много способов сделать это OP, например - Файлы с отображением в памяти или Анонимные каналы или MSMQ ,за 3 примера верхней части моей головы.Но самый простой подход - использовать вашу базу данных .В частности, я бы сделал это следующим образом:

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

  2. Запрограммируйте веб-службы на обновление базы данных.,Например, когда пользователь хочет «отправить» команду, просто добавьте ее в таблицу.Пока не беспокойтесь об оборудовании.

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

Это дастВы - простое, отказоустойчивое решение без внедрения каких-либо новых технологий в вашу архитектуру.

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

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

0 голосов
/ 17 октября 2018

Служба Windows может иметь дополнительный прослушиватель сокетов (или аналогичный) для получения команд для любого из подключенных устройств и поддержания BlockingCollection для каждого устройства.Поток, которому принадлежит соединение с каждым устройством, может просто зацикливаться на получении сообщений от BlockingCollectoion и взаимодействии с устройством через его сокет.

...