分散ロックとしてのCassandra

Question

分散ロックのさまざまなオプションを評価しようとしています。私が選んだオプションのいくつかは、Zookeeper、MySQL、Cassandraです。カサンドラで

、私が考えていたことは、テーブルを作成して、以下のようなクエリを存在しない場合、ロック

create table if not exists app.locks (
    key text, 
    primary KEY (key) 
); 

が続いacquireLockプロセスの一環として、私は挿入を実行することができると言います。 acquireLock insertはtrueを返す場合にのみプロセスを返します。他のスレッドがしようとすると、それを取得できるように、ロックを解除

INSERT INTO app.locks (key) VALUES ('KEY_1') IF NOT EXISTS; 

は、このキーのデータを削除することができます。

私が選んだすべてのオプションでいくつかのパフォーマンステストを行っていました。その結果、ZookeeperとMySQLは、Cassandraの結果がかなり矛盾していて、すべてのテストでエラーがほとんどないことを示すエラーは表示されません。ほとんどの時代のエラーは "でした。一貫性で書込み問合せ中のCassandraタイムアウトQUORUM"

質問ここでは、Cassandraは分散ロックの意味ですか？このロックを取得しようとしている同時スレッドの数が超過した場合、スケールできますか？

エキスパートからの思いを楽しみにしています。前もって感謝します。

Answer 1

カサンドラはAPSA CAPから定理を選択しています。つまり、カサンドラの一貫性よりも可用性とパーティションの許容差が一般に重要であると考えられます。カッサンドラは最終的な一貫性を提供します。

カッサンドラはロック機構を提供していません。軽量トランザクションであるIF NOT EXISTSを使用しています。

軽量取引（箇条IF）

最終的な/調整可能な一貫性と耐久性のある取引は多くのユースケースのために非常に満足ですがそれ以上が必要とされる場合には、状況が発生します。線形化可能な整合性を使用する軽量トランザクション（比較および集合とも呼ばれます）は、おそらくそれらのニーズを満たすことができます。

Cassandraは、軽量トランザクションを提案するノードと適切な実行を保証するためにクラスタ内の必要なレプリカ間を4回往復させ、パフォーマンスに影響を与えます。

高コスト、おそらく高すぎるように聞こえること。だからこそカサンドラはあなたにタイムアウトの例外を与えています。その結果、彼らは絶対に必要であるこれらの状況のた​​めの軽量の取引を確保

出典： http://www.datastax.com/documentation/cassandra/2.0/cassandra/dml/dml_ltwt_transaction_c.html https://www.datastax.com/dev/blog/lightweight-transactions-in-cassandra-2-0