【问题标题】:at-most-once and exactly-once最多一次和恰好一次
【发布时间】:2012-11-14 01:10:40
【问题描述】:

我正在研究分布式系统,当谈到 RPC 部分时,我听说过这两种语义(最多一次和完全一次)。我知道当我们不想重复执行时,最多一次用于数据库实例。

第一个问题:

这是如何实现的?服务器如何知道它不应该再次执行请求?它可能是重复的,但也可能是合法的请求。

第二个问题是:

标题中的两种语义有什么区别?我会读 :)。我知道 at-most-once 可能根本不会被执行,但是,exactly-once 做了什么来保证执行?

【问题讨论】:

    标签: rpc semantics execution


    【解决方案1】:

    对于您的第二个问题,这里是对不同 types of messaging semantics 的一个很好的解释:

    最多一次语义:从工程复杂性的角度来看,最容易实现的语义类型,因为它可以通过即发即弃的方式完成。系统的组件很少需要有状态。虽然它是最容易实现的,但最多一次也是最不理想的消息语义类型。它不提供绝对的消息传递保证,因为每条消息都传递一次(最佳情况)或根本不传递。

    至少一次语义:这是对最多一次语义的改进。可能有多次尝试传递消息,因此至少有一次尝试成功。换句话说,消息可能会重复,但不会丢失。虽然作为系统范围的特征并不理想,但至少一次语义对于数据重复无关紧要的用例或在消费者端可以进行重复数据删除的场景来说已经足够了。

    Exactly-once 语义: 最终的消息传递保证和数据完整性方面的最佳选择。顾名思义,exactly-once 语义意味着每条消息都只传递一次。消息既不能丢失也不能传递两次(或多次)。 Exactly-once 是迄今为止最可靠的消息传递保证。这也是最难实现的。

    这就是这篇关于Exactly-once message processing 的博文的全部内容(披露:我为Ably 工作)

    希望这会有所帮助?

    【讨论】:

    • 我认为你真的在滥用“at-most-once”和“at-least-once”。
    • 被滥用是什么意思?以什么方式?
    【解决方案2】:

    对于第一个问题,我认为每个请求都应该附加一个唯一的 ID。因此,即使客户端发送了两个具有完全相同命令的请求,服务器也能够通过请求的唯一 ID 进行过滤和区分。

    对于第二个问题,我认为本文有助于定义 rpc 调用的语义。 http://www.cs.unc.edu/~dewan/242/f97/notes/ipc/node27.html

    【讨论】:

      【解决方案3】:

      最多一次语义的情况下,如果失败,请求会再次发送,但请求会在服务器上过滤重复。

      exactly once 语义中,再次发送请求,过滤重复请求,并保证服务器在失败后重新启动并从崩溃的地方开始处理请求。

      但是exactly once 是无法实现的,因为客户端发送请求时会发生什么,在请求到达服务器之前,服务器会崩溃。无法跟踪请求。

      http://de.wikipedia.org/wiki/Remote_Procedure_Call#Fehlersemantik

      【讨论】:

      • 这是不正确的!最多一次,意味着客户端如果没有收到响应就不会再次发送请求。在至少一次语义中,客户端将再次发送请求,服务器将(或不会)进行重复数据删除,具体取决于操作是否具有幂等性
      【解决方案4】:

      纠正赫斯珀的答案-

      早些时候,恰好有一次 RPC 无法实现,但 2015 年的一篇研究论文 [1] 证明这是可能的。基本上,RIFL 范式保证了被执行的 RPC 的一次执行的安全性被持久存储

      [1]:李、科林等人。 “实现大规模和低延迟的线性化。”第 25 届操作系统原理研讨会论文集。 ACM,2015 年

      【讨论】:

      • 它在非常广泛的假设下“证明”了它,即可以在数据库中原子地存储记录并修改副作用,但没有提供实际证据。在现实中(发送邮件,发出一些HTTP POST请求等)确实是不可能的,因为如果你先发邮件,然后在你存储“完成记录”之前就崩溃了,操作结果就丢失了。
      【解决方案5】:

      Bump,我也在研究这个,发现了这个,希望它有帮助(帮助我),

      至少一次还是最多一次?

      举个例子:获取锁
      如果客户端和服务器不工作,客户端会收到锁
      如果客户端失败,它可能有锁或没有(服务器需要一个计划!)
      如果服务器出现故障,客户端可能有锁或没有锁
      至少一次:客户不断尝试
      最多一次:客户端将收到异常
      客户遇到异常怎么办?
      需要实现一些特定于应用程序的协议
      请问服务器,我有锁吗?
      服务器需要有一个计划,以便在重新启动时记住状态
      例如,将锁存储在磁盘上。
      至少一次(如果我们从不放弃)
      客户不断尝试。服务器可能多次运行程序
      服务器必须使用应用程序状态来处理重复
      如果请求不是幂等的
      但很难使所有请求都具有幂等性
      例如,具有锁定和请求 id 的磁盘上的服务器良好存储
      检查每个请求的表
      即使服务器出现故障并重新启动,我们也会得到正确的语义
      什么是对的?
      取决于使用 RPC 的位置。
      简单的应用程序:
      最多一次很酷(更像是过程调用)
      更复杂的应用程序:
      在这两种情况下都需要应用程序级计划
      一次不明确会让你站起来
      => 处理机器故障使 RPC 不同于过程调用

      引自分布式系统和范例第 2 版

      【讨论】:

        猜你喜欢
        • 2018-07-15
        • 2020-05-12
        • 1970-01-01
        • 2022-09-23
        • 2017-01-14
        • 2020-10-04
        • 2021-04-05
        • 1970-01-01
        • 2018-12-20
        相关资源
        最近更新 更多