2011-01-13 11 views
1

私はマルチユーザツリー編集アプリケーションを開発中です。バックグラウンドプロセスにresque gemを使用します。ランタイムのマルチユーザーの競合を避けるために、私はコマンドパターンを使用してユーザーのアクションをresqueキューに保存したいので、他のユーザーがブランチを削除している場合、そのブランチの子を編集することはできません。コマンドパターンを実装するためのresqueの使用

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インスタンスの非推奨メソッドです。

答えて

2

私はあなたのデザインアプローチはやや妥当だと思いますが、Redis/Resqueは適切ではないかもしれません。あなたが望むのは、Resqueと似ている超高速インメモリキューですが、ポーリングの遅延はありません。

私はかなりMemCachedを使うことができると確信していますが、他のオプションもあります。キューに入れられたコマンドを特定の間隔で取得しなければならないソリューションは、おそらく100msまたはそれ以上の頻度でポーリングすることができない限り、おそらく共同編集にとって許容できるパフォーマンスを提供しません。

最後に、コマンドを連続して(一度に1つずつ)処理できる単一のキューにすべてのアクションを配置すると、コマンドが多すぎるためにキューがバックアップされることが必然的に起こりますそして、彼らは速く処理していません。これは、ツリーの各要素がバージョン管理され、更新/変更されたときに、すべての子要素が新しいバージョンでも更新されるような、バージョニングを使用することにより、よりスケーラブルなソリューションが得られる理由です。そうすれば、古いバージョン番号の編集は拒否されます。

とにかく..幸運は、解決するために重要ではない問題のように聞こえる。

+0

私はrealtime/redisの速度に感心しています。GUIのレイテンシが10-20ミリ秒以下であれば気にしません。 Resqueはまた、ボックス外の特定のタスクに別のプロセッサを利用することを可能にする。だから、今私はmemcachedまたはメモリ内のソリューションに切り替える強い理由は見当たらない – dimus

関連する問題