使用TCP进行跨进程的内存共享
我一开始就没有使用Redis或Memcache或其他内存存储系统，因此在nodejs上犯了一个错误。 现在，重写所有的东西来调整和关联这些API中的代码已经太迟了。
不过，我最近刚刚发现了分叉过程，以及它们有多大的益处。 特别是因为我正在做一个游戏服务器。
我nodejs的问题是： 内存不在nodejs内核之间共享 ..直到我find一个名为Amensia的TCP内存共享模块。
nodejs ，我对于nodejs和tcp有一些疑问：
1） TCP数据包的最大大小约为64K，所以使用这个模块时我只能共享64K的数据？
2）我使用全局的GAMES和users对象来存储玩家数据。 当玩家在地图上移动（x，y位置）和其他动作时，这些对象被更新。 通过TCP发送所有这些数据是否会导致瓶颈？
1）你不应该有TCP数据包大小的问题。 如果数据太大，节点会caching/排队数据，并在操作系统给出可写的套接字文件描述符时发送数据。 只有在每秒写入更多的networking带宽的情况下，才会出现性能问题。 此时Node还将使用更多的RAM来排队所有这些消息。
https://nodejs.org/api/net.html#net_socket_buffersize
2）大多数游戏使用TCP或UDP进行实时通信。 与其他任何东西（RAM，CPU，带宽，存储）一样，它可能是一个瓶颈。 在某些压力下，一个或多个资源将会结束/失败/performance不佳。 当所有的瓶颈优化完成时，使用可以水平增长的架构（添加更多的机器）通常是一个很好的做法，而且您仍然需要向游戏服务器添加更多的并发用户。
https://1024monkeys.wordpress.com/2014/04/01/game-servers-udp-vs-tcp/
您可能会使用TCP连接到Redis服务器（但您也可以使用unix套接字）。
如果您只需要进程间通信（而不是机器间），则应该查看“集群”Node.js核心模块。 它有内置的IPC。
一个最小的开销方法
使用进程间智能消息传递层来装备所有localhost分叉进程。
这样，您的“共享”就可以在抽象意义上和（在ZeroMQ情况下非常有吸引力）的字面意义上实现，因此ZeroMQ允许您避免共享缓冲区（ZeroCopy格式）的数据重复。
如果您的操作系统允许IPC://和inproc:// transport类几乎没有开销，并且inproc://甚至不会（由于ZeroMQ团队的伟大体系结构思想）需要_any_additional_线程（CPU / RAM开销）一旦通过ZeroThread- context( 0 )调用
更less的开销（如果您的应用程序适合nanomsg）
如果ZeroMQ似乎对于您的特定目标来说太强大了，可能会对ZeroMQ的联合父亲Martin Sustrik感兴趣， 他们也可以提供node.js端口的 nanomsg
去哪里了解更多细节？
下一步你可以在以太网ZeroMQ / nanomsg的情况下做的最好的一步是获得更多的全局视图，这可能听起来很复杂，但是如果你至less要跳转到第265页如果不是在那里逐步阅读的话，第一卷就可以了。
有史以来发展最快的学习曲线将是首先在图60重新发布更新和图62 HA克隆服务器对上提供一个可能的高可用性方法，然后回到根源，元素和细节。
如果你爱上这种思维模式，那么你会爱上Martin Sustrik的博客文章 – 一个聪明人。 这是值得的，至less从他的观点和经验中得到灵感。