2011-01-13 100 views
1

我正在開發一個多用戶樹編輯應用程序。它使用resque gem作爲後臺進程。爲了避免運行時多用戶衝突,我想使用命令模式並將用戶操作存儲在resque隊列中,因此如果有人正在刪除分支,則其他用戶無法編輯該分支的子級。使用resque實現命令模式

它可以工作,但是第一次從隊列中選擇作業的速度非常慢,因爲resque worker會使用5秒的時間間隔檢查作業。它顯着降低了編輯界面的速度。這是possibe做這樣的事情:

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 

它做什麼,我需要,但我不知道是否有這樣做的更優雅的方式。另外,對於Worker實例,process是已棄用的方法。

回答

2

我認爲你的設計方法有點合理,但Redis/Resque可能不合適。你想要的是一個類似於Resque的超快速內存隊列,但是這不會帶來輪詢延遲。

我很肯定你可以使用MemCached,但也有其他選擇。任何排隊的命令必須以特定間隔拉的任何解決方案可能不會提供可接受的協作編輯性能,除非可以每隔100毫秒或甚至更頻繁地輪詢。最後,如果您將每個操作放在一個只能連續處理命令的單個隊列上(一次一個),那麼您將不可避免地發生隊列可能被備份的情況,因爲過多的命令即將到來進來,而且他們處理得並不快。這就是爲什麼更具擴展性的解決方案可能使用版本控制,樹的每個元素都是版本控制的,當更新/更改時,所有子元素都會使用新版本進行更新。這樣,舊版本號的編輯就會被拒絕。

無論如何..祝你好運,聽起來像一個不平凡的問題來解決。

+0

令我印象深刻的是resque/redis速度,並且不介意圖形用戶界面的延時低於10-20毫秒。 Resque還允許爲開箱即用的特定任務使用單獨的處理器。所以現在我沒有看到切換到memcached或inmemory解決方案的強有力的理由 – dimus 2011-02-03 14:56:07