标签: ably-realtime

我正在评估Pusher和PubNub,以便在我的主要Web客户端和我的服务器之间实现双向实时通信.两者看起来都令人印象深刻,Pusher的文档看起来更好,而PubNub的可扩展性和可靠性显然是他们的强项.

但是,由于我正在管理预算,我担心Pusher和PubNub的成本可能会成为我们的问题,因此我正在考虑使用其中一个开源替代品 - 我主要关注的是Socket.io,Faye和jWebSocket.

尽管我自己运行服务,但我有自己的顾虑:

• 有没有人之前实际上将Socket.io或其他开源解决方案扩展到多个服务器？PubNub声称每秒处理1M消息!,我有点怀疑Socket.io可以做到这一点,没有一个不可思议的服务器数量,如果它可以工作.
• 如果我使用开源解决方案,我可能会错过付费服务中的功能吗？
• 如果我在AWS上拥有我的服务器,延迟真的会成为一个问题吗？PubNub位于多个位置,所以我希望这可以减少延迟,尽管如果需要从美国发送消息到日本,在日本拥有服务器将无助于延迟,因为它仍然需要以某种方式在那里旅行.

感谢您的建议.

我的问题涉及以下用例:

用例演员

• 用户A:设置广播区域并使用实时帖子查看流的用户.
• 用户B:从用户A设置的广播区域内发送广播消息的第一个用户.
• 用户C:从用户A设置的广播区域内发送广播消息的第二用户.

用例说明

• 用户A选择他想要接收直播消息的边界(半径)的广播区域.
• 用户A打开livefeed并请求一组初始的livefeed项目.
• 当用户A的实时馈送仍然打开时,用户B从用户A的广播区域内广播消息.当用户A的实时进纸打开时,带有1个新的实时进纸项目的标签会显示在其上方.
• 当用户C从用户A从所选广播区域内发布另一个实时馈送帖子时,标签计数器递增.

用户A收到类似于Facebook示例的通知:

我认为应用的解决方案(我认为是Pubnub使用的)是为每个geohash创建一个主题.
在我的情况下,这意味着对于每个广播消息的用户,它需要发布到geohash主题,并且客户端(app /网站用户)将通过websocket消耗geohash主题,如果它落在定义的区域(半径).Ably似乎使用Web套接字提供这种可伸缩的服务.

我猜它会简化为这样的:

所以这意味着需要从发送广播消息的当前位置提取geohash.此geohash应具有足够小的粒度,以便接收用户可以设置或多或少准确的广播区域.(即如果我们希望允许用户定义接收实时消息的广播区域,那么geohash应该具有足够的准确性,这意味着如果我们决定扩展,则应该期望相当多的主题).

选项2是为具有较小特定粒度(覆盖较大区域)的geohash创建主题,并让客户端根据与消息一起发送的latlng值来处理准确性.
然后,客户端将决定是否删除消息.但是,这意味着发送更多消息(更多开销),并且成本更高.

我没有这种架构的经验,并质疑这种方法的可行性/可扩展性.
你能想到这个问题的另一种解决方案,以达到预期的效果,或者提供更多关于如何解决这类问题的见解吗？(我也考虑过使用常规的req-res流程,但这意味着垃圾邮件服务器,这似乎也不是一个很好的解决方案).

我实际上检查过.
鉴于161.4平方公里的区域(如布鲁塞尔地区),按字符串长度划分的地理位置如下:

1   ? 5,000km   ×   5,000km
2   ? 1,250km   ×   625km
3   ? 156km     ×   156km
4   ? 39.1km    ×   19.5km
5   ? 4.89km    ×   4.89km
6   ? 1.22km    ×   0.61km
7   ? 153m      ×   153m
8   ? 38.2m     ×   19.1m
9   ? 4.77m     ×   4.77m
10  ? 1.19m     ×   0.596m
11  ? 149mm     ×   149mm
12  ? 37.2mm …