1

大規模分散セルオートマトンを使用したシミュレーションの開発に取り組んでいます。セル シミュレーションはノード全体に分散され、ZooKeeper を使用して調整されます。永続データは Riak に保存されます。セルオートマトン自体は Python で書かれています。

セルが少量 (たとえば、毎秒数から数十の間) のメッセージ (おそらくキーと値のペア) をすぐ隣のセル (マンハッタンの近隣) に渡すことができれば、私のシミュレーションにとって非常に便利です。ただし、数百万のセルのシミュレーションの場合、単純なアプローチでは、各セルに 1 つずつ、数百万の小さなメールボックスがあり、各ボックスにゆっくりとメッセージが細流します。これにより、ZooKeeper や RabbitMQ は屈服します。私は DDSを勧められましたが、それは非常にエンタープライズ向けのようで、見つけることができる Python バインディングはありません。

私は分散システム開発の初心者です。これは、私がどこまで到達できるかを確認するための単なる趣味のプロジェクトです。私はこれを間違った方法で行っていると感じずにはいられません。小さなセルのメールボックスごとにモノリシックなメッセージ バスを使用しています。セルが隣接するセルとその世界における位置を判断するのは簡単なので、メッセージの受け渡しは何らかのチャンクの影響を受けやすいように思われます。しかし、この地域アクターの設計と、それが個々の細胞とどのように通信するかについては、私にはわかりません。セルがメッセージ バスを介してチャンクにメッセージを渡す方法はわかりましたが、チャンクはどのようにメッセージをセルに戻すのでしょうか?

この問題の真の解決策に近いところまで進んでいますか? 分散ノードが少量のメッセージを近隣ノードに渡す適切な方法は何ですか?

4

2 に答える 2

1

これらのメッセージがどれだけ持続する必要があるかはわかりません。あなたの説明によれば、異なるセルからのメッセージに対して順序付けの制約があるようには見えません。同じセル a から同じセル b に送信されるすべてのメッセージの完全な順序付けが必要だと思います。

ZooKeeper は、すべてのメッセージに対してグローバルな合計順序を提供するため、処理が滞ります。システムが Zookeeper を介してどのような種類の調整を必要としているかは正確にはわかりませんが、きめの細かい調整よりも粒度の粗い調整が最も効果的です。(私が働いているところでは、この意図を明確にするために、それぞれロールロックとリソースロックと呼んでいます。リソースをロックするのではなく、ワーカーがロールを引き受けます。)

そこで、私が持っている情報を基にいくつかのアイデアを紹介します。

メッセージが永続的である必要がない場合、最善の方法は、隣人との接続を維持し、メッセージを直接送信することです。私は 2D または 3D を想定しているので、(マンハッタン) 近隣の数は少ないです。

この残りの部分では、耐久性が必要であると仮定します。

単一のメッセージ キュー システムで数百万のメッセージを処理できる必要があります。ただし、ある程度分割するとパフォーマンスが向上します。

まず、すべてのメッセージを同じキューに送信してみてください。いくつかのワーカー (ZooKeeper によって選択された) がメッセージをキューからプルし、宛先セルに送信します (キューに ack する前にセルから ack を要求します)。一連のワーカーがセルからメッセージを受信して​​キューに入れることもできます。基本的に、これはキューの競合を助けています。

[  Router ]--->[ Queue ]--->[  Router  ]
 ^   ^   ^                   |   |   |
 |   |   |                   V   V   V
[A] [B] [C]                 [D] [E] [F]

これを少し一般化して、リージョンごとにキューを持つことができます。(処理するメッセージが少ないほど、キューは適切に機能します。) リージョンごとに 1 つ以上のルーターを用意します。

        ,----->[ QueueA ]<------.
        |                       |   (Note which arrows are bi-directional)
        V                       |
[ RouterA ]--->[ QueueB ]<--->[ RouterB ]
 ^   ^   ^                     ^   ^   ^
 |   |   |                     |   |   |
 V   V   V                     V   V   V
[A] [B] [C]                   [D] [E] [F]

メッセージング システムがまだ混雑している場合は、上の図のキューをメッセージ キューシステム全体に置き換えることができます。

これらは、うまくいけばあなたを良い方向に向けるための、実際のドメインを知らないいくつかの単純なアイデアです.

ところで、Twitter のアーキテクチャ (過去と現在) を調査することをお勧めします。なぜなら、Twitter には基本的に何百万ものメールボックスがあり、各セル オートマトン (人) ごとに 1 つずつあるからです。

于 2013-03-16T06:04:00.343 に答える
0

私がいじっている1つのアイデア：

内部システムの DNS に代わるものとして ZooKeeper を使用している人々のいくつかの場所を読みました。シミュレーション ワーカー プロセスは、セル シミュレーションを担当する ZooKeeper に既に登録されているため、応答する IP とポートを登録し、ZeroMQ を使用してセル間の P2P メッセージ パッシングを設定するのはそれほど遠くないと思います。これはまだラフスケッチです。

于 2013-03-17T21:37:49.030 に答える