什么是幂等操作？

Question

什么是幂等操作？

Answer 1

在计算中，幂等操作是一种如果使用相同的输入参数调用多次则不会产生额外效果的操作。 例如，从集合中删除项目可以被视为集合上的幂等操作。

在数学中，幂等运算是指f(f(x)) = f(x)。 例如，abs() 函数是幂等的，因为对于所有 x 来说，abs(abs(x)) = abs(x)。

这些略有不同的定义可以通过考虑数学定义中的x表示对象的状态，而f是可能改变该对象的操作来协调。 例如，考虑 Python set 和它的 discard 方法。 discard 方法从集合中删除一个元素，如果该元素不存在则不执行任何操作。 因此：

my_set.discard(x)

与执行两次相同的操作具有完全相同的效果：

my_set.discard(x)
my_set.discard(x)

幂等操作经常用于网络协议的设计中，其中执行操作的请求保证至少发生一次，但也可能发生多次。 如果该操作是幂等的，那么执行该操作两次或更多次并没有什么坏处。

有关详细信息，请参阅关于幂等性的维基百科文章。

---

^{上面的答案之前有一些不正确和误导性的例子。 下面的评论是 2014 年 4 月之前写的，涉及较旧的修订版。}

Answer 2

幂等操作可以重复任意次数，并且结果将与只执行一次相同。 在算术中，数字加零是幂等的。

在“RESTful”Web 服务的背景下，幂等性被广泛讨论。 REST 寻求最大限度地利用 HTTP 来为程序提供对 Web 内容的访问，并且通常与基于 SOAP 的 Web 服务形成鲜明对比，后者只是在 HTTP 请求和响应中隧道化远程过程调用样式服务。

REST 将 Web 应用程序组织为“资源”（例如 Twitter 用户或 Flickr 图像），然后使用 POST、PUT、GET 和 DELETE 等 HTTP 动词来创建、更新、读取和删除这些资源。

幂等性在 REST 中扮演着重要的角色。 如果您获取 REST 资源的表示形式（例如，从 Flickr 获取 jpeg 图像），并且操作失败，则可以一次又一次地重复 GET，直到操作成功。 对于网络服务来说，获取图像多少次并不重要。 同样，如果您使用 RESTful Web 服务来更新您的 Twitter 帐户信息，您可以多次 PUT 新信息，以便从 Web 服务获得确认。 PUT 一千次与 PUT 一次相同。 同样，删除 REST 资源一千次与删除一次相同。 因此，幂等性使得构建能够适应通信错误的 Web 服务变得更加容易。

进一步阅读：RESTful Web Services，作者：Richardson 和 Ruby（幂等性在页面上讨论103-104），以及 Roy Fielding 的关于 REST 的博士论文 。 Fielding 是 HTTP 1.1、RFC-2616 的作者之一，该文件在 中讨论了幂等性第 9.1.2 节。

Answer 3

无论调用该操作多少次，结果都是一样的。

Answer 4

幂等性意味着应用一次操作或应用多次具有相同的效果。

示例：

• 乘以零。 无论重复多少次，结果仍然是零。
• 设置布尔标志。 无论您执行多少次，旗帜都会保持不动。
• 从数据库中删除具有给定 ID 的行。 如果您再试一次，该行仍然消失。

对于纯函数（没有副作用的函数），幂等性意味着 f(x) = f(f(x)) = f(f(f(x))) = f(f(f) (f(x)))) = ...... 对于 x 的所有值

对于有副作用的函数，幂等性还意味着在第一次应用后不会产生额外的副作用。 如果您愿意，您可以将世界状态视为函数的附加“隐藏”参数。

请注意，在进行并发操作的世界中，您可能会发现您认为幂等的操作不再如此（例如，另一个线程可能会取消设置上例中布尔标志的值）。 基本上，只要你有并发和可变状态，你就需要更仔细地考虑幂等性。

幂等性通常是构建健壮系统的有用属性。 例如，如果存在您可能从第三方收到重复消息的风险，则让消息处理程序充当幂等操作会很有帮助，以便消息效果仅发生一次。

Answer 5

理解幂等操作的一个很好的例子可能是用远程钥匙锁定汽车。

log(Car.state) // unlocked

Remote.lock();
log(Car.state) // locked

Remote.lock();
Remote.lock();
Remote.lock();
log(Car.state) // locked

lock 是一个幂等操作。 即使每次运行lock时都会产生一些副作用，例如闪烁，无论您运行多少次lock操作，汽车仍然处于相同的锁定状态。

Answer 6

只要传入相同的参数，幂等操作就会产生相同状态的结果，即使您多次调用它也是如此。

Answer 7

幂等操作是可以多次应用的操作、动作或请求，而不改变初始应用之外的结果，即系统的状态。

示例（Web 应用程序上下文）：

幂等性：
发出多个相同的请求与发出单个请求具有相同的效果。 电子邮件消息系统中的消息被打开并在数据库中标记为“已打开”。 人们可以多次打开该消息，但这种重复操作只会导致该消息处于“打开”状态。 这是幂等操作。 第一次使用与资源（系统状态）不匹配的信息对资源进行 PUT 更新时，系统状态将随着资源更新而改变。 如果对资源重复 PUT 相同的更新，则更新中的信息将与每次 PUT 时系统中已有的信息相匹配，并且系统状态不会发生任何更改。 具有相同信息的重复 PUT 是幂等的：第一个 PUT 可能会更改系统的状态，而后续 PUT 则不会。

非幂等：
如果某个操作总是导致状态发生变化，例如一遍又一遍地向用户 POST 相同的消息，导致每次都会发送一条新消息并将其存储在数据库中，则我们称该操作是非IDEMPOTENT。

无效能力：
如果一个操作没有副作用，比如纯粹在网页上显示信息，而没有对数据库进行任何更改（换句话说，您只是读取数据库），我们称该操作为 NULLIPOTENT。 所有 GET 都应该是无效的。

当谈论系统状态时，我们显然忽略了希望无害且不可避免的影响，例如日志记录和诊断。

Answer 8

只是想抛出一个证明幂等性的真实用例。 在 JavaScript 中，假设您正在定义一堆模型类（如在 MVC 模型中）。 通常实现的方式在功能上相当于这样（基本示例）：

function model(name) {
  function Model() {
    this.name = name;
  }

  return Model;
}

然后您可以像这样定义新类：

var User = model('user');
var Article = model('article');

但是如果您尝试通过 model 获取 User 类('user')，从代码中的其他地方，它会失败：

var User = model('user');
// ... then somewhere else in the code (in a different scope)
var User = model('user');

这两个 User 构造函数会不同。 也就是说，

model('user') !== model('user');

要使其幂等，您只需添加某种缓存机制，如下所示：

var collection = {};

function model(name) {
  if (collection[name])
    return collection[name];

  function Model() {
    this.name = name;
  }

  collection[name] = Model;
  return Model;
}

通过添加缓存，每次执行 model('user') 时将是同一个对象，因此它是幂等的。 所以：

model('user') === model('user');

Answer 9

相当详细和技术性的答案。 只需添加一个简单的定义即可。

幂等 = 可重新运行

例如，
如果执行多次，则不能保证 Create 操作本身运行时不会出错。
但如果有一个操作CreateOrUpdate，那么它会声明可重新运行性（幂等性）。

Answer 10

每第 n 个结果都会产生与第一个结果的值匹配的输出的任何操作。 例如-1的绝对值是1。-1的绝对值的绝对值是1。-1的绝对值的绝对值是1。以此类推。

另请参阅：什么时候使用递归才是真正愚蠢的时机？

Answer 11

幂等操作：多次执行不会产生副作用的操作。

示例：从数据资源检索值并打印它的操作

非幂等操作：多次执行会造成一定危害的操作。 （当它们改变一些值或状态时）

示例：从银行账户提款的操作

Answer 12

对集合进行幂等操作时，应用一次或多次后，其成员不会发生变化。

它可以是像 absolute(x) 这样的一元运算，其中 x 属于一组正整数。 这里绝对（绝对（x））= x。

它可以是二元运算，例如集合与其自身的并集将始终返回相同的集合。

干杯

Answer 13

简而言之，幂等操作是指无论操作多少次幂等操作，该操作都不会得到不同的结果。

例如，根据HTTP规范的定义，GET、HEAD、PUT和DELETE都是幂等操作； 然而POST 和PATCH 则不然。 这就是为什么有时 POST 被 PUT 替换的原因。

Answer 14

如果多次执行某个操作相当于执行一次，则称该操作是幂等的。

例如：将音量设置为 20。
无论多少次将电视的音量设置为20，最终的结果都是音量为20。 即使一个进程执行该操作 50/100 次或更多，在该进程结束时，音量也将为 20。

反例：将音量增加 1。如果一个进程执行该操作 50 次，最终交易量将为初始交易量 + 50，如果进程执行该操作 100 次，则最终交易量将为初始交易量 + 100。 您可以清楚地看到，最终结果根据操作执行的次数而变化。 因此，我们可以得出结论，该操作不是幂等的。

---

如果您从编程角度思考，假设我有一个操作，其中函数 f 将变量 foo 作为函数 f< 的输入和输出/code> 设置为变量 foo 。 如果在进程结束时（执行该操作 50/100 次或更多），我的 foo 变量保存了该操作仅执行一次时的值，则该操作是幂等的，否则不。

foo = <let's say -2>

{ foo = f( foo ) }

大括号概述了操作

如果函数f返回输入的平方，则该操作不是幂等的。 则foo在进程结束时将被(-2)提升到幂（2 *操作执行次数）

因为如果函数f 返回输入的绝对值，则该操作是幂等的，因为无论进程执行该操作多少次，foo 在结束时都将是绝对值 (-2)的过程。

---

在数学意义上，幂等的含义略有不同：
f(f(....f(x))) = f(x)
这里，f(x) 的输出再次作为输入传递给 f，这在编程中并不需要始终如此。

Answer 15

1. 幂等基础知识

从数学上讲，如果f(f(x)) = f(x)，则称函数是幂等的。
因此，如果我们有一个函数 absolute(x)，它返回整数 x 的正对应项； 那么下面的条件一定成立：

absolute(absolute(x)) = absolute(x)

如果我们将x设为-100，那么无论我们重复这个操作多少次，第一次执行后的结果和第一次执行后的结果将完全相同。

所以，

absolute(-100) = 100
AND
absolute(absolute(-100)) = absolute(100) = 100
=> absolute(absolute(x)) = absolute(x)

❗ 这里需要注意的重要一点是“结果”并不一定意味着从函数返回的数据。 它指的是正在执行操作的数据。

因此，如果您采用面向对象编程中的函数，例如，具有值 {1,2,4} 的 Set，并且您尝试执行 add(2)； 结果即集合的内容不会改变。 无论重复此操作多少次，结果都将始终相同，即 {1,2,4}。 但是，当您添加集合中不存在的元素时，即执行 add(3) 时，集合将变为（不考虑顺序）{1,2,4, 3}。 但是当你再次重复该操作时（甚至100次），结果（即集合）将继续包含{1,2,4,3}。 对于列表来说情况并非如此，因为它可能包含重复项。 每次您向列表中添加某些内容时，它总是会被添加。

为了简化，

如果一个操作可以重复多次，并且第一次执行后的结果与执行n次后的结果完全相同，则称该操作是幂等的。

除此之外，任何不更改数据的操作都是幂等的，因为它不会对数据的状态产生任何影响。

2. REST 中的幂等性
因此，像 GET、HEAD、OPTIONS、TRACE.. 这样的请求方法（不会更改数据）是幂等的（只要它们正确实现）。
对于打算更改数据的方法，其幂等性可能会有所不同。 例如：

• PUT & 删除：应该以幂等的方式实现。
• POST 和 PATCH：不保证幂等。 他们可能是，也可能不是。

3. 为什么 PUT 必须是幂等的？

根据 RFC-7231 IETF 规定，PUT 旨在替换服务器的状态。 因此，如果您在网站上存储了地址，则 PUT 请求的请求中应包含完整地址。 此外，它应该替换服务器上的数据（如果不存在则创建）。 因此，第一次执行请求后的结果和多次执行同一请求后的结果是完全相同的。

4. 为什么DELETE必须是幂等的？

删除意味着删除服务器上的资源。 因此，如果您要删除地址，则无法再次删除同一地址（该地址不存在，并且不会再删除任何内容）。 同样，第一次执行后的 RESULT 和多次执行同一请求后的 RESULT 是完全相同的。

❗ REST 中的一个常见误解是，如果请求每次执行时都收到相同的响应，则它是幂等的。 这是不正确的。 结果始终与服务器上的数据相关（即正在执行操作的数据）。 在考虑 REST 中的幂等性时，请考虑服务器的状态。

该视频非常详细地解释了这些概念：https://www.youtube.com/watch?v =R7s2FVN4c9Q

Answer 16

我的5c：
在集成和网络中，幂等性非常重要。
现实生活中的几个例子：
想象一下，我们将数据传送到目标系统。 由一系列消息传递的数据。
1. 如果序列在通道中混合会发生什么？ （网络包总是这样做:)）。 如果目标系统是幂等的，结果不会有不同。 如果目标系统依赖于序列中的正确顺序，我们必须在目标站点上实现重新排序器，这将恢复正确的顺序。
2. 如果消息重复怎么办？ 如果目标系统的通道没有及时确认，源系统（或通道本身）通常会发送另一个消息副本。 因此，我们可能会在目标系统端出现重复的消息。
如果目标系统是幂等的，它会处理它并且结果不会有不同。
如果目标系统不是幂等的，我们必须在通道的目标系统端实现重复数据删除器。

Answer 17

对于工作流管理器（如 Apache Airflow），如果管道中的幂等性操作失败，系统可以自动重试该任务，而不会影响系统。 即使日志发生变化，这也很好，因为您可以看到事件。

在这种情况下最重要的是您的系统可以重试失败的任务并且不会弄乱管道（例如每次重试时在表中附加相同的数据）

Answer 18

假设客户端向“IstanceA”服务发出请求，该服务处理该请求，将其传递给数据库，并在发送响应之前关闭。 因为客户端看不到它已被处理，并且它将重试相同的请求。 负载均衡器会将请求转发到另一个服务实例“InstanceB”，该实例将对同一数据库项进行相同的更改。

我们应该使用幂等令牌。 当客户端向服务发送请求时，它应该有某种可以保存在数据库中的请求 ID，以表明我们已经执行了该请求。 如果客户端重试请求，“InstanceB”将检查 requestId。 由于该特定请求已被执行，因此它不会对数据库项进行任何更改。 这些类型的请求称为幂等请求。 所以我们多次发送相同的请求，但我们不会做任何改变