3

etcdの調査を始めたばかりで、作成者による講演で言及されているユース ケースの 1 つは、ワーク キュー システムです。

しかし、実際にこれをどのように実装しますか?

基本的なパターンはこのようなものになります。

1 プロセスで「作業内容チケット」を生成し、そのチケットを etcd のフォルダーに配置すると、「/queue/worktickets/00000000001/」と言うことができます

1->「/queue/worktickets/」フォルダーの変更をリッスンする多くのプロセス。新しいワーク チケットが表示されると、すべてのプロセスは「/queue/locks/00000001」に新しい値を作成してそのチケットをロックすることにより、チケットを取得しようとします。最初のものだけがロック値を作成できます。

ロック チケットを作成したプロセスが機能し、キューからチケットを削除し、場合によってはロック値も削除します。次に、キューから次に利用可能なチケットを取得しようとします。使用可能なチケットがなくなった場合は、「/queue/worktickets/」フォルダー内の変更のリッスンを再度開始します。

私の頭の中では、これを実装するのはかなり簡単なはずですが、キューが大きくなると (チケットは生成するのは簡単ですが、処理するのは難しいです)、大量のデータが etcd から各クライアントに転送されるようです。私の知る限り、このフォルダーに存在しない最初の値をこのフォルダーに教えてくださいと言う方法はありません。また、フォルダーの上位 n 項目を教えてくれるものもあります。

誰もがこれについての考えを共有したいと思っています。

4

2 に答える 2

0

あなたはすでにこの問題を解決していると思いますが、私が行う方法は、ワーク キュー ディレクトリの内容を一覧表示することです (これは、とにかくディレクトリをフェッチしたときに得られるものです)。次に、ロックを取得するまで、ロックディレクトリに同じ名前のロックを作成しようとして、リストを下っていきます。「prevExist=false」フラグを使用する場合、ロック「ファイル」の作成はアトミックであるため、作成に成功した場合、そのアイテムをロックしたのはあなたです。

理想的には、アイテムの処理にかかる時間を大まかに見積もって、TTL をそれよりも少し長く設定します (または、見積もれる時間があるステップの後に定期的に TTL を更新します)。完了したら、元のキューからアイテムを削除するか (「完了」ディレクトリに再作成することもできます)、またはロックの有効期限が切れて他の誰かがそれを取得します。

また、理想的には、一意の「ノード識別子」(ホスト名など) をロック ファイルに入れると、TTL 更新で比較と設定が行われますが、時間がかかりすぎてロックを失った場合は失敗します。

作業ディレクトリには、ディレクトリで POST を使用して順次作成された項目があり、ロック キューと完了したディレクトリには、PUT を使用して名前で作成された項目が含まれていると考えられます。

于 2016-03-23T21:09:47.063 に答える