Transactions 编年史地图原子性语义

我想知道编年史地图中的原子性语义。如果我有一个跨两个节点（服务器）共享的历史记录映射，并且我尝试在两个节点上同时将同一个键插入到该映射中，那么事务语义是什么

第一把会成功，第二把会失败吗

我很好奇编年史地图是否保证与ApacheZooKeeper相同的事务语义

在我的用例中，我想依靠这样一个事实，如果node1将一个键K1放入映射中，node2将能够检查K1的存在，如果它不存在，它将明确地知道它是第一个添加K1的

实际上，询问put-on-Chronicle映射是否是跨2个节点的分布式事务

非常感谢

---

Clifford

编年史地图使用最终一致性，最后一个获胜。当你观察微秒级的时间尺度时，节点处于一个分裂的大脑节点中，因为无法以这种速度保持它们的同步。 这是通过设计实现的，因为Map设计为支持每台服务器每秒数百万次的更新。 一般来说，在正常操作下，不难确保两台服务器不同时更新同一个密钥。例如，您可以使用Engine将所有更新传递给一台服务器，也可以对密钥进行分区以进行更新。 虽然分布式事务听起来是个不错的主意，但您应该注意； -它们要慢很多数量级， -当你有像大脑分裂这样的失败时，很难从中恢复过来。 -在不同的故障条件下测试应用程序是否正常工作是一件非常痛苦的事情

我的观点是，最好设计一个不需要这种假设的系统，这样你就可以知道在没有大量测试的情况下，它在失败时的表现

假设您在三个数据中心安装zookeeper，并确保没有任何数据中心拥有一半或更多的节点（两个数据中心还不够），从而确保一个数据中心的故障不会停止运行，但假设您的大脑因缓慢的互连而暂时分裂，这会影响任何更新，但会以难以复制或测试的方式暂时影响更新。

---

有了chronicle map，数据中心可以在任何时间断开连接，其所有保证都得到履行，您无需进行额外的测试。事实上，除了一个节点外，您可能会丢失所有节点，但仍然可以完全运行。

感谢您的详细回复。我的订单可以路由到3个传出网关中的任何一个，以便最终交付到ECN（这是为了确保高可用性）。我试图保证，第一个接收订单的网关是将订单发送到交易所的网关，而另外两个网关永远不会接收订单。我打算将唯一的订单id添加到Chronicle，并让所有3个网关在发送订单之前检查该订单id是否存在。根据以上建议，您对如何实现这一目标有何建议？编年史地图适合吗？