Ram*_*sio 16
对于第二个问题,这是对不同类型的消息传递语义的很好的解释:
\n至多一次语义:从工程复杂性的角度来看,最容易实现的语义类型,因为它可以通过“即发即忘”的方式完成。系统组件很少需要有状态。虽然它是最容易实现的,但最多一次也是最不理想的消息传递语义类型。它不提供绝对的消息传递保证,因为每条消息都传递一次(最好的情况)或根本不传递。
\n至少一次语义:这是对最多一次语义的改进。可能会多次尝试传递消息,因此至少有一次尝试成功。换句话说,消息有可能重复,但不会丢失。虽然作为系统范围的特性并不理想,但至少一次语义对于不太关心数据重复的用例或消费者端可以进行重复数据删除的场景来说已经足够好了。
\nExactly-once语义:最终的消息传递保证和数据完整性方面的最佳选择。顾名思义,精确一次语义意味着每条消息都精确传递一次。消息既不会丢失,也不会传递两次(或更多次)。Exactly-once 是迄今为止最可靠的消息传递保证。它\xe2\x80\x99s也是最难实现的。
\n
这就是这篇关于Exactly-once 消息处理的博客文章的全部内容(披露:我为Ably工作)
\n希望这可以帮助
\n在最多一次语义的情况下,如果失败则再次发送请求,但是在服务器上过滤请求以获得重复.
在一次语义中,请求再次发送,请求被过滤为重复,并且保证服务器在失败后重新启动并开始处理崩溃的请求.
但恰好一次是不可实现的,因为当客户端发送请求时会发生什么,并且在它到达服务器之前,服务器崩溃.无法跟踪请求.
http://de.wikipedia.org/wiki/Remote_Procedure_Call#Fehlersemantik
顶一下,我也在研究这个,发现了这个,希望它有帮助(帮助我),
至少一次与最多一次?
让我们举个例子:
如果客户端和服务器保持正常状态,则获取锁,客户端收到锁
,如果客户端失败,它可能有锁或没有锁(服务器需要一个计划!)如果服务器失败,客户端 至少
可能有锁或没有锁-一次:客户端 最多
尝试一次:客户端将收到异常 ,在发生异常时客户端会做什么? 需要实现一些特定于应用程序的协议 询问服务器,我有锁吗? 服务器需要有一个在重新启动时记住状态的计划 ,例如,在磁盘上存储锁。 至少一次(如果我们永不放弃) 客户会继续尝试。服务器可能多次运行过程 如果请求不是幂等的 ,但很难使所有请求幂等, 服务器必须使用应用程序状态来处理重复项,例如,服务器在磁盘上良好存储 ,即使服务器失败并重新启动, 每个请求都有 锁和请求 ID检查表,我们得到正确的语义 什么是正确的? 取决于使用 RPC 的地方。 简单的应用程序: 至多一次很酷(更像是过程调用) 更复杂的应用程序: 在这两种情况下都需要一个应用程序级计划 不清楚 一次给你一个优势 => 处理机器故障使 RPC 与过程调用不同
引自分布式系统和范式第二版