问题标签 [idempotent]

我正在组合一个写入数据库（Perl CGI 和 MySQL）的小型 Web 应用程序。CGI 脚本从表单中获取一些信息并将其写入数据库。然而，我注意到，如果我在网络浏览器上点击“重新加载”或“返回”，它会再次将数据写入数据库。我不想要这个。

在这种情况下，防止数据被重写的最佳方法是什么？

对于特定类型的功能，我需要适当的术语。

假设您在 SQL 数据库中编写了一个函数，其输入和输出包含在数据库事务的范围内。

也就是说，如果您在数据库事务的范围内调用此函数，则该函数使用的所有数据在同一范围内都是可用的。它可以查询数据库表，但不能从文件系统读取文件，或 ping 网站等。如果您在单个事务中REPEATABLE READ隔离调用该函数两次，您应该得到相同的结果，即使其他客户端正在对数据库进行更改。

同样，该函数没有副作用，除非在相同的事务范围内。不允许在数据库事务范围之外更改状态。该函数不应该发送电子邮件，也不应该写入文件系统，也不应该在 中存储值memcached等。如果该函数更改数据库中的数据，那没关系，因为如果调用事务回滚，那么该函数的效果也是如此.

函数的参数没问题，因为它们基本上用作常量。

这种类型的功能的正确术语是什么？“确定性”似乎还不够具体。您如何描述此类功能？

感谢您的回答，但它们都不是我的想法。幂等最接近，所以我将其标记为已接受的答案。但是无论如何，你们每个人都得到了我的支持。

• 纯函数没有副作用，它们的结果完全基于它们的参数。给定相同参数的结果总是相同的。这不行，因为我想到的数据库函数可以基于数据的状态，函数也可以影响数据的状态。

• 幂等函数可以根据数据的状态返回一个结果，并且给定相同的数据状态，结果总是相同的。但这并不完全符合我的想法。无论调用多少次，幂等函数的效果都必须导致结果不变。但是在事务隔离内所做的更改和在该范围之外所做的更改之间没有区别。

我最近花了很多时间阅读 HTTP 1.1 规范并将其与 REST 相关联。我发现对于 HTTP DELETE 方法的“幂等性”和安全性有两种解释。以下是两个阵营：

1. 如果您使用 HTTP DELETE 删除资源，并且成功（200 OK），然后您尝试删除该资源 N 次，您应该为每个删除调用返回一条成功消息（200 OK） . 这就是它的“幂等性”。

2. 如果您使用 HTTP DELETE 删除资源，并且成功（200 OK），然后您尝试再次删除该资源，您应该会收到一条错误消息（410 Gone），因为该资源已被删除。

规范说 DELETE 是幂等的，当然，但它也说幂等事件的序列仍然会产生副作用。我真的觉得第二个阵营是正确的，而第一个是误导性的。通过允许客户认为他们是删除先前删除的资源的原因，我们引入了哪些“安全性”？

第一个阵营有很多人，包括这个主题的几位作者，所以我想检查是否有一些令人信服的理由，而不是情绪导致人们进入第一个阵营。

应用程序发送电子邮件以验证用户帐户或重置密码。我相信以下是它应该的方式，我要求参考和实现。

如果一个应用程序必须在电子邮件中发送一个链接来验证用户的地址，在我看来，链接和应用程序对链接的处理应该具有以下特征：

1. 该链接在请求 URI ( )中包含一个随机数。http://host/path?nonce
2. 在点击链接 (GET) 时，用户会看到一个表单，可以选择使用 nonce。
3. 用户确认输入（POST）。
4. 服务器收到请求并

• 检查输入参数，
• 执行更改，
• 并使随机数无效。

根据关于 Safe and Idempotent Methods 的 HTTP RFC，这应该是正确的。

问题是这个过程涉及一个额外的页面或用户操作（第 3 项），这被很多人认为是多余的（如果不是无用的话）。我在向同行和客户展示这种方法时遇到了问题，因此我要求更广泛的技术团队对此提供意见。我反对跳过 POST 步骤的唯一理由是可能从浏览器中预加载链接。

• 是否有关于这个主题的参考资料可以更好地解释这个想法并说服非技术人员（来自期刊、博客等的最佳实践）？
• 是否有实施这种方法的参考网站（最好是流行的和有很多用户的）？
• 如果没有，是否有记录的原因或等效的替代方案？

谢谢你，
卡里姆

细节不遗余力

我保持了主要部分的简短，但是为了减少对我故意遗漏的细节的过多讨论，我将添加一些假设：

• 电子邮件的内容不是本次讨论的一部分。用户知道她必须单击链接才能执行操作。如果用户没有反应，什么都不会发生，这也是众所周知的。
• 我们不必说明我们向用户发送邮件的原因，也不必说明通信政策。我们假设用户希望收到电子邮件。
• nonce 具有过期时间戳，并直接与收件人电子邮件地址相关联以减少重复。

笔记

使用 OpenID 等，普通的 Web 应用程序无需执行标准的用户帐户管理（密码、电子邮件...），但仍有一些客户想要“他们自己的用户”

奇怪的是，我还没有在这里找到令人满意的问题或答案。到目前为止我发现了什么：

• Don 在HTTP POST 中使用 URL 查询参数回答——好主意还是不好？
• Thomas 的问题——你什么时候使用 POST，什么时候使用 GET？

什么是幂等操作？

当我在将表单传递到下一页时使用 post 方法时，我得到 null 重复此问题 链接文本

在 testjsp.jsp 中，我试图打印我无法执行的 prio 变量及其打印 null。我只想访问其他服务器端组件中的变量 prio 并且还想使用 post 方法。

这与幂等属性有什么关系吗？我很困惑为什么我无法访问 testjsp 页面中的变量 prio 。

我有多个分布式竞争消费者，每个消费者都从同一个（事务性）队列中提取消息。我想将每个消费者实现为幂等接收器，因此即使重复到达，我也永远不会多次处理相同的消息（跨所有消费者）。我怎样才能与多个消费者一起实现这一目标？

我的第一个想法是在将它们放入队列之前以某种方式为每条消息生成一个连续的序列号，然后使用共享数据库表来协调消费者之间的工作。即消费者#1 处理msg#1，然后将一行写入数据库表，说'msg#1 已处理'（希望它在数据库中以确保持久性）。当消费者准备好处理消息时，它会查看队列中的下一个可用消息，查阅共享数据库表并确定这是否是按顺序排列的下一个消息。如果是这样，它会将其从队列中拉出。如果不是，它会忽略它。

这样，我只需要存储处理的最后一条消息（因为所有消息都有一个连续的序列号），我不需要使用缓冲区存储所有接收到的消息的 ID，并以协商的“窗口”大小，并且消息总是被串行处理（这是我想要的这个场景）。

只是好奇是否有更好的方法？我担心每当我需要处理消息时查询数据库的成本。

如果答案是“它取决于框架”，那么我想到了 MSMQ

如何使用带有 SQL 2008 后端的 subsonic 执行幂等插入行？

例如

我有一个表“颜色”，其中名称是主键。

我知道我可以捕获错误，但我更愿意在 MySql 中执行类似 REPLACE 的操作

我正在阅读 twitter ( http://engineering.twitter.com/2010/04/introducing-gizzard-framework-for.html ) 最近发布的 Gizzard 分片框架的文章。它提到所有写操作必须是幂等的，以确保高可靠性。

根据维基百科，“幂等操作是可以多次应用而不改变结果的操作。” 但是，恕我直言，在 Gizzard 的情况下，幂等写操作应该是顺序无关紧要的操作。

现在，我的问题是：如何使写操作具有幂等性？

我唯一能想象的就是在每次写入时都附加一个版本号。例如，在博客系统中，每个博客必须有一个$blog_id和$content。在应用层面，我们总是像这样write($blog_id, $content, $version)来写博客内容。$version在应用程序级别被确定为唯一的。所以，如果一个应用程序首先尝试将一个博客设置为“Hello world”，第二个希望它是“再见”，那么write是幂等的。我们有这样两个写操作：

这两个操作应该改变数据库中的两条不同的记录。所以，无论这两个操作执行多少次，以什么顺序执行，结果都是一样的。

这只是我的理解。如果我错了，请纠正我。

我正在使用 ROA（面向资源的架构）设计一个 RESTful Web 服务。

我试图找出一种有效的方法来保证在服务器指定资源密钥的情况下创建新资源的 PUT 请求的幂等性。

据我了解，传统的做法是创建一种事务资源，例如 /CREATE_PERSON。用于创建新人员资源的客户端-服务器交互将分为两部分：

第 1 步：获取用于创建新 PERSON 资源的唯一事务 ID:::

第 2 步：使用事务 id::: 在保证唯一的请求中创建新人员资源

我用这种方法看到的问题是它需要向服务器发送两个请求才能执行创建新 PERSON 资源的单个操作。这会产生性能问题，增加用户等待客户端完成其请求的机会。

我一直在尝试消除第一步的想法，例如在每个请求中预先发送事务 ID，但我的大多数想法都有其他问题或涉及牺牲应用程序的无状态性。

有没有办法做到这一点？

编辑：：：：：：

我们最终采用的解决方案是让客户端获取 UUID 并将其与请求一起发送。UUID 是一个非常大的数字，占用 16 个字节 (2^128) 的空间。与具有编程头脑的人可能直观地认为的相反，随机生成 UUID 并假设它是唯一值是公认的做法。这是因为可能值的数量如此之大，以至于随机生成两个相同数字的几率低到几乎不可能。

一个警告是我们让我们的客户从服务器请求一个 UUID ( GET uuid/)。这是因为我们无法保证客户端运行的环境。如果出现问题，例如在客户端上播种随机数生成器，那么很可能会发生 UUID 冲突。