CASSANDRA-5062でCAS (Compare and Swap) を入れようという話になっているらしく、一体どんなすごいアトミックブロードキャストを使うのか気になっていた。どういうことなのだろうとスレッドをナナメ読みしてみたのだが…議論の流れとしては
- カウンターだけじゃなくてCASほしいよねAPIとして
- ZooKeeperのロック使うのがシンプルでいんじゃね？
- いやいやサーバーの種類増やすとかあり得ないし
- 基本方針は、コーディネーターみたいなのをレプリカセット毎に決めてそこから Chain Replication ぽく
- コーディネーターどうやって決める
- やっぱPaxosじゃね？
- 再実装ヤダよZAB使おうよZKの実装あるよ
- （なんかプロトコル上の理由があって）やっぱPaxos実装するしかないか…
となって、結局 Jonathan Ellis が Paxos を素で実装してしまった模様。 Thrift APIも無事に cas というのが増えて非常にわかりやすい感じではある。分かったことは、テキストベースで非同期通信の議論なんてするもんじゃないということだ。まして英語なので大変辛く結局ポイントを抑えられていない。だれか有識者に補足していただきたいところ。
個人的にはPaxosの実装って大変だと思うのだが、1ヶ月でサクッとできてしまったりするものなんだろうかというところ。まあテストはこれからなんだろうけども。あとはCoordinatorが落ちた瞬間ちょっとCASできなくなるところかな。性能を求めてるわけじゃないから…とは書いてあったけど、じゃあ何のためにCASにするんだろう。そこだけはどうしても分からなくて、便利だからというだけの理由でこの類の難しい機能を入れたら大変なことになる予感しかしなくて心配している。
追記
そういえばふと心配になって、PaxosベースでCoordinatorを決めるとして、その故障検知がPhi Failure Detectorで動いていたら大丈夫なのかなと思って調べたら相変わらずΦ故障検知だったので安心した。
- About failure detection and recovery
- ArchitectureInternalsのFailure Detectionのところ
- ソースの流れ
改めてソースのファイル名だけを見ていると故障検知に関係ありそうなファイルはない。故障検知まわりがノータッチだと仮定するとちょっと怖いことになる。FUDだったらすみません。
故障検知をトリガーにして次のPaxosによるLeader Electionが動き出すのだとすると、たとえばCoordinatorが過負荷とか瞬断で見えてない瞬間があって、たまたまFollowerの故障検知が短かったときに（Φ故障検知だと起こりうる）Coordinatorさんは自分がまだCoordinatorだと思っている瞬間にリクエストを処理してしまい、FollowerはFollowerでPaxosで次のCoordinatorを選出してしまっていると、それぞれのサーバーで別のCASが同時に走ってしまう気がする。Lease Timeをちゃんと設計していれば大丈夫なのだけど... 有識者とかスレッドを全部読んだ偉い人教えてください。
