【问题标题】:What is advantage and disadvantage of using pubnub over Amazon Simple Notification Service (sns)? [closed]与 Amazon Simple Notification Service (sns) 相比,使用 pubnub 的优点和缺点是什么? [关闭]
【发布时间】:2013-12-30 16:37:26
【问题描述】:

对于我的团队项目,我需要建议我们应该使用 PubNub 还是 Amazon Simple Notification Service (SNS)。我发现 PubNub 的实现和使用非常简单,但我在 Internet 上找不到任何具体的东西来说明 Amazon SNS 的优缺点。

【问题讨论】:

    标签: amazon-web-services notifications push-notification amazon-sns pubnub


    【解决方案1】:

    PubNub 实时网络和 Amazon SNS

    原始答案来自 Quora:What are the advantages and disadvantages of using PubNub over Amazon SNS?

    PubNub Real-Time Network 和 Amazon SNS 都使用发布/订阅隐喻来发送和路由数据。然而,这是比较结束的地方。这两种服务提供不同的功能,解决不同的业务问题;一个不能替代另一个。

    发布到最终用户设备 PubNub 与 SNS

    PubNub 专门设计用于以低延迟(低于 0.25 秒 SLA)向最终用户设备(包括智能手机、平板电脑、浏览器和笔记本电脑)提供数据。这些设备可能位于防火墙、NAT 环境、手机信号塔机构和其他难以到达的网络环境之后。 PubNub 通过为每个设备维护一个始终打开的套接字连接,并使用这个打开的套接字连接以低延迟“推送”数据来实现这一点。 PubNub 提供超过 50 个客户端 SDK 库,通过简单的 PubNub 订阅 API 调用,可以轻松“插入”PubNub 实时网络。

    相反,Amazon SNS 无法访问客户端设备,除非通过电子邮件或 SMS 通知。因此,对于依赖低延迟数据的应用程序(例如多人游戏、聊天应用程序、协作应用程序等),Amazon SNS 不是适合这种环境的解决方案。 Amazon SNS 向订阅者发送数据的主要方式是通过电子邮件或 HTTP 回调。由于网络防火墙和设备安全原因,在移动、浏览器和桌面设备上运行 HTTP 服务器来接收这些通知是不切实际的。 Amazon SNS 的主要用途是服务器到服务器发布/订阅用例,或电子邮件和文本消息最终用户通知。此处对常见的 Amazon SNS 使用案例进行了很好的解释:What are good uses of Amazon's Simple Notification Service?。 Amazon SNS 不是用于应用内实时通知的正确工具。 Amazon SNS 更类似于 Tibco 或 Tuxedo,它们是服务器到服务器的发布/订阅系统。

    PubNub 实时网络与 SNS 的特点

    除了简单的发布/订阅之外,PubNub 实时网络还为任何类型的实时应用程序提供了一系列“构建块”服务。 Amazon SNS 或其他 Amazon 服务不提供这些服务:

    • PubNub Presence -- 提供用户在线的实时更新,并在他们离线时发出警报。这些更新是通过多路复用的 PubNub “姐妹通道”提供的,只要应用程序中的用户数量发生变化,该通道就会流式传输状态更新。一个名为“Here_Now()”的附加 API 还为应用中的用户提供了最新的计数。
    • PubNub 存储/播放 -- PubNub 自动存储发布到每个频道的所有数据,并提供两种检索这些数据的机制:(a) 一次检索所有数据的简单 REST 请求,以及 (b ) 一种用于“播放”此数据的播放机制,类似于用于电视录制的 DVR。
      PubNub 实时分析——PubNub 提供各种可视化和使用统计数据来显示用户活动、地理位置和使用情况。示例截图如下:

    • PubNub 离线移动推送 -- PubNub 还为移动应用程序未运行(或在后台)时向移动设备发送消息提供了一种回退机制。 PubNub 可以回退到移动“推送通知”,确保即使手机在口袋里也能通知移动终端用户。应用启动后,应用将再次开始使用 PubNub 的实时网络。
    • AES 加密 -- PubNub 提供开箱即用的 AES 256 加密支持,确保数据在通过 PubNub 网络路由时保持加密。虽然 Amazon SNS 提供 HTTPS,但这意味着数据在通过 Amazon 网络路由时是未加密的。这立即使 Amazon SNS 无法用于 HIIPA、SAS70 和其他具有安全意识的应用程序。
    • 多路复用 -- PubNub 通过允许所有数据主题通过单个 TCP 套接字连接流式传输的机制来增强多通道通信。使用 PubNub 多路复用,移动设备资源的节省最为明显,例如使用电池的手机和较慢的网络连接。数据通过可配置的窗口进行压缩和捆绑,以在不断变化的网络条件下提供更长的电池寿命和更好的最终用户体验。

    PubNub 与 SNS 的延迟(即“实时”)

    由于 PubNub 通过现有的、已建立的开放网络套接字传递数据,在 95% 的订阅设备中,从发布到订阅的延迟不到 0.25 秒。如果事件在 0.6 - 0.7 秒内被感知,大多数人会认为某事是“实时的”。 Amazon SNS 不提供延迟保证,并且绝大多数延迟的测量时间超过 1 秒,通常慢很多秒。同样,这有点无关紧要。 Amazon SNS 专为服务器到服务器(或电子邮件/SMS)通知而设计,在这种情况下,几秒的延迟通常是可以接受和预期的。

    频道/主题和多路复用 PubNub 和 SNS

    Amazon SNS 最多允许在一个账户上创建 100 个“主题”(请参阅​​Amazon Simple Notification Service (SNS))。 “主题”相当于 PubNub 频道。相反,PubNub 支持无限数量的 PubNub 频道。今天的一些客户通常每月使用超过 100 万个频道。这样一来,每个最终用户设备都可以拥有自己的一对一连接通道。

    此外,PubNub 对多路复用的支持允许客户端设备同时连接到多个 PubNub 通道,同时继续使用单个网络套接字。这允许客户端同时订阅,例如,专门与同一个人拥有的单个设备或一组设备配对的“私人”频道,以及一组或整个人群也可能订阅的“公共”频道.

    多路复用的另一个用例是流式股票价格应用程序:假设您要流式传输 1,000 种不同股票的股价变化。每只股票都有自己的 PubNub 频道。最终用户设备将使用 PubNub Multiplexing 仅订阅与他们想要跟踪的股票相关联的 PubNub 频道。

    由于 Amazon SNS 不支持多路复用,因此这种类型的用例是不可能的。

    可靠性和冗余 PubNub 实时网络与 SNS

    PubNub 实时网络分布在全球 12 个数据中心,并且还在不断增长。发布到 PubNub 全球云的所有数据都会在全球范围内自动复制,即使在整个数据中心出现故障的情况下,也能在全球范围内提供低延迟以及无与伦比的可靠性。 PubNub 为其实时网络提供高达 99.999% 的 SLA 正​​常运行时间。 Amazon SNS 是一个测试版产品,因此没有服务级别协议。

    PubNub 实时网络和 SNS 总结

    Amazon SNS 有多种有趣的用途,主要与服务器到服务器的通知和电子邮件/SMS 最终用户警报有关。它最初是作为一种在各种其他 Amazon AWS 云服务之间编排数据的方式而开发的,因此主要用于服务器后端操作和数据移动。

    PubNub Real-Time Network 旨在简化在移动设备、浏览器和桌面上构建实时应用程序,并在全球范围内扩展到数百万同时用户。如今,PubNub 已在全球超过 2,000 个应用程序中使用,涵盖社交、广告、游戏、电信和各种其他市场。

    【讨论】:

    • 这不是真的:“相反,Amazon SNS 无法访问客户端设备,除非通过电子邮件或 SMS 通知”。大约半年前,Amazon SNS 增加了通过 GCM 和 APNS 的原生消息传递。
    • @tster 你说得很好,谢谢你的更新。 :-) 我们提到“Amazon SNS 无法访问客户端设备...” 并指的是非第三方路由。基本上,GCM 和 APN 是前端加载连接的第 3 方供应商,而 SNS 仅从远处调用这些连接供应商。既然我们正在讨论 GCM 和 APNS,它实际上更像是关于 推送通知 的对话,这是一种不同类型的解决方案,也由其他公司提供。
    • 很明显,您对自己的身份很坦率,但在某些情况下,您所写的关于 SNS 的内容通常是在夸大事实。尽管您关于 SNS 是为服务器到服务器通信而设计的断言是正确的,并且您是对的,这些用例可能不是 SNS 上最简单或最好的用例。以下是一些更正:1)多路复用 - 您提到的用例可以通过将 SNS 和 SQS 与客户端长轮询 SQS 结合使用来轻松实现。
    • 2) 100 个主题 - 您可以在此处轻松请求增加主题数量:aws.amazon.com/contact-us/…
    • 3) 延迟 - 我不知道您从哪里获得 SNS 的数字,但它们肯定不是我所经历的。这对于电子邮件和 SMS 消息可能是正确的,但对于 http 和 SQS 消息,95% 的延迟应该比这要好得多。此外,假设服务器到服务器的应用程序对延迟不敏感是错误的。
    猜你喜欢
    • 1970-01-01
    • 2010-10-31
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-04-01
    • 2011-07-24
    • 2014-12-08
    • 1970-01-01
    相关资源
    最近更新 更多