Использование resque для реализации шаблона команды - PullRequest
Новая
       11

Использование resque для реализации шаблона команды

1 голос
/ 13 января 2011

Я работаю над многопользовательским приложением для редактирования дерева. Он использует Resque Gem для фоновых процессов. Чтобы избежать многопользовательских конфликтов во время выполнения, я хочу использовать шаблон команды и сохранять действия пользователя в очереди восстановления, поэтому, если кто-то удаляет ветку, другой пользователь не может редактировать дочерние элементы этой ветви.

Работает, но довольно медленно выбирает задание в первый раз из очереди, потому что работник resque проверяет задания с интервалом в 5 секунд. Это значительно замедляет редактирование интерфейса. Возможно сделать что-то вроде этого: 

    cmd = MyCommand.create!(:attr1 => 'foo', :attr2 => 'bar')
    Resque.enqueue(MyCommand, cmd.id)
    workers = Resque.workers.select {|w| w.queues.include?('my_queue') }
    raise "Should be only one queue for commands!" if workers.size != 1
    not_done = true
    while not_done
      not_done = workers[0].process
    end

Он делает то, что мне нужно, но мне интересно, есть ли более элегантный способ сделать это. Кроме того:: process является устаревшим методом для экземпляров Worker.

1 Ответ

2 голосов
/ 14 января 2011

Я думаю, что ваш подход к дизайну несколько здравый, но Redis / Resque может не подходить. Вам нужна супербыстрая очередь в памяти, похожая на Resque, но не сопровождающаяся задержкой опроса.

Я почти уверен, что вы можете использовать MemCached для этого, но могут быть и другие варианты. Любое решение, когда ваши команды в очереди должны обрабатываться с определенным интервалом, вероятно, не обеспечит приемлемой производительности для совместного редактирования, если не разрешено опрашивать, возможно, каждые 100 мс или даже чаще.

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

Во всяком случае ... удачи, звучит как нетривиальная задача для решения.

...