Cluster 集群

skynet 支持两种集群模式。

如果你仅仅是单台物理机的计算能力不足，那么最优的策略是选用更多核心的机器，在同一进程内，skynet 可以保持最高的并行能力，充分利用物理机的多核心，远比增加物理机性价比高得多

master/slave 模式

当单台机器的处理能力达到极限后，可以考虑通过内置的 master/slave 机制来扩展。具体的配置方法见 Config 。

每个 skynet 进程都是一个 slave 节点。但其中一个 slave 节点可以通过配置 standalone 来多启动一个 cmaster 服务，用来协调 slave 组网。对于每个 slave 节点，都内置一个 harbor 服务用于和其它 slave 节点通讯。

每个 skynet 服务都有一个全网唯一的地址，这个地址是一个 32bit 数字，其高 8bit 标识着它所属 slave 的号码。即 harbor id 。在 master/slave 网络中，id 为 0 是保留的。所以最多可以有 255 个 slave 节点。

在 master/slave 模式中，节点内的消息通讯和节点间的通讯是透明的。skynet 核心会根据目的地址的 harbor id 来决定是直接投递消息，还是把消息转发给 harbor 服务。但是，两种方式的成本大为不同（可靠性也有所区别），在设计你的系统构架时，应充分考虑两者的性能差异，不应视为相同的行为。

这种模式的缺点也非常明显：它被设计为对单台物理机计算能力不足情况下的补充。所以忽略了系统一部分故障的处理机制，而把整个网络视为一体。即，整个网络中任意一个节点都必须正常工作，节点间的联系也不可断开。这就好比你一台物理机上如果插了多块 CPU ，任意一个损坏都会导致整台机器不能正常工作一样。

所以，不要把这个模式用于跨机房的组网。所有 slave 节点都应该在同一局域网内（最好在同一交换机下）。不应该把系统设计成可以任意上线或下线 slave 的模式。

slave 的组网机制也限制了这一点。如果一个 slave 意外退出网络，这个 harbor id 就被废弃，不可再使用。这样是为了防止网络中其它服务还持有这个断开的 slave 上的服务地址；而一个新的进程以相同的 harbor id 接入时，是无法保证旧地址和新地址不重复的。

---

如果你非要用 master/slave 模式来实现有一定弹性的集群。skynet 还是提供了非常有限的支持：

local harbor = require "skynet.h