Производитель - Потребитель и очередь базы данных

У меня есть механизм производителя-потребителя, Я вынужден хранить произведенные товары в базе данных, это требование. Также у меня есть несколько производителей и несколько потребителей, производителей и потоков потребителей, которые будут обращаться к записям в нескольких таблицах базы данных; Столбец ProcessID будет определять, какой поток к какой записи обращается.

Потоки будут работать через службу Windows.

ProcessID создается по трем причинам.

  • 1- Если поток завершился некорректно, будет использоваться идентификатор процесса, чтобы избежать повторного запуска обработки.

  • 2- Потоки синхронизируются с помощью блокировки базы данных, и, надеюсь, у меня будут только блокировки строк, и, вероятно, у меня будет несколько заблокированных потоков на короткое время, потому что каждый поток будет обращаться к нескольким записям, отмеченным ProcessID.

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

Если бы я использовал массив In-Memory в качестве очереди, я сомневаюсь, что это повысит производительность, у него есть следующие недостатки: -

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

  • Производитель вставит элемент в базу данных и получит его идентификатор с помощью параметра Output stp, затем он поместит элемент в очередь с его идентификатором, избегая его повторного чтения из базы данных, это единственное преимущество очереди в памяти, избегая перечитать элемент из базы данных. Обратите внимание, что после того, как запись вставлена ​​в БД, ничего не будет обновлять ее, кроме потребителя.

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

  • Класс Queue должен будет заблокировать частный объект, методы очереди доступа должны быть синхронизированы. Я чувствую, что дублирую вероятность того, что поток будет голоден. и я чувствую, что дублирую время, в течение которого поток будет заблокирован в ожидании.

Два вопроса

1- Мне что-то не хватает в этом дизайне? Как вы думаете, это сработает?

2- Не использовать ли очередь в памяти?


multithreading architecture thread-safety producer-consumer database-locking
person Costa    schedule 02.07.2013    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

Что касается этого, вы можете дважды проверить перед передачей потребителю:

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

И, конечно же, это гораздо более понятный дизайн ... вы будете следовать принципу единой ответственности, когда производители и потребители будут заботиться только о производстве и потреблении товаров.

Что касается:

1- Мне что-то не хватает в этом дизайне? Как вы думаете, это сработает?

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

person Art Licis    schedule 02.07.2013