избыточность приложений с многопотоковой обработкой

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

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

источник

2012-05-16 Steve Goykovich

Это действительно зависит от того, что вы подразумеваете под «что-то в приложении не удается». Можете ли вы привести примеры неудач, из которых вы хотите восстановить? – dlev

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

Ну, самый простой способ перезагрузить службу при сбое - позволить Windows сделать это. Вы просто настраиваете службу на автоматический перезапуск, это очень просто. Вы также можете сделать это с помощью программы установки программы. Для справки о том, как это сделать, см. Этот пост: Building a Windows Service – Part 4: Extending the Service Installer.

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

Реальный вопрос: что это за служба?

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

источник

2012-05-16 18:06:12

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

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

источник

2012-05-16 18:02:02 GETah

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

Он встроен в любое окно, в котором у вас есть учетные данные, и вся тяжелая работа для вас выполнена. Это всегда бесполезно для служб, которые мне нужны, чтобы всегда быть в движении.

Для этого вы просто установите для типа службы значение «Автоматически» (это перезапустит его, если ваша коробка когда-либо перезагрузится), тогда есть варианты для первых трех перезагрузок, которые вы можете установить для всего, что вам нужно, изнутри management window в разделе услуг.

подробнее: windows service documentation

источник

2012-05-16 18:07:27 mirezus

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

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

Watchdog перезапускает рабочий процесс, если он не получает отчет о состоянии своевременно.
Watchdog перезапускает рабочий процесс, если он получает отчет о состоянии сбоя.
Watchdog перезапускает рабочий процесс, если он обнаруживает утечку памяти.
Watchdog запускает рабочий процесс, если он не работает.

Помимо последнего элемента диспетчер управления службами Windows не может обрабатывать другие 3 случая. Это одна из причин, почему мне нравится идея процесса сторожевого пса. Другая причина заключается в том, что ваша основная логика может зависать при блокирующем вызове. Поскольку Thread.Abort не рекомендуется, потому что он разлагает состояние, у вас действительно очень мало вариантов, кроме как в любом случае убить рабочий процесс.

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

источник

2012-05-16 19:37:20

избыточность приложений с многопотоковой обработкой

ответ

Смежные вопросы