这个问题分为两部分。
我在 IIS 6 中托管了一个单向 WCF 操作。以下是我对其工作原理的理解：
_1。IIS 收到一个请求。
_2。IIS 发送 HTTP 202 响应（谢谢，我稍后会处理）。
_3。IIS 调用我的单向 WCF 操作。
现在控制传递给我的 WCF 操作，它执行以下操作：
_4。将请求信息保存到事务性的持久存储中。
_5。开始处理 OLTP 数据库中的请求。
_6。如果出现错误，请从第 5 步开始重复，或采取一些补救措施，然后清理第 4 步中保留的数据。
我对 IIS 何时发送 HTTP 202 响应的理解是否正确？
如果 IIS 在第 2 步和第 4 步之间循环，我可能会丢失请求信息，然后再进行更改以保留它，但在客户端认为我已接受该消息之后。当有未决的请求时，IIS 是否提供了关于何时回收或不回收的任何保证？
PS：请原谅狡猾的格式。出于某种原因，降价完全搞砸了我的编号列表项。
我不确定你的假设是否正确。
即使是单向交互，在返回 202 之前，WCF 也可以非常投入；例如，如果您使用身份验证，则这一切都必须在调用方法和返回 202 之前发生，这样如果有任何问题都可以报告。
例如，如果您使用开箱即用的 wsHttpBinding，您将在实际方法调用之前看到 2-3 次消息交换，导致 200 次。这是为了交换安全信息并建立安全上下文。
诚然，如果您将服务配置为没有安全性，则不会发生这种情况，它会立即返回 202，但这表明它必须知道它是否可以从 WCF 堆栈中做到这一点。
除了所有这些 - 我不确定你想要实现什么 - 你指的是哪个 IIS 回收？我根本不是 IIS 专家，但我怀疑它会在某些东西正在积极执行时回收主机；如果您指的是手动重新启动应用程序池（或 IIS，或与此相关的机器）的任何人，我怀疑您可以做很多事情。
如果您必须确定消息不会丢失，那么我知道的唯一保证方法就是以一种或另一种方式采用可靠的消息传递，它只确认请求一旦持久存储在持久存储中；
在我看来，有几件事我会建议：
我知道在 IIS 中管理进程回收的唯一方法是查看您的网站正在使用的应用程序池。如果您打开 IIS 管理器 -> 应用程序池 -> 选择您的池，然后右键单击属性，在“回收”选项卡上，其中的选项可能会对您有所帮助。我想这并不能保证您不会在回收中丢失请求，但设置更长的时间会降低这种情况的可能性。
但是，听起来您要构建的系统是 MSMQ 的理想候选者，它可以提供异步服务请求，这些请求可以正确排队，而且开销或手动管道非常少。这将使您完全避免整个过程的回收问题。我不确定这是否适合您的方案，但可能需要研究一下。