Hazelcast (Java) 和 ETCD (golang) 的区别/相似之处？

Question

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

1. Java+Hazelcast

2. Golang+ETCD

但是在主题上下文中彼此的优缺点是什么？

Answer 1

Hazelcast 和 etcd 是两个非常不同的系统。原因是CAP定理。CAP 定理指出，任何分布式系统都不能具有一致性、可用性和分区容错性。分布式系统通常更接近 CA 或 CP。Hazelcast 是一个 AP 系统，而 etcd（作为 Raft 实现）是 CP。因此，您的选择是在一致性和可用性/性能之间。一般来说，Hazelcast 会比 Raft 和 etcd 性能更高，能够处理更多的故障，但代价是潜在的数据丢失或一致性问题。Hazelcast 的工作方式是对数据进行分区并将数据片段存储在不同的节点上。因此，在 5 个节点的集群中，键“foo”可能存储在节点 1 和 2 上，而 bar 可能存储在节点 3 和 4 上。您可以通过 Hazelcast 和 map 控制 Hazelcast 将数据复制到的节点数量配置。但是，在网络或其他故障期间，您可能会在 Hazelcast 中看到旧数据甚至丢失数据。或者，Raft 和 etcd 是一个单领导高度一致的系统，将数据存储在所有节点上。这意味着它不适合存储大量状态。但即使在网络故障期间，etcd 也可以保证您的数据保持一致。换句话说，您永远不会看到旧的/过时的数据。但这需要付出代价。CP 系统要求集群的大部分都处于活动状态才能正常运行。一致性问题可能与基本键值存储相关，也可能不相关，但它可能与锁极为相关。如果你希望你的锁是整个集群一致-这意味着只有一个节点甚至可以在网络或其他故障持有锁-千万不能使用Hazelcast。因为 Hazelcast 牺牲了一致性来支持可用性（再次参见 CAP 定理），所以网络故障完全有可能导致两个节点相信可以免费获取锁。或者，Raft 保证在网络故障期间只有一个节点将保持 etcd 集群的领导者，因此所有决策都通过该节点做出。这意味着 etcd 可以保证它始终具有一致的集群状态视图，并且可以确保像锁这样的东西只能由单个进程获取。真的，你需要考虑你在数据库中寻找什么并去寻找它。CP 和 AP 数据存储的用例大不相同。如果您希望存储少量状态、一致锁、领导选举和其他协调工具的一致性，请使用像 ZooKeeper 或 Consul 这样的 CP 系统。如果您希望以潜在的一致性代价获得高可用性和性能，请使用 Hazelcast 或 Cassandra 或 Riak。