如何使用解析服务器正确设计可靠的确认机制

试图解决两个将军问题不太可能有成效。相反，请考虑如何设计一个可以容忍故障的系统。

您的推送通知可能永远不会送达。你的应用是否可以在将新数据置于前台时检查新数据，或者进行一些备份以使其仍然有用？

收到推送通知后，您的应用可能无法发送加载此数据的请求。是否可以依赖下一个通知，或者将其视为缺少的通知，并且仍然允许应用有用？

请求数据后，应用可能永远不会收到响应。同样，您如何确保该应用程序对其用户有用？如果及时传递此数据并不重要，则可以依靠重试机制。如果它很关键，也许您需要某种方式在看起来过时时警告用户。

哪种解决方案对您有意义实际上取决于您的应用正在做什么以及它为什么需要这些数据。

我会这样做：

1. 当应用程序发送到服务器请求新数据时，也发送ID码
2. 服务器存储此 ID
3. 当应用程序结束数据接收时，向服务器发送带有 id 的接收正常消息。
4. 当服务器从应用程序收到"接收正常"消息时，请从其列表中删除应用程序的 ID。

通过这种方式，服务器知道有多少应用程序要求数据传输以及有多少应用程序成功接收数据。

用于数据传输的应用程序 ID 可以在任何传输会话之间更改。