所以，我想问一些我无法理解的问题。例如，我有一个应用程序需要跟踪 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 实时数据库 Feed: Firebase RealTime Database 提供实时同步，似乎是最好的替代方案，但是考虑如果 APPLICATION_1 的 200 个用户正在更新 FireBase RDB，则成本仅适用于使用 APPLICATION_1 的那 200 个用户，而当 200 个 APPLICATION_2 用户和 200 个 APPLICATION_3 用户正在获取数据时同一个数据库，它的节点总数达到 600 个，这可能非常昂贵。 Firebase 的可扩展性是这里的问题。
套接字实现: 套接字是端口饥饿的。尽管它们的一对一连接是无缝的并且通信完美，但当节点数量急剧增加时，它们往往会成为问题。因此，如果服务器被用于大量数据处理过程，这可能不是完美的解决方案。
使用某种计时器的最佳方案 您将位置数据记录保存在本地，并且每 X 分钟或任何适合您的时间发送一次 并且接收应用程序也每 X 分钟更新一次 另请注意，Socket 连接从 android 7 开始受到限制 检查这个https://stackoverflow.com/a/49016500/1849543
关于java - 通过套接字或回调进行持续的服务器客户端通信，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55123752/
| 欢迎光临 OGeek|极客世界-中国程序员成长平台 (http://ogeek.cn/) | Powered by Discuz! X3.4 |