Рабочие роли Azure. Самый оптимальный способ агрегирования данных в памяти?

У меня есть X рабочих ролей, которые будут обрабатывать очереди Azure с использованием нескольких потоков. Данные, которые текут в этих очередях, довольно простые (для этого Client_ID у нас есть действие A, B или C, одно действие на транзакцию), но их будет много, более 5000 транзакций в секунду. Теперь мне нужно агрегировать их в формате, который показывает Client_ID, 43 транзакции типа A, 20 для B и 11 для C. По сути, суммируйте их. Но GetMessages в очереди может получить только 32 сообщения из очереди.

Мой вопрос: должен ли я продолжать извлекать 32 в то время, пока я не скажу 1000, а затем просмотреть их и суммировать? Или хранить итоги в списке, очереди или кеше?

Что бы вы порекомендовали для наиболее оптимального механизма агрегатора для моего сценария, зная, что может быть 10 рабочих ролей с 5 потоками, постоянно получающими сообщения из этих очередей?


person enlightenedOne    schedule 27.02.2013    source источник
comment
Я делал это раньше. Какой уровень точности тут нужен - 100% или можно допустить некоторое проскальзывание (скажем в случае, если экземпляр выйдет из строя).   -  person hocho    schedule 28.02.2013
comment
@Lucifure - это не критические данные, так что есть где поэкспериментировать. Жду вашего предложения :)   -  person enlightenedOne    schedule 28.02.2013
comment
Если точность не критична, ответ Knightpfhor - на деньги. Читайте и удаляйте сообщения как можно быстрее, и вы можете (32 за раз, возможно, в нескольких потоках), хранить сводные данные в памяти и периодически записывать их.   -  person hocho    schedule 28.02.2013


Ответы (1)


Для начала, я думаю, было бы неплохо прочитать эту всегда популярную статью. и связанные Эпизод Cloud Cover о создании масштабируемых счетчиков в Azure.

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

person knightpfhor    schedule 27.02.2013