skynet集群 --- cluster 模式

　　skynet本身解决的核心问题是充分利用同一台机器的多核的处理能力。云风在描述集群时，强调说skynet只提供了构建集群的组件。那是因为不是所有项目遇到的问题都能够用统一的解决方案的。还提出任何企图抹平服务运行位置差异的设计都需要慎重考虑，很可能存在设计问题，因为集群协作不与单机多服务工作，集群中可能对方的服务并未启动，而单机工作中，可以认为不会只有一部分出错（即不会说当前功能正在运行，但是本机目标服务未启动的情况）。

　　skynet自带两种集群基础架构，我们接下来要拜读的是cluster 方式。

　　相对于master/slave 模式，cluster模式有较大的弹性。它不需要配置harbor_id，harbor_id需要填0，那么就意味着，集群节点不限制于256个。

　　跟master/slave 不同，cluster的配置需要在每台机子上（或者缓存到redis中，每台机子获取到的配置表需要一致）配置，需要新建一份文件，如skynet示例，又或者在cluster.reload时传入一个table配置

__nowaiting = true    -- If you turn this flag off, cluster.call would block when node name is absent

db = "127.0.0.1:2528"
db2 = "127.0.0.1:2529"

-- cluster1.lua
skynet.start(function()
    cluster.reload {
        db = "127.0.0.1:2528",
        db2 = "127.0.0.1:2529",
    }
        ...
end)

　　接下来我们主要看几个问题：集群的启动过程，cluster.send()与cluster.call()的执行过程。

cluster集群的启动过程

　　当我们需要使用cluster模式时，我们必须要在一个地方进行 require "cluster"，可以在main里，也可以在项目中的负载均衡里等等地方。当require "cluster"时，会执行如下代码：

-- cluster.lua
skynet.init(function()
    clusterd = skynet.uniqueservice("clusterd")
end)

　　在init中，会启动一个 clusterd的服务，用来对集群的维护，其实cluster.lua只是对集群操作的一个浅封装。

　　在require启动完clusterd服务后，需要进行 cluster.reload({})的操作，对集群中的机子进行初始化，并且启动当前节点对配置表中的机子的 clustersender 发送服务，也就是说当前节点会有n个集群节点的发送服务（有多少个集群节点，就有多少个服务），当reload完成后，需要对各节点的监听操作（cluster.open "name"),这里cluster.open的主要操作是生成一个对应目标机子的gateserver并监听端口，如果有消息触发gateserver，则表示对应的监听机子有消息过来，如果是对方连接过来，则会生成一个对应的clusteragent（接收消息服务）：

-- cluster1.lua
skynet.start(function()
    cluster.reload {
        db = "127.0.0.1:2528",
        db2 = "127.0.0.1:2529",
    }
        ... 
    cluster.open "db"
    cluster.open "db2"
        ...
end)

　　首先看下对集群节点发送消息的服务的创建与其功能：

-- clustersender.lua
skynet.start(function()
    channel = sc.channel {
            host = init_host,
            port = tonumber(init_port),
            response = read_response,
            nodelay = true,
        }
    skynet.dispatch("lua", function(session , source, cmd, ...)
        local f = assert(command[cmd])
        f(...)
    end)
end)

　　注意，此时只是创建了clustersender的服务，并没有与对应的机子进行open操作，实际上与对应节点建立连接是在对节点进行通讯的时候才会去判断是否已经连接成功，如果没有连接则进行连接，这里每次通讯都会去判断是因为连接是tcp的，可能会中断。在创建服务时，可以看到对socketchannel 的对象进行了初始化，host与port是必须要初始化的，这里的response进行赋值是为了告诉channel是使用哪种通信逻辑，具体的socketchannel支持的通信逻辑，可查看官方wiki：SocketChannel · cloudwu/skynet Wiki · GitHub。

　　同理，对节点进行接收消息的 clusteragent 服务的创建大同小异。

　　现在，对每个节点都创建了 clustersender, clusteragent 两个服务后，我们看下cluster.call的执行过程是怎样的。

cluster.call 的执行过程

　　当执行cluster.call时，首先先访问当前缓存是否有对应节点的发送服务信息，如果没有先将此次消息插入到节点的消息队列中，然后会跟clusterd获取对应clustersender，如果对应服务未启动，那么会触发连接去新建一个tcp连接的服务 ，如果创建失败则会将所有消息丢弃掉，如果服务创建完成，则会对所有消息进行依次执行，如果本身已经有缓存信息，则直接给发送服务发送 req 命令：

-- cluster.lua
function cluster.call(node, address, ...)
    -- skynet.pack(...) will free by cluster.core.packrequest
    local s = sender[node]
    if not s then
        local task = skynet.packstring(address, ...)
        return skynet.call(get_sender(node), "lua", "req", repack(skynet.unpack(task)))
    end
    return skynet.call(s, "lua", "req", address, skynet.pack(...))
end

　　clustersender 发送消息服务接收req命令并执行操作，首先会对消息进行编码，然后才执行发送操作：

-- clustersender.lua
local function send_request(addr, msg, sz)
    -- msg is a local pointer, cluster.packrequest will free it
    local current_session = session
    local request, new_session, padding = cluster.packrequest(addr, session, msg, sz)        -- 对消息进行打包，padding是区分消息是否为长消息，大于32k为长消息
...
    return channel:request(request, current_session, padding)                -- 对消息发送
end

function command.req(...)
    local ok, msg = pcall(send_request, ...)
...
end

 

　　chanel:request 函数，主要是对消息的发送，然后区分使用的模式是否为一问一答，还是不要求每一个请求都有一个回应进行，但是两种模式都会触发等待消息的情况：

-- socketsender.lua
local function push_response(self, response, co)
    if self.__response then
        -- response is session
        self.__thread[response] = co
    else
        -- response is a function, push it to __request
        table.insert(self.__request, response)
        table.insert(self.__thread, co)
        if self.__wait_response then
            skynet.wakeup(self.__wait_response)
            self.__wait_response = nil
        end
    end
end

local function wait_for_response(self, response)
    local co = coroutine.running()
    push_response(self, response, co)
    skynet.wait(co)
    ...
end

function channel:request(request, response, padding)
    assert(block_connect(self, true))    -- connect once
    local fd = self.__sock[1]
...
    return wait_for_response(self, response)
end

　　执行channel:request 会挂起当前协程等待消息（而channel在connect时就会fork一个协程进行消息的分发。），对应节点会在clusteragent服务接收到消息并且执行，然后将消息原路返回给原节点。

　　节点收到消息回应，如果是dispatch_by_session则会根据session获取到对应的协程然后唤起，使得之前的wait_for_response协程进行消息并且返回消息给对应的调用者。

-- socketchannel.lua
local function connect_once(self)
...
self.__dispatch_thread = skynet.fork(function()
            pcall(dispatch_function(self), self)
            -- clear dispatch_thread
            self.__dispatch_thread = nil
        end)
...
end

　　以上则是cluster.call的调用过程。

cluster.send 的执行过程

　　相对于cluster.call而言，send的主要区别则是在channel:request时会直接返回函数，不会挂起协程进行等待。