【问题标题】:Cassandra as Distributed LockCassandra 作为分布式锁
【发布时间】:2017-07-16 16:28:46
【问题描述】:

我正在尝试评估分布式锁定的各种选项。我入围的几个选项是 Zookeeper、MySQL 和 Cassandra。

对于 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 是用于分布式锁定的吗?如果尝试获取此锁的并发线程数超过,它可以扩展吗?

期待专家的意见。提前致谢。

【问题讨论】:

标签: cassandra locking


【解决方案1】:

Cassandra 从CAP Theorem 中选择 AP,这意味着在 Cassandra 中,可用性和分区容错性通常被认为比一致性更重要。 Cassandra 提供最终的一致性。

Cassandra 不提供锁定机制。您正在使用IF NOT EXISTS,这是一个轻量级事务。

轻量级交易(IF 子句)

虽然具有最终/可调一致性的持久事务对于许多用例来说非常令人满意,但确实会出现需要更多的情况。使用可线性化一致性的轻量级事务,也称为比较和设置,可能可以满足这些需求。

Cassandra 在提出轻量级事务的节点和集群中任何需要的副本之间进行四次往返,以确保正确执行,从而影响性能。

这听起来成本很高——也许太高了。这就是 Cassandra 给你超时异常的原因。因此,为绝对必要的情况保留轻量级事务

来源: 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

【讨论】:

    猜你喜欢
    • 2014-12-26
    • 1970-01-01
    • 2022-01-17
    • 1970-01-01
    • 2015-08-26
    • 2022-05-13
    • 2018-09-27
    • 2021-11-05
    • 2010-11-06
    相关资源
    最近更新 更多