Отправка уведомления в веб-роль Azure из роли рабочего Azure - передовой опыт - PullRequest
2 голосов
/ 30 августа 2011

Положение

Пользователи могут загружать документы, сообщение об очереди будет помещено в очередь с идентификатором документов. Рабочая роль поднимет это и получит документ. Разбери это полностью с Lucene. После завершения анализа Lucene IndexSearcher на веб-странице должен быть обновлен.

В веб-роли я сохраняю статический Lucene IndexSearcher, потому что в противном случае вам придется выполнять новый IndexSearch при каждом поисковом запросе, что приводит к большим накладным расходам и т. Д.

Я хочу отправить уведомление от Рабочей роли в веб-роль о необходимости обновить свой IndexSearcher.

Возможные решения

  • Сделать какую-то очередь уведомлений. Веб-роль запускает бесконечную задачу, которая постоянно проверяет очередь уведомлений. Если он находит сообщение, он должен обновить IndexSearch.
  • Запустите службу WCF на рабочей роли и подключитесь к веб-роли. Выполните обратный вызов из рабочей роли и скажите через веб-службу через службу, что ему нужно обновить свой IndexSearcher.
  • Просто регулярно обновляйте его

Каково было бы лучшее решение или есть какое-то другое решение для этого?

Большое спасибо!

Ответы [ 2 ]

2 голосов
/ 30 августа 2011

Если ваши рабочие роли записывают подробности каждой законченной работы в таблицу, используя PK, например, (DateTime.MaxValue - DateTime.UtcNow).Ticks.ToString("d19"), у вас будет отсортированный список последних обработанных работ. Установите свою веб-роль для опроса таблицы следующим образом:

var q = ctx.CreateQuery<LatestJobs>("jobstable")
    .Where(j => j.PartitionKey.CompareTo(LastIndexTime.GetReverseTicks()) < 0)
    .Take(1)
    .AsTableServiceQuery()

if (q.Count() > 0)
{
    //new jobs exist since last check... re-index.
}

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

Однако у вас осталась одна проблема: похоже, у вас есть 1 веб-роль, которая обновляет индекс. Эта одна веб-роль может, конечно, опрашивать эту таблицу с любой выбранной вами частотой (просто отследите LastIndexTime для поиска позже). Ваша проблема заключается в том, как контролировать параллелизм веб-ролей, если у вас их несколько. Поддерживает ли каждая веб-роль свой собственный индекс, или у вас есть один, где он хранится для всех? Извините, но я не эксперт в Lucene, если это должно быть очевидно.

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

Обновление на основе комментария:

Если каждый экземпляр WebRole имеет свой собственный индекс, вам не нужно беспокоиться об аренде. Это только если они совместно используют ресурс BLOB-объектов вместе. Таким образом, этот метод должен работать как есть, и ваше единственное потенциальное препятствие заключается в том, что интервалы опроса для веб-ролей могут быть немного не синхронизированы, что приведет к несколько разным результатам до полного обновления (в зависимости от того, какой экземпляр вы нажали). Опрос каждые 30 секунд на столе, и это будет вашим максимальным из синхронизации. Каждому экземпляру веб-роли просто необходимо отследить, когда он обновлялся в последний раз, и выполнять добавочный поиск с этой точки.

1 голос
/ 30 августа 2011

В зависимости от частоты загрузки вы можете найти сообщения в очереди, чтобы вызвать ненужные обновления.Например, если вы получаете дюжину закачек и обрабатываете их в непосредственной близости, у вас теперь будет дюжина сообщений в очереди, каждое из которых сообщает вашей веб-роли об обновлении.Было бы разумнее сохранить один сигнал (возможно, строку таблицы или строку SQL Azure).Вы можете просто установить значение строки в 1, сигнализируя о необходимости обновления.Когда ваша веб-роль обнаружит это изменение, сбросьте на 0 и запустите обновление.Примечание. При использовании строки таблицы Azure вам нужно будет опросить обновления (и в зависимости от трафика вы можете начать накапливать большое количество транзакций).Вы также можете использовать кэш AppFabric для этого сигнала.

Вы можете использовать службу WCF на внутренней конечной точке вашей веб-роли.Тем не менее, у вас все еще есть проблема (если вы получаете, скажем, дюжину загрузок во время обновления веб-ролика, вы не хотите делать еще дюжину обновлений).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...