水平缩放在服务器之间共享input的应用程序
我正在构build一个应用程序，通过websocket接受input，这个input必须共享回其他可能连接到其他前端服务器的客户端。
为了简单想象一个多用户多房间聊天应用程序。 让input路由到正确的连接不是一个问题，它是服务器之间的消息传递，并能够扩展并保持消息的延迟。
现在我有一个每个前端连接到的代理程序，然后他们订阅一个队列来查看连接可能需要知道的任何事情。 这样做是为了切断接收来自前端永远不会使用的代理的消息。 不过，我仍然可以获得大约75％到85％的消息从经纪商发回到每个前端。
在旅行中，我正在做消息validation，parsing和任何其他业务逻辑的工作。 在旅途中我循环了本地数组的订阅，并将消息发送到每个订阅的连接。
例如：如果我在11个前端服务器上收到10条消息（总共110条消息 – 10条消息在本地处理，而不是由代理发回）* 0.75乐观预订级别= 75条消息被发送回每个服务器处理。 所以我们有10个本地+75个broker = 85个消息被每个服务器处理一段时间。
现在，我不会有100个每秒100个的前端服务器，也许是两个，但是通过代理程序发回给每个前端服务器的消息似乎会爆炸我通过其他前端服务器收到的更多消息。
代理进程是一个与RabbitMQ和PostgreSQL交谈的小型node.js应用程序。 前端服务器也是node.js应用程序。
我能做什么，或者应该采取不同的措施，以在大批量生产期间保持低延迟？
更新回复用户评论：虽然我期望在队列之间的连接会导致他们的前端服务器订阅，我不认为它是100％的每个服务器的重叠。 最糟糕的情况是，每个前端服务器都必须订阅代理上的每个队列，从而从代理获得100％的消息。 乐观地说，只有大约75％的消息确实需要被发回到任何特定的前端服务器。
itaifrenkel的第二次更新：两个用户发送的消息可能以不同的顺序返回。 只有在延迟非常低的情况下才可以接受，而且只有在发送的消息非常接近时才会发生。 如果它发生的消息秒分开，那么我会说我们有一个延迟和规模的问题。
有一种情况我们需要显示一个历史logging，但是由于我觉得这个问题超出了问题的范围，所以我把这个logging留下了。
消息队列解决scheme听起来像是正确的选项。 正如你在标题中所build议的那样，为了扩大这个范围，你需要水平。
我还没有和RabbitMQ合作过，所以我不能用细节把你吹走，但是横向扩展意味着一个集群，所以http://www.rabbitmq.com/clustering.html可能足以让你走。
我们假设每个用户在任何时候只连接到一个聊天室。 这意味着一个websocket连接=一个聊天室。 所以你可以写一个额外的node.js逆向代理，将每个用户连接转发到最前面的node.js进程，这个进程很可能已经在监听那个聊天室的事件了（聊天室关联使用基于聊天室ID）。 这种路由algorithm需要尽最大努力提高networking利用率，并不需要做到完美。
现在，让我们允许每个用户在多个聊天室中。 然后，您需要改进反向代理以连接到多个“前端”服务器，并将结果复用回用户。
这种devise将提供横向扩展性的networking延迟的代价。
注意：当然，新的反向代理现在是前端服务器，但是当我提到“前端”时，我会参考服务器，就像你在问题中描述的那样。