我想知道 Chronicle Map 中的原子性语义。如果我有一个跨 2 个节点（服务器）共享的编年史地图，并且我尝试在两个节点上同时将相同的密钥插入到该地图中，那么事务语义是什么？
第一次put成功，第二次失败吗？
我很好奇 Chronicle Map 是否保证与 Apache Zookeeper 相同的事务语义？
在我的用例中，我想依靠这样一个事实，即如果 node1 将密钥 K1 放入映射中，则 node2 将能够检查 K1 的存在，如果它不存在，它将明确知道它是第一个添加K1。
实际上，询问 ChronicleMap 上的 put 是否是跨 2 个节点的分布式事务。
非常感谢克利福德
Chronicle Map 使用最终一致性，最后一个获胜。当您查看微秒时间尺度时，节点处于裂脑节点中，因为无法以这种速度保持它们同步。这是设计使然，因为 Map 旨在支持每台服务器每秒数百万次更新。一般来说，保证两台服务器在正常运行时不会同时更新同一个key并不难。例如，您可以使用 Engine 将所有更新传递到一台服务器，或者您可以对密钥进行分区以进行更新。虽然分布式事务听起来是个好主意，但您应该注意；- 它们的速度要慢许多数量级， - 当你遇到像裂脑这样的失败时，很难恢复。- 在不同的故障条件下测试您的应用程序是否正常工作是一件非常痛苦的事情。
我认为我们最好设计一个不需要这种假设的系统，并且您将知道它在失败时的行为，而无需进行广泛的测试。
假设您将 zookeeper 安装到三个数据中心，并通过确保没有数据中心有一半或更多节点（两个数据中心不够）来确保一个数据中心的故障不会停止运行，但是说您有暂时的脑裂是由缓慢的互连，这会影响任何更新，但会以难以复制或测试的方式暂时发生。使用编年史地图，数据中心可以在任意时间断开连接，并且所有保证都得到兑现，您无需进行额外的测试。事实上，您可能会丢失除一个节点之外的所有节点，但仍然可以完全运行。