Naoki Kurosawa
naoki_kuros****@ybb*****
2003年 3月 28日 (金) 01:26:53 JST
黒澤です。 対戦実行単位の変更、やっちゃえと思ってやり始めて気がついたんですけど、 総当たり戦をやるということは、巨大なdivisionを1つ作ってすべての ロボットを1つのdivisionで実行するということじゃないですか。 とすると、対戦実行単位をdivisionごとにすると、 1つのマシンで全対戦をやらなきゃならなくなっちゃいません？ なぜ対戦実行単位をdivisionごとにしようとしているかというと、 通信回数を減らすことも理由の一つですが、 もう一つはロボットが作成したデータを中央サーバと分散サーバで やり取りするためです。 ロボットが作成したデータを分散環境できちんと維持するということは、 あたかも1台のマシンで実行したかのごとくデータが維持されるということです。 つまり、あるロボットが絡む対戦を複数のサーバが同時に実行することのない ように制限します(以下、対戦制限と呼びます)。 でないと、複数のサーバから同時に上がってくるデータのどれを有効にする かを選べないからです。 で、対戦制限はどうやるか、ということで、 対戦実行単位をdivisionごとにすればいいじゃん、となります。 総当たり戦をやりたい、対戦実行単位をdivision単位にするのはいや、 となると、対戦制限の方法を考え直す必要があります。 一つ考えられるのは、 あるリーグのあるシーズンのあるロボットを表すテーブルであるseason_robots に、ロック用のフィールドを設けて、 ある分散サーバが対戦を1つ実行しようとしたら、 その対戦に絡むロボット2台をロックします。 他の分散サーバは、対戦を実行する際はロックがかかっているロボットが絡む 対戦は実行しないようにする、というやり方で、対戦制限を行います。 ただ、ロックがかかっていないロボットのバトルを抽出するSQLクエリは 結構時間がかかることが予想されるので、まともなスループットを維持する には、同時実行がしやすい順にバトルを並べておくなどの措置が必要になり、 かなりよく考えないといけなくなります。 それと、対戦実行単位が1対戦ごとになるので、スループット担保も 厳しくなります。 なんかうまい方法ありますかねぇ。 -- Naoki Kurosawa <naoki_kuros****@ybb*****>
