Как поддерживать состояние или очередь запросов в Web API

Это очень хороший сценарий, чтобы использовать MSMQ. Для каждого запроса просто отправьте элемент в очередь MSMQ. Либо в том же веб-приложении, либо в любом другом приложении просто прочитайте несколько элементов из очереди и опубликуйте их в solr. Независимо от сбоя вашего приложения или его рециркуляции, MSMQ будет безопасно хранить ваши данные, чтобы получить их позже.

MSMQ является надежным, надежным и масштабируемым. Это идеально подходит для вашей проблемы.

вы можете запрашивать запросы в очередь в памяти, и вы можете периодически отправлять их в базу данных с использованием Quartz .Сеть. Вы можете просто сделать это в Global.асакс.CS следующим образом:

public class RequestQueue
{
    private readonly Queue<HttpRequest> _requestHistory; 
    private RequestQueue()
    {
        _requestHistory = new Queue<HttpRequest>();
    }
    private static RequestQueue _singleton;

    public static RequestQueue Instance()
    {
        if (_singleton == null)
            _singleton = new RequestQueue();
        return _singleton;
    }

    public void Enqueue(HttpRequest request)
    {
        _requestHistory.Enqueue(request);
    }

    public void Flush()
    {
        while (_requestHistory.Count > 0)
        {
            var request = _requestHistory.Dequeue();
            try
            {
                //Write request To Db
            }
            catch (Exception)
            {
                _requestHistory.Enqueue(request);
            }
        }
    }
}

public class WebApiApplication : System.Web.HttpApplication
{
    public WebApiApplication()
    {
        base.BeginRequest += delegate
            {
                RequestQueue.Instance().Enqueue(HttpContext.Current.Request);
            };
    }

    private void InitializeQuartz()
    {
        ISchedulerFactory sf = new StdSchedulerFactory();
        IScheduler sched = sf.GetScheduler();

        DateTimeOffset runTime = DateBuilder.EvenMinuteDate(DateTime.UtcNow);
        DateTimeOffset startTime = DateBuilder.NextGivenSecondDate(null, 5);

        IJobDetail job = JobBuilder.Create<QueueConsumer>()
            .WithIdentity("job1", "group1")
            .Build();
        ITrigger trigger = TriggerBuilder.Create()
            .WithIdentity("trigger1", "group1")
            .StartAt(runTime)
            .WithCronSchedule("5 0/1 * * * ?")
            .Build();

        sched.ScheduleJob(job, trigger);

        sched.Start();
    }

    public class QueueConsumer : IJob
    {
        public void Execute(IJobExecutionContext context)
        {
            RequestQueue.Instance().Flush();
        }
    }

    protected void Application_Start()
    {
        InitializeQuartz();

другое решение может содержать записи в очереди памяти, которая не находится в том же процессе, что и WebApi. Например: MemcacheQueue https://github.com/coderrr/memcache_queue

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

вы должны попытаться реализовать NServiceBus есть возможность планировать сообщения и отправлять сообщения в будущем, из документации служебной шины вы можете возможность планирования вы можете запланировать задачу или действие/лямбда, которые будут выполняться повторно в заданном интервале.

это означает, что вы можете иметь кэш memeory и записывать содержимое массива в свой solr/lucene impl каждые 10 минут, например, это что-то проще as:

Schedule.Every(TimeSpan.FromMinutes(10)).Action(() => { < task to be executed > })

в случае, если вам понадобится больше гибкости для установки schedueler, вы можете интегрировать его quartz.net

случай должен быть следующим:

• WCF как служба windows и NServiceBus должны иметь один и тот же контекст или реализовать cacheManager, который может быть разделен между этими двумя различными частями вашей системы.
• каждый раз, когда вы делаете запрос, вы вызываете свой wcf передать параметры и whitin ваш wcf вы добавляете в строка памяти в массив (это может быть строковый массив с тем же значением json, которое вы записываете на диск)

• ServiceBus будет обрабатывать очереди для операций в массиве и избегать любых конфликтов для операций массива, например:

  • добавить элементы в массив
  • пустой массив
  • запись в базу данных

public class ThresholdBuffer<T>
{
    private ConcurrentBag<T> _buffer;

    private int _threshold;

    public ThresholdBuffer(int threshold)
    {
        _threshold = threshold;
        _buffer = new ConcurrentBag<T>();
    }

    public void Add(T item)
    {
        _buffer.Add(item);

        if(_buffer.Count >= _threshold)
        {
            Recycle();
        }
    }

    public void Recycle()
    {
        var value = Interlocked.Exchange<ConcurrentBag<T>>(ref _buffer, new ConcurrentBag<T>());
//flush value 
    }
}

1. создать логику промывки
2. At Application_Start (Глобальный.asax) событие создать ThresholdBuffer и храните его в приложении, статическом поле и т. д.
3. вызов метода Add
4. при ручном вызове Application_End Recycle

вы можете добавить логику блокировки в Recycle, чтобы предотвратить создание нескольких ConcurrentBag и промывку почти пустого мешка. Но, по моему мнению, это менее зло, чем замок.

обновление. Замок бесплатно без aditional ConcurrentBag creation

public class ThresholdBuffer<T>
{
    private ConcurrentBag<T> _buffer;

    private int _copacity;

    private int _threshold;

    public ThresholdBuffer(int threshold)
    {
        _threshold = threshold;
        _copacity = 0;
        _buffer = new ConcurrentBag<T>();
    }

    public void Add(T item)
    {
        _buffer.Add(item);
        if (Interlocked.Increment(ref _copacity) == _threshold)
        {
            Recycle();
        }
    }

    public void Recycle()
    {
        var value4flasshing = Interlocked.Exchange<ConcurrentBag<T>>(ref _buffer, new ConcurrentBag<T>());
        Thread.VolatileWrite(ref _copacity, 0);
    }
}

ps Вы можете использовать любой ConcurrentCollection вместо ConcurrentBag