问题标签 [idempotent]

无论我重新加载.emacs文件多少次，

M-x load-file RET ~/.emacs RET

我希望结果与第一次相同。我想让我的.emacs文件是幂等的。

动机

我知道我可以通过手术评估一个区域 ( C-c C-r)、一个defun ( )C-M-x或最后一个 sexp ( C-x C-e)。在进行小的更改时，我经常采用这种更精致的方法。但是，在重新处理文件时，有时我想通过重新加载整个文件.emacs来最终检查更改的结果。.emacs每次重新启动 emacs 都会很快变老，尤其是在进行主要的.emacs内务处理时。

具体步骤

我必须采取哪些具体步骤来更新我的.emacs文件以将非幂等操作替换为幂等操作？

例如，

1. 搜索“-hook”并将直接添加到钩子的调用替换为调用add-hook，如果已经存在，则不会将函数重新添加到钩子中。
2. 用直接设置或清除替换任何标志的切换。当心？？尤其是。
3. ...

一个全面的检查和更正列表将是理想的，但您遇到的任何关键的个人检查也会有所帮助。

我需要想出一个策略来处理数据存储条目创建时的客户端重试：

• 客户端发送请求以在数据库中创建新条目
• 服务器执行条目创建并准备成功回复
• 发生一些错误，使客户端认为请求未处理（数据包丢失，...）
• 客户端发送相同的请求以再次在数据库中创建新条目
• 服务器检测到重试并重新创建并发送原始回复而不创建另一个数据存储条目
• 客户收到回复
• 每个人都很高兴，数据库中只创建了一个条目

我有一个限制：服务器是无状态的！它没有关于客户端的会话信息。

我目前的想法如下：

• 用保证的全局唯一 ID 标记每个创建请求（这是我创建它们的方式，尽管它们与问题不太相关）：
  • 使用数据存储（和内存缓存），我为每个服务器实例在加载后分配一个唯一的、单调递增的 ID（我们称之为SI）
  • 当客户端请求起始页面时，为请求提供服务的实例会生成一个唯一的单调递增页面加载 ID ( PL )，并将SI.PL与页面内容一起发送给客户端
  • 对于每个创建请求，客户端都会生成一个唯一的单调递增请求 ID ( RI )，并将SI.PL.RI与创建请求一起发送
• 对于每个创建请求，服务器首先检查它是否知道创建标签
• 如果没有，它会创建新条目并以某种方式将 create-tag 与它一起存储
• 如果它确实知道该标签，它会使用它来查找最初创建的条目并重新创建相应的回复

以下是我现在正在考虑的实施选项及其问题：

1. 将 create-tag 存储为条目内的索引属性：
   • 当服务器收到请求时，它必须使用查询来查找任何现有条目
   • 问题：由于 AppEngine 中的查询只有最终一致，它可能会丢失一个条目
2. 使用 create-tag 作为条目的键：
   • 应该没问题，因为如果数字不换行，它保证是唯一的（不太可能是多头）
   • 小不便：它会在将来的任何使用中增加条目密钥的长度（不必要的开销）
   • 主要问题：这将在数据存储中生成顺序条目键，应不惜一切代价避免这种情况，因为它会在存储的数据中创建热点，从而显着影响性能

对于选项 2，我正在考虑的一种解决方案是使用某种公式，该公式采用序列号并将它们重新映射到一个唯一的、确定的但看起来随机的序列上，而不是消除热点。关于这样的公式可能是什么样子的任何想法？

或者也许有更好的方法？

我正在为 DDD 应用程序编写服务层。
服务通过 WSS 上的 JSON-RPC 公开。
我不确定如何响应多余的服务调用。

关于系统的一些事实：

1. 所有请求必须在特定时间内完成，否则会发生超时异常。
2. 如果系统负载很重，它可能会决定丢弃请求（可见为timeout）。
3. 如果系统负载过重，一些消息可能会在队列中过期（显示为timeout）。
4. 即使请求到达它的目标 ACK 也可能无法及时到达用户（可见为timeout）。
5. 如果 ACK 没有及时到达，最终用户有权重新调用方法。

不保证请求完成。因此需要幂等性。

如果我们考虑 [4]+[5] 的含义，就会出现问题：

• 用户调用方法 setFoo(Bar)。
  • 实体已创建，但 ACK 未按时完成。
• 用户收到超时并假设他应该再试一次，所以他重新调用 setFoo(Bar)。
• 实体已经存在 -> 嗯...

问题是：用户应该得到 ACK 还是错误（我已经完成了那个伙伴......）？

我必须对方法的幂等性进行测试。

假设我有具有以下方法的 Person 类：

我需要在删除之前测试什么时候出现问题，下次你调用方法 doSomething 时，它会在第一次应该正确运行时创建与你想要的相同的结果。例如，当您运行调用该方法但失败（例如通过停止脚本）的脚本时，可能会发生这种情况。当您在以下时间运行脚本时，它应该会给出相同的结果而不会失败。

你能在单元测试中做到这一点吗？

提前致谢

我正在使用 Ansible，我只想运行一次任务。我只遵循一次关于如何配置和运行任务的文档

但是当我运行 Ansible 时，它​​总是运行这个任务。我怎样才能只运行一次我的任务。

示例路线：

在没有 myid 参数的情况下向侦听器 URL 发送请求会引发 org.apache.camel.processor.idempotent.NoMessageIdException: No message ID could be found using expression: header(myid) on message exchange: Exchange[Message: [Body is instance of org .apache.camel.StreamCache]]

没有从 onException 传递。

（这并不是 Rails 特有的，但我将使用 Rails 结构来提问）。

TL;博士

当用户在地址栏中键入一个真正是 PUT 操作而不是 GET 的 URI 时会发生什么？

细节

假设我们有一个支持 Web 的 Gauge，它将最近读取的值的副本保存在数据库中（为了提高效率），但用户可以请求更新以刷新缓存的值。所以这里的路线可能看起来像：

我选择GET显示仪表的缓存状态，因为您可以执行任意数量的 GET 并且结果永远不会改变。在http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html的术语中，GET 操作是幂等的。因此GET /gauge/33将获取仪表 #33 的缓存值。

据我了解 RFC2616，我必须使用 aPUT来更新本地状态，因为状态可以在每次调用时更改：它不是幂等的。另一种说法PUT /gauge/33/update是在数据库中产生副作用。

现在：如果我误解了 RCF2616，请在此阻止我，我会悄悄溜走。

问题

我的问题很简单：如果用户/gauge/33/update在浏览器的地址栏中输入内容会发生什么？这向服务器显示为GET /gauge/33/update，但没有与之匹配的路由。

为相同的 URI 模式设置包含 GET 和 PUT 的路由是否常见？也就是说，我可以将路由表设置为：

我对这种方法的担忧是，如果用户GET /gauge/33/update连续调用两次（或多次），服务器可能会决定——因为 GET 表示幂等操作——它实际上不需要执行更新。

我只是迂腐？还是我误解了 RFC2616？

这是我在应用程序中创建资源的经典 RESTful 方式：

当我们触及数据存储性能领域时，会发现随机生成的 UUID 不能很好地服务于数据局部性等许多原因。

服务器生成的 ID 对性能有好处，但它们并不真正匹配 REST：

1. 如果使用 POST 创建资源，就会失去幂等性：REST 隐含 PUT、GET、DELETE 幂等性，而 POST 则没有。
2. 在执行 PUT 之前，您可以要求服务器为您提供一个不错的 ID。尽管它感觉很重且不明显，但它也不能防止使用自己的随机 id 而不是要求它的虚拟客户端。

有人可以在这个架构问题上给我一个提示吗？

我正在构建一个基于 REST 的幂等 POST API 调用。我想实现幂等行为以避免客户端在网络故障和超时期间创建重复资源。客户端在每个 API 调用的请求标头中传递一个 ClientToken。我的 POST 请求具有标准有效负载，并且我有围绕它的验证逻辑。在重试期间，API 期望的理想幂等行为是什么？它应该仅依赖于 ClientToken 并忽略请求有效负载，还是应该在使用 ClientToken 调用幂等检查之前在请求有效负载上运行验证逻辑？

我不太明白 HTTP 动词是如何定义为幂等的。我读过的只是 GET 和 PUT 是幂等的。POST 不是幂等的。但是您可以使用不会更改任何内容的 POST 创建一个 REST API（例如在数据库中），或者为 PUT 创建一个每次调用都会更改的 REST API。

当然，这可能是错误的做事方式，但如果可以做到，为什么在实现时 PUT 被标记为幂等（或 POST 不是）？我没有挑战这个想法，我可能遗漏了一些东西，我要求澄清我的理解。

编辑：

我想提出我的问题的一种方法是：如果我使用 PUT 进行非幂等调用并使用 POST 这样做会有什么问题？