наша система имеет 60 компьютеров, на каждом из которых запущено 12 задач (потоков), которые должны «получить следующую работу». В общем, речь идет о 50 тысячах «рабочих мест» в день. посчитайте, сколько транзакций в минуту, и поймите, что время задачи является переменным, чтобы можно было получить несколько «всплывающих» событий в одно и то же время.
У нас была первая версия с использованием MSMQ. вывод: держись подальше . Хотя с нагрузкой и синхронизацией все в порядке, у него было 2 проблемы. один раздражающий и один прерыватель сделки.
Раздражает: как корпоративное программное обеспечение, MSMQ имеет потребности в безопасности, которые просто делают его еще одним средством настройки и борьбы с сетевым администратором клиентов.
Прекращение сделки: затем пришло время, когда мы хотели взять следующую работу, но не с использованием простого всплывающего окна, а что-то вроде «получить следующую синюю работу» или «получить следующую желтую работу». не могу этого сделать!
Мы перешли к плану B: реализовали наш собственный Q с одной таблицей SQL 2005. не может быть счастливее
Я подчеркнул, протестировать его с 200K сообщений в день, сработало. Мы можем сделать «следующую» логику настолько сложной, насколько захотим.
подвох: вам нужно быть очень осторожным с SQL, который принимает следующий элемент. Так как вы хотите, чтобы это было быстро и без блокировки. есть 2 очень важных подсказки SQL , которые мы использовали, основываясь на некоторых исследованиях. Волшебство происходит примерно так:
SELECT TOP 1 @Id = callid
FROM callqtbl WITH (READPAST, XLOCK)
where 1=1 ORDER BY xx,yy