SQL Server услугата брокер, #

Здравейте на всички! И накрая, ръка дойде да напише друга статия профилирани. Днес бих искал да говоря за това, което може да работи в продължение на около една седмица или две по време на работа поради липсата на основния проект.
Моля да се обичат и полза: SQL Server Service Broker!

Така прелюдия. Проект отлежава. Същността на пъзелите е доста популярен: клиентът желае да изпраща данни в базата данни, ние трябва да ги обработи по някакъв начин много умело, докато се прибягва до външни ресурси, и след това се върнете обратно резултатите. И този трик е, че "нормално" начин за нас, никой не може да уведоми и не мога да чакам (или не може, не е същността). Просто искам да кажа, че в действителност рамката, за да получите още по-трудно: няма какво да се напише велосипедите си, ние използваме Service Broker, и всички са доволни. Ами ... това е необходимо да се разбере, че за такова животно.

Ако това е кратко и в случая, тогава ние включите лампичката (тук си отсечен всички връзки към базата данни):

Допълнителна извайвам нашите видове съобщения, договори, опашки, услуги. Е, можете да се отдадете инча
Например, тъй като изпращането на съобщението (за местно Прекрати разговор може да си стиснем ръцете - така че трябва да не се направи и друга точка и запетая бележка.)

Или да вземем съобщение:

Това е кратък за синтаксиса. Сега копаем още по-дълбоко в проблема.

По този начин, проблемът с пари и аз съвсем накратко подчертано по-горе. Но това е на всички думи. Необходимо е да се такъв план и за разпространение на хартията. По-долу е схема на себе си (кликване) и описание.

1, 2. Молбата за клиент вае входящо съобщение (m1) и го поставя в опашка входящи съобщения (опашка).
3. На сървъра, ние имаме създадена външен активиране (Ext активатор, система за обслужване не е заспал).
4. Поради това подкопава нашия модул с магия (Mapper).
5. Устройството дърпа умна (отново) hranimku (SP Dequeue В).
6. Кои достига във всички входящи съобщения.
7. агнешки дреболии от масив от най-много съобщения.
8. тъпча в временна таблица (таблица В) натоварване от ключовите послания от пробата (и).
9. И се връща един и същ основен модул (ние ще се върне просто не мога временна таблица).
10. Сега, модулът има ключ за проба, така че той почука на функцията на маса (TVF Dequeue В).
11, 12. За да изберете я с помощта на полезните части на съобщения.
13. И след това - поредица от съобщения.
14. Превръщане 1 (Карта 1).
15, 16, 17. чукат служба за външна дейност и събиране резултат (REQ, Външна служба, ВЕИ процес).
18. Преобразуване 2 (Карта 2).
19, 20. Ние теглене на друг hranimku (SP Enqueue Out), за да се бутам изходящо съобщение (m2) към опашката на изходящи съобщения (Queue си).
21, 22. доволен клиент взима съобщението.
23. Ние почистване на временна таблица с ключ.

Ако обърнете внимание на колоната с минимални стойности, той ще бъде ясно, че най-еднократна яде IO-интензивни задачи (стартирате изпълнимия файл, откриването на съединения). Ако направите всичко това ще доведе до ума и се зареди изцяло, а след това най-вероятно, ще започне да потъва винта (за tempdb) и се появява заключване (също трябва да мисля за). Такава е интересно нещо. Тъй като нападение, както и на целия SQL Server, не osilivaetsya.

За резултата - пита на GitHub. И сега - всичко добро дело седмица.