Hazelcast（Java）和ETCD（golang）的差异/相似之处？

Question

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

1. 爪哇+ Hazelcast

2. Golang + ETCD

但是在主题背景下彼此的利弊是什么？

Answer 1

Hazelcast和etcd是两个截然不同的系统。原因是CAP theorem。

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

一般而言，Hazelcast性能更高，能够处理比Raft和etcd更多的故障，但代价是潜在的数据丢失或一致性问题。 Hazelcast的工作方式是分割数据并将数据存储在不同的节点上。因此，在5节点集群中，密钥＆＃34; foo＆＃34;可以存储在节点1和2上，并且条可以存储在节点3和4上。您可以控制Hazelcast通过Hazelcast和映射配置复制数据的节点数。但是，在网络或其他故障期间，您可能会在Hazelcast中看到旧数据甚至丢失数据。

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

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

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

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

来源：我是a Raft implementation

的作者

Answer 2

尽管这个问题已有3年之久了，但我想通知后续的读者，Hazelcast从3.12版本开始就为其Atomics和Concurrency API提供了一个基于CP的子系统（基于Raft）。计划在不久的将来将CP推广到更多的Hazelcast数据结构中。让Hazelcast用户在AP和CP问题之间真正选择，并允许用户将Hazelcast应用于先前由etcd和Zookeeper等系统处理的新用例。

您可以在这里阅读更多内容...

https://hazelcast.com/blog/hazelcast-imdg-3-12-beta-is-released/