如何为停机时间设计Azure主题订阅服务器而不丢失消息？

如果我有一个Azure主题，并且对于添加到主题中的每一个类型为X的事件，我需要一个订阅服务器将该事件记录到一个位置，而我需要另一个订阅服务器实际对该主题消息进行一些处理

什么是正确的设计来处理我的审核或处理订阅服务器的失败几分钟，并确保我不会错过任何主题消息并创建数据损坏场景

---

我可以运行每个实例的三个版本，然后这三个版本不太可能同时关闭，但这不是一个完美的场景。还有什么其他的选择呢？作为API的一部分，我是否遗漏了什么

我可能不理解您试图解决的问题。如果我正确理解了您的场景，那么您有一个审计订阅和一个处理订阅，订阅和“事件主题”。这意味着您将有两个逻辑使用者：一个用于审计，另一个用于处理（我说逻辑是因为每个使用者可以有多个实例从同一订阅读取吞吐量和冗余）

如果您在订阅客户端上使用PeekLock（默认）作为接收模式，这意味着如果在记录审核消息或处理事件时消费者出现故障或异常，则消息最终将重新出现，以供另一消费者实例处理。这假定由于异常而未调用Complete。理论上，如果您的审计和处理消费者正在执行幂等运算，那么即使您的消费者失败了，他们也可以在重新联机时赶上，并且不会错过任何消息，尽管有些消息可能会被多次接收。如果按照上面的建议运行每个使用者的多个实例，则这一点不会改变。运行每个使用者的多个实例确实减少了可能的停机时间，但即使只有一个实例在处理，也不应错过任何消息。订阅将保留它们，直到消费者恢复

如果使用ReceiveAndDelete接收模式，则可能会丢失消息。这是一篇关于这个问题的好文章。通读这个

根据审计和处理操作的资源密集程度，有各种各样的部署选项。您可以有一个工作者角色或进程，该角色或进程成对处理不同线程上的审核和处理消息，并部署多个实例。这意味着每个实例都可以处理这两种类型的消息，但存在冗余，如果其中一台机器发生故障，另一个正在运行的实例可以继续处理

您需要检查死信消息（如毒药消息）以及未处理或可能未完全处理的消息

---

现在，您确实提到了数据损坏，所以我假设您指的是审计日志被写入，但实际事件无法处理的可能性。这有点棘手。这是两个截然不同的操作，你正试图结合起来。简单的答案是，你不能保证这不会失去同步。这两个操作之间没有事务（您也不希望在分布式系统中有事务）。将审核视为执行操作的意图，而不是操作实际完成。不能仅仅因为消息已提供给系统，就认为处理将成功完成。一旦处理发生，它可以记录操作实际上已经完成。或者，它可能会抛出一条信息，让另一位审计员记录下来。这将为您的系统提供更好的分析指标：请求的操作数与实际完成的操作数。在一段时间内查看时，此指标可以为您提供系统的实际成功吞吐量

如果我很了解你，你可以让订阅者停机，消息将保留在订阅中。当订阅服务器重新启动时，它将在停机期间找到发送到主题的消息。所以你不需要三个订户来保证安全