在服务器上管理 APNS 和 FCM 令牌答案

【问题标题】：managing APNS and FCM tokens on server在服务器上管理 APNS 和 FCM 令牌
【发布时间】：2020-04-19 15:47:31
【问题描述】：

我一直在尝试弄清楚如何在我正在编写的设备注册和推送通知服务器上管理 APNS 令牌。

问题的症结在于通过卸载和应用更新来唯一标识设备。甚至供应商的标识符也可以随着安装或更新而改变。似乎 Apple 和 Google 并不真的希望你能够做到这一点。

似乎有一些解决方法，例如在 iOS 设备上使用钥匙串和在 Android 上使用内部存储，但据我了解，其中至少一种方法需要用户许可，这可能会拒绝一些用户。我想尊重用户的隐私并与他们建立信任。

这是我到目前为止提出的逻辑：

存储推送令牌，这些令牌将由application Id、platform、user Id 和device Id 唯一标识（应用程序在本地存储中存储的唯一值） - 我们将此唯一标识符称为APUD Id
我们将拥有本质上是一个 upsert 端点（尽管我通常讨厌 upsert 或任何通用端点 - 似乎这可能是一个很好的例外情况），它需要更新令牌或其他设备数据并确定是否存在匹配的 APUD Id - 如果是，则更新该行，否则创建一个新行
当向特定用户的设备发送推送通知时，找到所有尚未软删除的匹配条目（在涉及多个服务实例时，硬删除可能更容易避免并发错误，但这是 OT - 理想情况下我们是为了支持和调试目的，至少将这些数据保留一段时间）。由于我们无法唯一标识设备，因此这些通知应使用适当的折叠 ID（应允许设备唯一标识通知）以防止用户收到重复通知。
如果 Apple 或 Google 响应指示令牌已过期/未注册，则软删除该条目。

问题：

【问题讨论】：

【解决方案1】：

逻辑看起来不错。它与我在一些答案中建议的方法相似（如果不相同）。

第 4 步可靠吗？有一个更好的方法吗？有没有办法通过 cron 作业主动管理过期的令牌？这会导致大量很少过期的代币堆积吗？

可靠到应该防止令牌积聚并防止不必要的推送请求。

是否有更好甚至更规范的方法来解决这个问题？

我还没有找到一个更好的 方法来处理除此之外的 FCM 令牌。

根据您拥有（或可能很快拥有）的任何其他规格，只需确保（尽可能：

【讨论】：