Эффективно обрабатывать сообщения с темами?

Question

Эффективно обрабатывать сообщения с темами?

2

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

Затем у меня есть второй процесс, который читает из этой же таблицы каждые [n] секунд, получая до 100 сообщений в одном чтении, и если какие-либо новые записи, очереди каждого, которые будут отправлены на свой собственный ThreadPool, выпущенный backgorund thread.

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

Проблема в том, что я мог бы получить много сообщений в течение одного интервала: было бы гораздо лучше оставить их в Db до нужного, а не в памяти, в очереди в ThreadPool, ожидая.

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

Одна из моих идей заключалась в том, чтобы подсчитать, сколько рабочих потоков я поставил в очередь (например: 500, равно максимальным потокам, которые я установил первым) и посчитать их по мере их завершения. Если они упадут ниже 1/2 (например: 250), сверните проверку Db. Если записи найдены, отлично, получите 100 за раз, пока таблица db не будет полностью прочитана, или снова будет достигнуто значение 500 max.

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

Есть ли у кого-нибудь советы/комментарии/опыт работы с такой системой? Является ли подход твердым? Или серьезно испорчен?

AndrewS 04 июль 2009, в 03:19

Источник

0

Вы обсуждаете сценарий «Производитель / Потребитель» с одним производителем и несколькими потребителями. Это общий шаблон проектирования, и есть много ссылок, таких как devpinoy.org/blogs/jakelite/archive/2009/01/12/… вокруг. Я постараюсь собрать еще несколько ссылок позже и опубликовать лучший ответ, но я решил оставить вам некоторые условия в Google на данный момент. :-) HTH.
Stobor 04 июль 2009, в 05:57
0

Любопытство: о какой базе мы говорим? Поставляется ли он с возможностью обмена сообщениями из коробки случайно, как это делают SQL Server, Oracle и DB2?
Remus Rusanu 06 июль 2009, в 02:50

Теги:

c#

multithreading

1 ответ

Ещё вопросы

Вы обсуждаете сценарий «Производитель / Потребитель» с одним производителем и несколькими потребителями. Это общий шаблон проектирования, и есть много ссылок, таких как devpinoy.org/blogs/jakelite/archive/2009/01/12/… вокруг. Я постараюсь собрать еще несколько ссылок позже и опубликовать лучший ответ, но я решил оставить вам некоторые условия в Google на данный момент. :-) HTH.
Любопытство: о какой базе мы говорим? Поставляется ли он с возможностью обмена сообщениями из коробки случайно, как это делают SQL Server, Oracle и DB2?

AndrewS · Answer 1 · 2009-07-03T23-30-00.000Z

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

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

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

Привет, Эндрю: Используемые сервисы доставки являются асинхронными веб-сервисами, так что да, время их выполнения значительно медленнее, чем доступ к БД. И поэтому (я думаю) хорошо подходит для создания большего количества потоков, чем процессоров. С ThreadPool переключение контекста относительно безболезненно. Но что более важно, поиск каждого запроса на отправку может завершиться неудачей из-за тайм-аутов, лучше всего выделить поток для каждого? Несколько таймаутов в одном потоке могут вызвать реальное накопление сообщений ...
@Ciel: вы сказали: «С ThreadPool переключение контекста относительно безболезненно». Я не думаю, что это верное утверждение. Один поток на ядро процессора идеален.