【发布时间】：2016-04-12 14:41:44
【问题描述】：
Azure 通知中心显示，从 13k WNS toast 通知广播中，只有 5k 消息成功，8k 出现“WNS Channel Disconnected”错误。什么会导致如此大量的错误？我可以检查什么，为什么会这样？
【问题讨论】：
-
您是向手机还是向 PC 发送通知（或两者兼而有之）？
标签： azure push-notification wns
【发布时间】：2016-04-12 14:41:44
【问题描述】：
这可能是因为频道不再有效，应该刷新。推送通知很难调试。你能说一下“13k push”的时间段是多少？
还可以查看 WNS 概述 - 它有“重要说明”部分 https://msdn.microsoft.com/en-us/windows/uwp/controls-and-patterns/tiles-and-notifications-windows-push-notification-services--wns--overview
还有一个关于调试通知中心的有用页面： https://msdn.microsoft.com/en-us/library/azure/dn530751.aspx
所以我会检查频道是否有效。
【讨论】：
-
感谢您的回答。我想我已经在 MSDN 上检查了所有可能的内容。有 26 个广播通知，每小时一个，针对不同的用户时区。我在那个通知中心总共有大约 21,000 个活动设备。对于过期的频道，我有 1.5k 的“WNS 过期频道错误”错误，我认为没关系。主要问题是我认为，Azure 会重试向断开连接的设备发送通知，一旦它们连接上，它们就会收到。也许您可以建议，如果我可以使用任何重试机制？
-
您好，抱歉耽搁了。 Azure NH 正在使用回退策略 - azure.microsoft.com/en-us/documentation/articles/… 并在 30 分钟后开始放弃推送。关于离线设备 - NH 将仅存储最后未发送的推送。它看起来像在你的情况下可能发生的事情吗？顺便说一句，使用服务总线资源管理器对其进行测试并查看您有多少错误很有用。你有可能这样做吗？
-
糟糕，请原谅 - 我错过了有关重试逻辑的问题。我会建议您使用检测推送状态和结果的逻辑来实施类似的退避策略。 blogs.windows.com/buildingapps/2013/10/22/…
-
感谢您的努力。我已启用标准计划以查看每个通知的丰富遥测。但是对于广播通知，我认为我需要重新设计，在我的后端拥有 Channel URI 并为每个人发送消息，然后跟踪它的状态。因为现在我只能看到传递/失败消息的计数。我曾尝试使用服务总线资源管理器，但在连接到服务总线命名空间时总是出现 500（内部服务器）错误，但我会尝试找出解决方法。
-
没有理由对断开连接的设备实施重试。 WNS 将在每个通道缓存多达 5 个 Toast 和 Tile，或在设备离线时缓存 1 个原始通知。在 toasts 上重试断开设备的通知可能只会导致重复的通知。仅当您从服务中收到 500 或 503 错误或 406 错误（意味着您的通知被限制）时才需要重试。在所有情况下，请确保在重试时使用指数退避，否则只会使限制变得更糟。