至多一次，一次一次

Question

我正在研究分布式系统，当谈到RPC部分时，我听说过这两种语义（最多一次，一次只有一次）。据我所知，当我们不想重复执行时，最多只用于实例的数据库。

第一个问题：

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

第二个问题是：

标题中的两个语义有什么区别？我会读 ：）。我知道最多一次可能根本不会被执行但是，究竟什么才能保证执行？

Answer 1

如果最多一次语义，请在发生故障时再次发送请求，但会在服务器上过滤请求以获取重复项。

在完全一次语义中，再次发送请求，请求被重复过滤，并保证服务器在失败后重新启动并开始处理崩溃的请求。

但完全一次是不可实现的，因为当客户端发送请求时会发生什么，并且在它到达服务器之前，服务器崩溃。无法跟踪请求。

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

Answer 2

Bump，我也在研究这个，发现这个，希望它有所帮助（帮助我），

  

至少一次与最多一次？

   让我们举一个例子：获得一个锁    如果客户端和服务器保持运行，客户端会收到锁定    如果客户端失败，它可能有锁定（服务器需要计划！）
   如果服务器出现故障，客户端可能有锁定或没有    至少一次：客户不断尝试    最多一次：客户将收到例外    客户在例外的情况下做了什么？    需要实施一些特定于应用程序的协议    问服务器，我有锁吗？   服务器需要有一个计划，以便在重新启动时记住状态    例如，将磁盘存储在磁盘上    至少一次（如果我们永不放弃）
   客户继续努力。服务器可以多次运行程序
   服务器必须使用应用程序状态来处理重复项    如果请求不是幂等的   但很难让所有要求具有幂等性    例如，具有锁定和请求ID的磁盘上的服务器良好存储    检查表每个要求
  即使服务器出现故障并重新启动，我们也会得到正确的语义    什么是对的？
   取决于RPC的使用位置    简单的应用：
   最多一次很酷（更像程序电话）
   更复杂的应用：
   在这两种情况下都需要一个应用级计划    不清楚马上给你一条腿    =＆GT;处理机器故障使RPC与过程调用不同

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

Answer 3

纠正Hesper的回答 -

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

[1]：Lee，Collin，et al。 ＆＃34;大规模实现线性化和低延迟。＆＃34;第25届操作系统原理研讨会论文集。 ACM，2015

Answer 4

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

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

Answer 5

对于您的第二个问题，这里有一个很好的解释，说明了不同的types of messaging semantics：

最多一次的语义：从工程复杂性的角度来看，最容易实现的一种语义类型，因为它可以一劳永逸的方式完成。系统的组件很少有状态的。尽管这是最容易实现的，但最多一次也是最不理想的消息传递语义类型。它没有提供绝对的消息传递保证，因为每个消息仅传递一次（在最佳情况下），或者根本不传递。

至少一次语义：：这是对一次最多语义的改进。可能有多次尝试传递消息，因此至少有一次尝试成功。换句话说，消息可能会重复，但不会丢失。尽管不是一次理想的系统范围的特征，但是至少一次语义对于在很少关注重复数据的用例或在消费者方可能进行重复数据删除的情况下已经足够了。

一次语义：最终的消息传递保证和就数据完整性而言的最佳选择。顾名思义，一次语义意味着每条消息仅发送一次。消息既不会丢失，也不会传递两次（或多次）。到目前为止，精确一次是最可靠的消息传递保证。这也是最难实现的。

这是有关Exactly-once message processing的博客文章的全部内容（披露：我为Ably工作）

希望这对您有帮助