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

一般而言,Hazelcast性能更高,能够处理比Raft和etcd更多的故障,但代价是潜在的数据丢失或一致性问题. Hazelcast的工作方式是分割数据并将数据存储在不同的节点上.因此,在5节点集群中,密钥“foo”可以存储在节点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的作者