我有一个用例，需要在服务器和客户机之间按照pub/sub消息传递模式进行实时通信。生产商将使用java服务器、节点等，客户机将使用java桌面应用程序、移动应用程序（android/ios）、浏览器（javascript）。
我已经探索了下面讨论的许多选项，但我无法提出一个强大的可扩展解决方案。
用例：服务器将发布关于各种主题的通知/消息，所有订阅了一组主题的客户机（java/js/ios）将实时获得这些消息。
我遵循了3种方法来解决这个问题1>socketio/socketcluster 2>探索了使用mosquitto/rabbitmq作为代理的mqtt协议。3> 探索Kafka
其主要目标是使此体系结构具有高度可扩展性，不仅可以同时连接超过百万个客户端，而且每秒可以发布和使用超过百万条消息。
第一种方法简单易行，但websocket不是一个可伸缩的解决方案。
第二种方法是可行的，但是rabbitmq会创建大量的队列（百万个客户端有一百万个队列），因为它为每个连接到它的客户端维护队列，而且rabbitmq没有很高的消息发布和使用率，另外，假设我们有一个rabbitmq节点集群，那么只有一个节点用于处理请求，其他节点用于高可用性，而不是并行消耗。
第三，我研究了kafka，它以它的基准而闻名，我用kafka的高级javaapi创建了java客户机，这个api可以用来订阅一个kafka主题，发布到这个主题的任何消息都可以实时传递给客户机。
所以我的问题是，使用kafka客户机进行实时推送通知有多好，所有java桌面应用程序（可能有一百万个）都将包含这个kafka java客户机sdk，并订阅某些主题，在这里，我将每个客户机视为一个消费群。
这里还有一个主要的问题是，这个kafka客户机由于其scala依赖性而很大，所以在android中使用这个客户机将不是一个好的选择，我也不认为它会起作用。
mqtt在这里表现出色，因为它有用于android、java、ios等的官方phao客户端。
此外，我还没有在网上看到使用kafka进行发布/订阅消息的例子，大多数人都将其用于数据管道，例如：实时日志处理、向hdfs提供数据、分析引擎等、流处理。
主要的问题是，我如何使用mqtt协议（与android/ios/web/iot配合良好）和kafka作为消息代理（具有较高的发布/订阅率），并为这个问题提出一个可伸缩的解决方案。
我的用例在某种程度上也类似于uber，那里有上百万的android/ios设备（客户端），我们实际上可以在Map上看到我们所在位置的所有汽车的实时移动，有人知道这些汽车实时跟踪背后的架构是什么吗。