Hazelcast（Java）和ETCD（golang）的区别/相似之处？

java go distributed hazelcast etcd

2022-09-03 03:32:10

现在我们构建一个实时分析系统，它应该是高度分布式的。我们计划使用分布式锁和计数器来确保数据一致性，并且我们需要某种分布式映射来了解哪个客户端连接到哪个服务器。我以前没有分布式系统的经验，但我认为我们有两个选择：

Java+Hazelcast
Golang+ETCD

但是，在主题上下文中，彼此的利弊是什么？

答案 1

Hazelcast和etcd是两个非常不同的系统。原因是CAP定理。

CAP 定理指出，没有分布式系统可以具有一致性、可用性和分区容错性。分布式系统通常更接近CA或CP.Hazelcast是一个AP系统，etcd（作为Raft实现）是CP。因此，您可以选择一致性和可用性/性能。

一般来说，Hazelcast的性能要高得多，并且能够处理比Raft和etcd更多的故障，但代价是潜在的数据丢失或一致性问题。Hazelcast的工作方式是它对数据进行分区，并将数据片段存储在不同的节点上。因此，在 5 节点集群中，密钥“foo”可以存储在节点 1 和 2 上，bar 可以存储在节点 3 和 4 上。您可以通过 Hazelcast 和映射配置控制 Hazelcast 将数据复制到的节点数。但是，在网络或其他故障期间，存在一些风险，即您会在Hazelcast中看到旧数据甚至丢失数据。

或者，Raft和etcd是一个单一领导者的高度一致性系统，将所有数据存储在所有节点上。这意味着它不适合存储大量状态。但即使在网络故障期间，etcd也可以保证您的数据将保持一致。换句话说，您永远不会看到旧/陈旧数据。但这是有代价的。CP 系统要求群集的大部分处于活动状态才能正常运行。

一致性问题可能与基本键值存储相关，也可能不相关，但它可能与锁非常相关。如果您希望锁在整个群集中保持一致 - 这意味着即使在网络或其他故障期间也只有一个节点可以持有锁 - 请不要使用 Hazelcast。由于 Hazelcast 牺牲了一致性而牺牲了可用性（再次，参见 CAP 定理），因此网络故障完全有可能导致两个节点认为可以自由获取锁。

或者，Raft保证在网络故障期间只有一个节点将保持etcd集群的领导者，因此所有决策都是通过该节点做出的。这意味着 etcd 可以保证它始终具有一致的集群状态视图，并且可以确保像锁这样的东西只能由单个进程获得。

真的，你需要考虑你在数据库中寻找什么，然后去寻找它。CP 和 AP 数据存储的用例大不相同。如果您希望在存储少量状态、一致锁、领导者选举和其他协调工具时保持一致性，请使用 ZooKeeper 或 Consul 等 CP 系统。如果您希望以潜在的一致性为代价获得高可用性和性能，请使用 Hazelcast 或 Cassandra 或 Riak。

来源：我是 Raft 实现的作者

答案 2

虽然这个问题现在已经超过3年了，但我想告诉后续读者，Hazelcast从3.12开始有一个基于CP的子系统（基于Raft）用于其原子和并发API。计划在不久的将来将CP推广到更多的Hazelcast数据结构。让Hazelcast用户在AP和CP问题之间做出真正的选择，并允许用户将Hazelcast应用于以前由etcd和Zookeeper等系统处理的新用例。