What are the differences / similarities between hazelcast (Java) and etcd (golang)?

Now we build a real-time analysis system, which should be highly distributed We plan to use distributed locks and counters to ensure data consistency. We need a distributed mapping to know which client is connected to which server

> Java Hazelcast > Golang ETCD

But what are the pros and cons of each other in the context of the theme?

Solution

Hazelcast and etcd are two distinct systems The reason is cap theory

Cap theorem points out that no distributed system can have consistency, availability and partition tolerance Distributed systems are usually closer to Ca or CP. hazelcast is an AP system, while etcd (a raft Implementation) is CP. therefore, your choice is between consistency and availability / performance

Generally speaking, hazelcast has higher performance and can handle more faults than raft and etcd, but at the cost of potential data loss or consistency problems Hazelcast works by splitting data and storing it on different nodes Therefore, in a 5-node cluster, the key "foo" can be stored on nodes 1 and 2, and the bar can be stored on nodes 3 and 4 You can control the number of nodes and mapping configuration that hazelcast copies data through hazelcast However, during network or other failures, you may see old data or even lost data in hazelcast

Alternatively, raft and etcd are a single leader highly consistent system that can store data on all nodes This means that it is not suitable for storing a large number of states But etcd can keep your data consistent even during network failure In other words, you will never see old / stale data But it comes at a price The CP system requires most of the cluster to be active for normal operation

Consistency problems may or may not be related to basic key value storage, but they are very related to locking If you want locking to be consistent throughout the cluster – which means that only one node can remain locked even during network or other failures – do not use hazelcast Because hazelcast sacrifices consistency to support availability (see cap theorem again), network failure may cause two nodes to believe that they can freely obtain locks

Alternatively, raft guarantees that only one node is still the leader of etcd cluster during network failure, so all decisions are made through this node This means that etcd can ensure that it always has a consistent view of cluster state, and can ensure that lock like content can only be obtained through a single process

Really, you need to think about what you're looking for in the database, and then look for it The use cases of CP and AP data storage are very different If you want to store a small amount of consistency of status, consistency locking, leader election and other coordination tools, please use CP systems such as zookeeper or consult If you want high availability and performance at the possible cost of consistency, use hazelcast or Cassandra or riak

Source: I am the author of a raft implementation