做一个实时的socket.io node.js应用程序中的多个Web dynos是否有意义？
我正在为heroku上的实时聊天应用程序开发一个node.js后端。 当我在研究dynos和扩展node.js后端的方法时，我可以看到dynos可以在http服务器上拥有的优势，因为每个dyno都可以独立于其他dynos（对于大多数情况来说是可以的）。
我的问题是：如何扩展和处理实时socket.io应用程序的负载平衡？ 从我正在阅读的dynos是容器是'沙箱'：每个dyno运行自己的过程，独立于其他dynos ..那么处理这个问题最好的办法是什么？
我正在考虑一个解决scheme，但它并不优雅或漂亮：
我可以有多个后台作业，其中包含crons可以检查连接在该实例上的用户的新消息..但我认为必须有一个更好的解决scheme。
这个问题可以概括为如何让多个节点进程共享数据，而不pipe他们在相同或不同的服务器上。 据我所知，传统的观点是让所有的进程使用普通数据库（Postgres，Mongo，Redis）来读写数据。 只需使用正确的数据库来满足您的需求。
另一种select是像MessengerJS那样允许进程间通信。 我不知道这是否是您的应用程序的好主意，因为那么所有的dynos最终都会包含聊天数据的副本。 然后由你来确保在所有的dynos之间所有的东西都是同步和一致的。 我会更倾向于把数据库作为单一的事实来源。