使用TCP跨进程共享内存

Question

由于没有使用nodejs或Redis或其他内存存储系统，我在开始Memcache时犯了一个错误。现在，重写所有内容以适应和关联这些API中的代码为时已晚。

然而，我最近才发现了分叉过程以及它们有多么有益;特别是因为我正在开发游戏服务器。

我遇到的问题是：The memory is not shared between cores in nodejs ..直到找到一个名为Amensia的TCP内存共享模块。

总而言之，我对nodejs和tcp的一般问题有一些疑问：

1）maximum size of a TCP packet约为64k，因此使用此模块时，我只能共享最大64k的数据？

2）我使用全局GAMES和users对象来存储玩家数据。当玩家在地图（x，y位置）和其他动作中移动时，这些对象会更新。通过TCP发送所有这些数据会导致瓶颈吗？

Answer 1

最小开销方法

为所有localhost分叉进程配备进程间智能消息传递层。

这样你的共享＆＃34;可以通过抽象的含义和（在ZeroMQ案例中非常有吸引力）实现完全正确的含义，从而ZeroMQ允许您通过共享缓冲区（ZeroCopy格言）避免数据重复。

如果你的操作系统允许IPC://和inproc://传输类几乎没有开销，inproc://甚至没有（由于ZeroMQ团队的伟大架构思想）需要_any_additional_ thread {通过ZeroThread调用{3}} - context( 0 )

一种更不受开销( CPU/RAM-overheads )

影响的方法

如果ZeroMQ看起来对你的特定目标来说太强大了，可能会感兴趣的是它的妹妹Martin Sustrik，ZeroMQ的共同父亲已经剥离了 - nanomsg ( if your app fits nanomsg )

去哪里了解更多详情？

你可以在以太网中做的最好的下一步ZeroMQ / nanomsg就是为了获得更多的全局视图，对于尝试使用ZeroMQ进行编码的前几个事情可能听起来很复杂，但是如果你至少跳到which also has node.js port available的第265页，如果不是一步一步地阅读的话。

最快的学习曲线是首先在图60 重新发布更新和图62 HA克隆服务器对上获得未公开的视图，以获得可用的高可用性方法和然后回到根，元素和细节。

如果你爱上这种思维模式，你会喜欢Martin Sustrik的博客文章 - 确实是个聪明人。值得花时间至少从他的观点和经验中获得灵感。

Answer 2

1）TCP数据包大小不应该有任何问题。如果数据太大，节点将对数据进行缓冲/排队，并在操作系统为其提供可写套接字的文件描述符时发送它们。只有在每秒写入超过网络带宽的情况下，才可能遇到性能问题。此时，Node还将使用更多RAM来排队所有这些消息。

https://nodejs.org/api/net.html#net_socket_buffersize

2）大多数游戏使用TCP或UDP进行实时通信。它可能是瓶颈，因为其他任何东西（RAM，CPU，带宽，存储）都可以。在某些压力点，一个或多个资源将结束/失败/执行不良。在为您的瓶颈完成所有优化并且您仍然需要向游戏服务器添加更多并发用户时，使用可以水平增长的架构（添加更多计算机）通常是一种很好的做法。

https://1024monkeys.wordpress.com/2014/04/01/game-servers-udp-vs-tcp/

您可能会使用TCP连接到Redis服务器（但您也可以使用unix套接字）。

如果您只需要进程间通信（而不是跨机器间），则应该查看“cluster”Node.js核心模块。它内置了IPC。