所以，我想问一些我无法理解的问题。例如，我有一个需要跟踪 APPLICATION_1 位置的应用程序，该位置正在 Firebase 实时数据库中更新，我的服务器会进一步使用它。现在我想在另外两个应用程序上显示这个连续位置。做一些 Rnd 我开始了解套接字实现，但考虑到我有 200 个用户使用 APPLICATION_1，并不断向 Firebase DB 提供数据，然后通过服务器将其进一步提供给 400 个最终用户，这意味着为此目的维护或保持 400 个套接字打开.这对我的服务器来说似乎是一个非常糟糕的选择，因为它会滞后并且可能最终没有响应。但是，如果我使用备用回调递归 API 来 ping 服务器以获取 APPLICATION_1 的 200 个用户的实时位置，那也是一个糟糕的解决方案。在为这个特定问题实现解决方案时，我有点停滞不前。限制是我只有 1 个服务器和 3 个应用程序可以向其提供数据，而且可以供许多用户使用。
更新
经过深思熟虑，我得出以下结论:
建立 Kafka 连接: 正如 Youtube 或其他流媒体数据站点所做的那样，该平台需要缓存其资源并通过流提交它，就像目前由 Kafka 所做的那样。因此，需要在所有平台端为 Kafka 流编写一个包装器，例如 web 包装器、ios 和 android 包装器。然而 Youtube 所做的是，无论距离多远，它最初都会在客户端和服务器之间建立一对一的连接，但是由于 Youtube 是一个更大的平台，如果感觉有更多的用户使用这个流，它会让实际流的副本并将其发布到附近的服务器上，从该位置接收它的客户端将转移到该服务器。我们不能这样做，因为我们的服务器功能有限。
实现回调 API: 很好地实现 Callbacks API 最初看起来非常递归和糟糕的实现，但后来我为物联网平台研究它并发现 IOT 实现了另一种 API 调用协议(protocol)，MQTT ，这是一种更轻、更耐用且不占用资源的解决方案。然而，这也需要 Promises(需要深入研究)。
直接获取 Firebase 实时数据库提要: Firebase RealTime Database 提供实时同步并且似乎是最好的替代方案，但是考虑如果 APPLICATION_1 的 200 个用户正在更新 FireBase RDB，成本仅适用于使用 APPLICATION_1 的那 200 个用户，而当 200 个 APPLICATION_2 用户和 200 个 APPLICATION_3 用户正在获取数据时同样的数据库，它需要总节点到 600，这可能非常昂贵。 Firebase 的可扩展性是这里的问题所在。
套接字实现: 套接字端口饥饿。尽管它们的一对一连接是无缝的并且通信完美，但是当节点数量急剧增加时它们往往会成为问题。因此，如果服务器用于大量数据处理过程，这可能不是完美的解决方案。
最佳答案
使用某种计时器的最佳方案 您将位置数据记录保存在本地，并且仅每 X 分钟或任何适合您的时间发送一次 并且接收应用程序也会每 X 分钟更新一次 另请注意，套接字连接已从 android 7 开始受到限制 检查这个https://stackoverflow.com/a/49016500/1849543
关于java - 通过套接字或回调的连续服务器客户端通信，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55123752/