编年史图原子性语义
我想知道纪事图中的原子性语义。如果我有一个跨2个节点(服务器)共享的历史记录映射,并且我尝试在两个节点上同时将相同的密钥插入此映射,那么事务性语义是什么?编年史图原子性语义
第一次成功,第二次失败?
我很好奇,如果Chronicle Map保证Apache Zookeeper具有相同的事务语义?
在我的用例中,我想依赖的事实是,如果node1将密钥K1放入地图中,则该节点2将能够检查K1的存在,如果不存在,它会明确地知道它是第一个添加K1的。
实际上,询问ChronicleMap是否是分布式事务,跨越2个节点。
非常感谢 克利福德
纪事地图使用最终一致性,最后一个获胜。当你观察微秒时间尺度时,节点处于裂脑节点中,因为无法以这种速度保持它们同步。 这是设计的,因为Map旨在支持每台服务器每秒数百万次更新。 通常,在正常操作下不难确保两台服务器不会同时更新相同的密钥。例如。您可以使用引擎将所有更新传递给一台服务器,也可以对密钥进行分区以进行更新。 虽然分布式事务听起来像是一个好主意,但您应该注意到; - 它们慢很多个数量级, - 从分裂大脑等失败时很难恢复。 - 测试您的应用程序在不同的故障条件下正常工作是一个真正的痛苦。
我认为我们最好设计一个不需要这个假设的系统,并且你会知道它在未经过广泛测试的情况下如何表现失败。
假设您将zookeeper安装到三个数据中心,并确保一个数据中心的故障不会通过确保没有数据中心具有一半或更多节点(两个数据中心不够)而停止运行,但是假设您有临时拆分大脑由缓慢的互连引起,这会影响任何更新,但是以瞬间难以重现或测试的方式。 使用历史记录地图,数据中心可以在任何时间断开连接,并且所有的保证都得到遵守,您无需进行额外的测试。事实上,除了一个节点之外,您可能会失去所有节点,并仍然完全运行
感谢Peter的详细回复。我的订单可以发送到3个出网关中的任何一个,以最终交付给ECN(这是为了确保高可用性)。我试图保证第一个接收订单的网关是将其发送给交易所的网关,而另一个网关则不应该这样做。我将为Chronicle添加唯一的订单ID,并且在发送订单前,所有3个网关检查是否存在此订单ID。根据你上面的建议,你对如何实现这一目标有任何建议吗? Chronicle Map是否合适? – cliff