Один из вариантов - обработать очередь в RunAsync, что-то вроде этого:
protected override async Task RunAsync(CancellationToken cancellationToken)
{
var store = await StateManager.GetOrAddAsync<IReliableQueue<T>>("MyStore").ConfigureAwait(false);
while (!cancellationToken.IsCancellationRequested)
{
using (var tx = StateManager.CreateTransaction())
{
var itemFromQueue = await store.TryDequeueAsync(tx).ConfigureAwait(false);
if (!itemFromQueue.HasValue)
{
await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken).ConfigureAwait(false);
continue;
}
// Process item here
// Remmber to clone the dequeued item if it is a custom type and you are going to mutate it.
// If success, await tx.CommitAsync();
// If failure to process, either let it run out of the Using transaction scope, or call tx.Abort();
}
}
}
Что касается комментария о клонировании элемента, удаленного из очереди, если вы хотите его изменить, просмотрите раздел «Рекомендации» здесь: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-services-надежные-коллекции/
Одним из ограничений надежных коллекций (как очереди, так и словаря) является то, что у вас есть только 1 параллелизм на раздел. Так что для очередей с высокой активностью это может быть не лучшее решение. Возможно, это проблема, с которой вы столкнулись.
Мы использовали ReliableQueues для ситуаций, когда объем записи очень мал. Для очередей с более высокой пропускной способностью, где нам нужна надежность и масштабируемость, мы используем разделы ServiceBus. Это также дает нам то преимущество, что если служба была с отслеживанием состояния только из-за наличия ReliableQueue, теперь ее можно сделать без отслеживания состояния. Хотя это добавляет зависимость от сторонней службы (в данном случае ServiceBus), и это может не подойти вам.
Другой вариант - создать надежную реализацию pub / sub, которая будет действовать как очередь. Раньше я проводил тесты с использованием акторов для этого, и это показалось мне жизнеспособным вариантом, не тратя на это слишком много времени, поскольку у нас не было никаких проблем, связанных с ServiceBus. Вот еще одна SO об этом шаблоне Pub / sub в Azure Service Fabric
person
anderso
schedule
01.03.2016
