是否存在幂等的哈希函数？我知道 MD5 和 SHA256 不是：

有没有可以做这样的事情的哈希算法？

如果确实存在这样的算法，它在密码学上是否有用？即有合理的输入，用已知输出猜测输入在计算上是不可行的吗？

如果这样的算法不存在，它不存在是因为没有人费心去寻找它，还是在数学上不可能？

语境

我正在开发一个用户可能希望在密码管理器中保存密码的系统。特别偏执的用户可能更喜欢以散列形式而不是纯文本形式保存密码。我希望用户能够使用此散列密码进行身份验证。而不是简单地尝试两次身份验证（一次假设用户的密码被散列，一次假设它不是），我想知道是否有一种算法让我只做一次。

我知道有允许用户存储身份验证令牌而不是纯文本密码的替代方法。但是这个想法突然出现在我的脑海中，我很好奇。我在 Google 或 SO 上找不到任何关于此的内容。

编辑：我并不是建议允许用户使用散列密码进行身份验证意味着服务器不加盐/散列密码是可以的。服务器仍必须对原始密码或客户端哈希密码进行加盐/哈希处理。

编辑：我并不是说允许用户使用客户端哈希密码登录是真正的安全改进。据我所知，这将增加的唯一可能的好处是，如果用户将此密码用于多个目的。在这种情况下，如果攻击者发现了用户的哈希密码，那么只有对我的服务的访问会受到威胁，而不是所有共享该密码的服务。但是，最佳做法是不要对多个服务使用相同的密码。

我正在使用轮询消费者模式从给定的只读目录中读取所有文件并进行处理。是否有忽略幂等性的选项？

我知道用 noop=true & idempotent=false 定义的路由会导致整个系统崩溃（无限循环），但池消费者模式是一次性操作，在给定时刻触发。

语境

我有一个 REST API，其中多个客户端（应用程序）可以使用 PUT 更新资源的状态。例如，此资源是您可以打开ON或的灯OFF。

当检测到发生电力故障时，系统也会自动更新此资源，从而导致灯处于BROKEN状态。我要区分BROKEN和OFF，一盏灯BROKEN不能转动ON！

问题

我使用PUT 方法来做到这一点，比如PUT http://address:port/my_lamp { "state": "ON"}

但我不确定我是否尊重PUT方法的幂等性。事实上，我有3个案例：

• 灯是ON。上面的代码导致ON状态。
• 灯是ON。上面的代码导致ON状态....酷！此时，幂等性仍然得到保证:-)！
• 灯是BROKEN。上面的代码会导致错误，比如503 Service Unavailable

问题

我不确定是否正确理解幂等性的概念。相信我，我读了很多关于它的东西，但仍然有点困惑。

在我的理解中，多个PUT总是导致资源的相同状态：在我的情况下不能保证，因为BROKEN

但我也可以用另一种方式理解它：多重PUT总是导致相同的副作用：保证，我的请求要么产生 turn ON，要么什么都没有（对于这种BROKEN情况，它已经存在）。

编辑：

看这里：REST DELETE 真的是幂等的吗？

哪一个是正确的？根据理解，我的 REST API 是否确保幂等性......

编辑2：

方法还可以具有“幂等性”，因为（除了错误或过期问题）N > 0 个相同请求的副作用与单个请求相同。

我可以认为打开灯是错误ON的BROKEN吗？

考虑以下场景：启用了重复数据删除的 Azure 服务总线，具有单个主题、单个订阅和订阅该队列的应用程序。

如何确保应用程序从队列中接收消息一次且仅一次？

这是我在应用程序中用于接收消息的代码：

我预见的问题是，如果message.Complete()由于某种原因失败，那么刚刚处理的消息将保留在 Azure 中的订阅队列中。再次ReceiveMessages()调用时，它将从队列中获取相同的消息，并且应用程序将再次执行相同的工作。

虽然最好的解决方案是具有幂等域逻辑 ( DoWork(payload))，但在这种情况下很难编写。

我能看到的确保一次且仅一次交付给应用程序的唯一方法是构建另一个队列以充当 Azure 服务总线和应用程序之间的中介。我相信这被称为“持久的客户端队列”。

但是我可以看到这对于许多使用 Azure 服务总线的应用程序来说是一个潜在的问题，那么持久的客户端队列是唯一的解决方案吗？

在阅读了大量关于 Azure WebJobs 的网络信息后，文档说工作应该是幂等的，另一方面，博客说他们使用 WebJobs 来执行诸如“向客户收费”、“发送电子邮件”等操作。

该文档说，在具有队列的多个实例上运行连续的 WebJob 可能会导致多次调用。人们真的忽略了他们可以向客户收取两次费用或发送两次电子邮件的事实吗？

如何确保可以在扩展的 Web 应用程序上运行带有队列的 WebJob，并且消息只处理一次？

这是关于 GET 方法的一般问题。

想象一下，我需要存储用户选择的最后一个分页大小：

浏览产品列表当然是 GET 请求，更改分页大小也是 GET 请求（我们只更改size参数）：

每次用户更改尺寸时，我都需要在后端存储新尺寸。

如何处理GET不应该改变状态的事实？发出查询（从而改变应用程序的状态）对我来说是错误的。有没有其他选择？

GET 请求指定资源的表示。使用 GET 的请求应该只检索数据并且应该没有其他效果。

从我看到的大量文章和商业 API 中，大多数人通过要求客户端提供 requestId 或 idempotent-key（例如https://www.masteringmodernpayments.com/blog/idempotent-stripe-requests）和基本上将 requestId <-> 响应映射存储在存储中。因此，如果有一个请求已经在这个映射中，应用程序将只返回存储的响应。

这对我来说一切都很好，但我的问题是如何处理在第一个电话仍在进行时第二个电话打进来的情况？

所以这是我的问题

1. 我想理想的行为是第二​​个调用一直等到第一个调用完成并返回第一个调用的响应？人家是这样的吗？

2. 如果是，第二个呼叫应该等待第一个呼叫完成多长时间？

3. 如果第二个调用有等待时间限制，而第一个调用仍未完成，它应该告诉客户端什么？它是否应该不返回任何响应，以便客户端超时并重试？

在 RESTful 架构中，POST 请求既不是Safe也不是Idempotent。

现在，jQuery 的 ajax 调用允许重试失败的请求，方法是设置 ajax 调用以使用该函数来捕获失败，并可选择重试调用（以及相关设置，error例如timeout、和）。tryCountretryAfterretryLimit

重试 GET 调用不是问题（因为它们既安全又幂等），但是应该如何重试 POST 调用呢？

例如，假设我们使用 ajax POST 插入一条新记录：

1. 在客户端上启动 ajax POST 调用。
2. 服务器接收到调用，并更新数据库。
3. 服务器响应，但此响应未能传递给客户端。
4. 所以客户端假设有一个失败，并重试调用。
5. 服务器再次接收到该调用，这又进行了一次更改。
6. 等等...

满足这种情况的最佳方法是什么？

请记住，我对休息和建筑服务有基本的了解。我问这个问题主要是因为我试图通过提供一个前端以可扩展的方式运行异步作业，从而将服务与调用 CLI（在同一主机内）分离。

我想构建一个可以提交异步作业的服务。该服务应该能够告诉我工作的状态和结果的位置。

问题 第二个 API GetAsyncJobStatus 违反了幂等性原则。

• 在我们需要更新特定作业进度的 API 中，幂等性如何保持？
• 在这种情况下是否需要幂等性？

我正在评估一种使用 HyperLogLog [ HLL ] 实现域服务幂等性的方法。

这种方法的目的是提供确保幂等性而不存储大量无用信息的通用方法。唯一的要求是容忍偶尔的重复（发送 2 封电子邮件而不是 1 封）。

在我的场景中，每个服务请求都是一个带有 toHashCode 函数的消息对象。该算法如下所示：

1. 收到请求后，域服务计算 HLL[ S1 ] 基数并将其存储为C1。
   
2. 请求hash[ H ] 被添加到HLL[ S2 ] 的副本中，并且基数存储为C2。
   
3. 如果C1 == C2则请求被复制并且S2应该被丢弃。
4. 否则请求将被处理，hash[ H ] 将被添加到 HLL[ S1 ]。

有没有人遇到过类似的解决方案？（如布隆过滤器）
这种解决方案的缺点是什么？