【问题标题】:How Cassandra ensures high availability?Cassandra 如何确保高可用性?
【发布时间】:2015-05-24 01:34:08
【问题描述】:

我想了解 Cassandra 如何确保高可用性。我所知道的是,当我们向 Cassandra 数据库查询数据时,一个名为 coordinator 的节点会将查询路由到集群中具有所需数据的适当 Cassandra 节点。 但是,如果我们在 JDBC 连接 URL 中指定的节点(我认为它将充当集群中的协调器,如果我错了,请纠正我)自己崩溃了怎么办? 在这种情况下,Cassandra 是如何确保高可用性的?

也许我们作为开发人员必须为此提供回退机制?

【问题讨论】:

    标签: jdbc cassandra fallback


    【解决方案1】:

    在 Cassandra 集群中,所有节点都是平等的。集群级别没有主节点或协调节点。当你连接到一个集群时,你通常会指定一个或多个节点来连接,但是一旦驱动程序连接了它就可以找到其他节点。这意味着如果它连接的第一个节点出现故障,它会知道其他节点并可以连接到其中一个节点。

    如果将查询发送到本身不承载请求数据的节点(或指定的一致性级别高于一个),则该节点充当查询的协调者,但这是一个临时角色,并且任何节点可以为任何查询担任该角色。

    甚至有驱动程序,例如 Astyanax,连接到多个节点并尝试找出哪个节点包含请求的数据并使用与该节点的连接来执行查询,以最大限度地减少查询时间。

    【讨论】:

    • 感谢您的帮助。但是 Astyanax 似乎是围绕 cassandra 的更高级别的包装器。我想使用纯 JDBC 连接与 cassandra 进行交互。那会是什么情况?
    • Cassandra JDBC 客户端 (code.google.com/a/apache-extras.org/p/cassandra-jdbc) 不如 Astyanax 或 Hector 或 Pelops 等其他中级驱动程序先进,所以我猜你在自动重新连接方面不走运。但是,如果您的应用程序知道集群中的一些节点,它可以尝试依次连接到它们,直到找到一个已启动的节点。由于没有一个节点是特殊的,所以它最终连接到哪个节点并不重要。
    猜你喜欢
    • 2020-12-13
    • 2013-09-12
    • 2018-06-11
    • 1970-01-01
    • 2014-03-30
    • 1970-01-01
    • 1970-01-01
    • 2014-05-15
    • 2012-02-02
    相关资源
    最近更新 更多