基于geohashes的pubsub主题划分的建议,用于ably websocket连接服务

Question

我的问题涉及以下用例:

用例演员

• 用户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    ×   18.6mm

鉴于我们允许用户可能存在高达153米的误差(在用户可能想要订阅的区域上接收本地广播消息),这将需要一定数量的主题,这些话题肯定已经太大,甚至只能覆盖整个布鲁塞尔地区.
所以我目前仍然处于这个水平.

Answer 1

1. 酒吧网站

PubNub 是目前唯一通过 websockets 提供开箱即用的 geohash pub-sub 解决方案的服务，但其定价非常高（500 个连接设备的成本约为 49 美元，20k 设备的成本为 799 美元）更新：PubNub 现已更新价格拥有无限的设备。网站更新即将推出。

Pubnub 正在研究他们的定价模型，因为他们的一些客户为意外的流量激增支付了很多费用。

然而，对于向所有人开放的通用广播消息应用程序来说，这并不是一个可行的解决方案，因此流量非常难以预测。

这很遗憾，因为否则这项服务对我们来说将是完美的解决方案。

2.阿布利

Ably 提供了一个 pubsub 系统，可通过自定义通道的 Websocket 将数据流式传输到客户端。当客户端附加自身以发布或订阅该频道时，会动态创建频道。

这里的主要问题是：

• 如果我们想要高的geohash精度，我们需要大量的通道，因此我们必须支付更多的费用；
• 如果我们采用较低的 geohash 精度，将会出现大量冗余消息：假设我们采用一个由 4 个字符的 geohash 表示的通道，跨越 39.1 x 19.5 km 的地理区域。

发送到该频道的任何帖子都将被多路传送给该区域内当前正在收听的每个人。

然而，假设我们的应用程序允许的最大半径为 10 公里，并且一半的连接用户将其设置为 1 公里半径。

这意味着 2 公里半径之外的所有帖子都将不必要地多路复用给这些用户，并且将被丢弃而不再有任何进一步的使用。

我们还应该考虑这种方法的可扩展性。对于生产者或消费者需要的每个 geohash，将创建另一个通道。

拥有一个需要基于全球地理哈希的主题的应用程序肯定比一个仅需要基于主题的主题的应用程序更昂贵。

也就是说，在全球范围内采用时，主题数量急剧增加，价格也会随之增加。

另一个考虑因素是我们的应用程序需要额外数量的通道：

• 通过 geohash 和群组：我们的应用程序允许创建基于地理位置的群组（相当于 Twitter 的 #hashtags）。
• 按地点
• 由关注的用户（高级功能）

尽管有以下几点，但这种方法有一些乐观的考虑：

• 仅当新闻源处于活动状态时才需要流式传输：当用户打开浏览器窗口并显示我们的网站时+当用户使用移动设备并主动打开相关源时
• 可以进行进一步的优化，例如仅在 feed 刷新后 10 到 20 秒内开始流式传输
• 根据当前活动，按地点/关注的用户进行流式传输可能具有较高的流量，但许多地点频道也将处于空闲状态

在这方面，一个非常重要的注意事项是 Ably 如何向消费者计费，这可以充分利用我们的优势：

当发生以下任一情况时，通道将被打开：

• 通过 REST 在通道上发布消息
• 实时客户端连接到通道。该通道在客户端附加到该通道的整个时间内保持活动状态，因此，如果您连接到 Ably、附加到通道并发布消息但从未分离通道，则只要该连接保持，该通道就会保持活动状态打开。

当满足以下所有条件时，打开的通道将自动关闭：

没有更多实时客户端连接到该通道 自发布最后一条消息以来已经过去了至少两分钟。我们使通道保持活动状态两分钟，以确保我们可以在通道上提供连续性，作为连接状态恢复的一部分。

举例来说，如果您有 10,000 个用户，并且在每月最繁忙的时间，会出现一个峰值，其中 500 个客户与 Ably 建立实时连接，并且每个客户都连接到一个唯一频道和一个全局共享频道，则频道的峰值数量将是每个客户端 500 个唯一通道和一个全局共享通道（即 501 个峰值通道）的总和。如果整个月这 10,000 个用户中的每一个都连接并附加到自己的唯一通道，但不一定在同一时间，那么这不会影响您的峰值通道数，因为峰值通道是在任何时间点打开的并发通道数那个月里。

乐观的结论

最重要的结论是，我们应该考虑到这个功能对于应用程序的第一个版本可能并不像人们想象的那么重要。

尽管 Twitter、Facebook 等提供了接收实时更新的功能（并且用户已经开始期待它），但我们应用程序的有限规模的初始测试版可以在没有此功能的情况下运行，即用户必须刷新才能接收新的更新。

在应用程序首次启动期间，可以收集统计数据以更深入地了解详细的用户行为。这将使我们能够根据事实数据建立更可靠的基础设施和财务反映。