Здравствуйте, Vladimir Alekseev, Вы писали:

VA>Есть ли реальная необходимость "забирать" задачи из очереди в БД напрямую из worker'ов? Почему бы не сделать отдельный поток/процесс, который выбирает в себя весь список задач (список id), которые нужно выполнить, а всем worker'ам выдавет id следующей задачи по запросу "Дай мне следующую задачу"? В случае многопроцессовой реализации это, возможно, выльется в написание некого сервиса, а в случае многопоточной реализации — в простой "Queue<Task>".
Дело в том, что уже есть инфраструктура NLB-ESB-DB. Каждый узел выполнен в виде нескольких машин — и сервисы ESB например, работают параллельно (т.е. worker'ы работают на разных машинах и друг о друге ничего не знают). Точка соприкосновения здесь БД — она тоже крутится на двух машинах, но представляет собой одну базу данных и является удобной точкой хранения состояния. Делать новый сервис/кластер не хочется, да и не вижу что принципиально изменится: что меняется от того, что некий процесс вберёт в себя весь список задач? В любом случае каждый чих надо фиксировать в БД транзакцией, иначе при отключении питания состояние будет потеряно. Другое дело, что дополнительный сервис как единая точка может ставить lock на любые действия и работать с БД в одно лицо. Но тогда этот сервис является узким местом в плане производительности и надёжности.
Так в принципе можно вообще в лоб — одним потоком читать из БД, рассылать и удалять.

VA>Побочный эффект — некая задача может быть передана worker'у дважды, если программа упала после того, как она была выполнена в первый раз, но до того, как была удалена из очереди. Но с этим, ИМХО, бороться проще, чем с зависанием задачи если worker ее заблокировал и упал.
От передачи одного сообщения дважды ни один из моих сценариев также не застрахован (по-моему это задача о двух генералах).