Websockets推送通知

Question

以Instagram这样的iOS应用为例。Instagram基本上是一个实时应用程序，每当用户与您交互时都会更新它的UI。例如，如果有人喜欢你的帖子，而你正在使用这个应用程序，用户界面就会被更新以触发多巴胺的释放，并告诉你某些东西已经触碰到你的某个帖子。类似地，当有人在instagram上给你发送一条直接消息时，当你使用该应用程序时，你会看到消息从顶部弹出，所有这些都是实时的。

在实现这些实时特性方面，显而易见的是，天真的HTTPS轮询方法效率太低。因此，这就剩下两种战略：

( 1.)推送通知：

当用户喜欢一个帖子，发送一个直接的消息，评论(等等)，发送一个HTTP到后端服务器，然后更新数据库，并发送一个无声的苹果推送通知给接收者的设备。正在使用该应用程序的接收方将接收被推送的有效负载，并将一个HTTP发送到后端服务器以获取所需的数据(即。发送的直接消息的内容)。UI以准“实时”的方式更新。

( 2.)Websockets:

每当任何用户打开iOS应用程序时，都要通过websocket将用户连接到服务器。这意味着，所有正在使用该应用程序的用户都通过自己的websocket连接到服务器。当用户喜欢一个帖子，发送一个直接的消息，评论(等等)时，应用程序通过套接字向服务器发送一条消息，指示操作。服务器在更新数据库之前，将查找与收件人关联的套接字，并通过套接字将消息转发给收件人。接收消息后，用户界面将实时更新。

这些方法中哪些是可扩展的，更适合于生产环境？

Answer 1

您会喜欢websockets +组合框架，事件驱动可以顺利更新您的UI。在交付能力和资源/数据库成本方面，an可能有些不可靠，对我来说更像是一个信息中心。

喜欢websockets的理由：

• 降低了DB成本(例如，查找发送设备)--您知道，当用户不使用该应用时，
• ，降低了出站数据成本
• 延迟，以及更快的实际操作(更深入地介绍websocket段落)--

要回答这个问题: websockets显然基于用户计数是可伸缩的。APNS在CI中不是服务器端可测试的，也不是跨平台的，在资源消耗方面也不完全可行。

我对websockets有偏见。但是为了说明我为什么更喜欢它，请考虑一下Instagram的例子所给出的效率。

对我来说，websockets事件驱动，APNS是一个简单的信息中心。

亚太网络：

您注册了APNS，然后将设备保存在后端。很好，每次执行一个动作，比如某人喜欢你的帖子，查询你的后端，找到连接到OP的设备，然后把它发送出去(如果你考虑云计算成本的话，这要花钱)。每次有人喜欢你的帖子时，你都要这样做(显然你可以聚合，但当你有websockets的时候，为什么还要麻烦呢？)所以数据库成本是考虑的一回事。此外，用户可能正在静音通知。我没有Instagram，但从效率上讲，他们可以做的事情(如果不是通过套接字)是更新他们的UI基于传入通知的喜欢/心脏，而不是一个websocket连接。如果将其标记为垃圾邮件，则延迟时间较慢，成本较高，且不可靠。然而，APNS与websockets不同，它的好处是不需要授权，但是.

Websockets：

当我们接近websockets时，您只授权一次(至少对于移动应用程序)。通过删除标题之类的内容，您将删除出站数据成本(就$$和延迟而言)。您希望发送小块数据，而套接字只是发送文本/二进制(我喜欢使用JSON创建命令。一个值得注意的例子是GitHub)。当您的用户完成应用程序，您关闭连接，您不需要再发送数据通过APNS。您的服务器本身可以通过Redis PubSub之类的工具与单个websocket进行通信，以便在不需要发送推送通知的情况下使用POST请求来发送邮件时更新您的UI。这是一个胜利者(他不需要等待推送通知被发送)，或者如果你把它卸载到一个后台任务( OP不需要等待)。Websockets ==事件驱动：

经常发送的

• 小数据块(在很多情况下)要比实际发送速度慢的APNS要好得多，特别是当您向苹果/用户发送大量通知，将您标记为垃圾邮件时。不过，免责声明，这只是我个人的信念和猜测，取决于您的用例。
• 您正在删除那些不必要的数据库成本。
• A的缺点是保持连接的活力。

就我个人而言，最近我已经在一个聊天应用程序中使用了结合框架的websockets，但是它可以在许多不同的情况下使用。更新Facebook提要/评论部分，通过websocket (而不是APNS )实时通知，甚至发布内容。

Answer 2

APNS并不一定会被交付，特别是如果您有大量的通知--我不记得我在哪里读到的，但是在每分钟达到某个阈值之后，它就会停止工作。另外，你必须把它们发送给你的所有用户，而不仅仅是在线用户。发送无声通知是可能的，但仍然不是最优的。

这就是为什么websocket是首选的方式。此外，您还可以使用像https://github.com/centrifugal/centrifugo这样的工具，它是服务器的助手，可以保存所有的连接，并且非常稳定。

Answer 3

它不是两个中的一个，即使是web套接字也不是故障安全的，但所有这些都应该考虑到有效的通信，当应用程序在前台时使用web套接字监听服务器的任何更新，如果web套接字连接不活动或者没有确认响应通过APNS/FCM传递更新，那么当套接字发送时，它不保证从客户端发送更新，当下一个套接字连接成功时，交付更新。