关于cluster node=false 的用法疑惑

[rangercyh]

我今天增加了一个特性，如果在 reload 的时候，指定 node = false, 那么就明确了 node 这个节点下线了，cluster.call 的时候就会立刻出错。@mahal907 你看是否能解决你的问题。

Originally posted by @cloudwu in #803 (comment)

我原本以为把某个节点明确设置为false，会导致在call或者send阶段导致报错或者是直接返回；但在实际使用中发现，把某个节点明确设置为false，然后进行reload，这个阶段本身就会因为address的改变导致去重新open_channel，然后直接在reload阶段就报错了。我在想明确某个节点为false跟某个节点不可达应该是两种情况，网络不可达可以认为是错误，明确某个节点为false，而且是通过我主动reload的，这应该是一种需求，不应该报错，就好像我明确下线某个处理节点，应该是一种正常处理，不应该报错，更不应该在reload阶段就开始报错。当然我可以采取把我明确下线的节点从reload table中移除来防止这种问题，但既然云风提供了明确改为false的处理，我感觉是不是用法上有所不妥。

[cloudwu]

不太记得这个问题。

是说， reload 应该忽略掉 false 的配置？

[hanxi]

skynet/service/clusterd.lua

Lines 89 to 97 in 2a076d8

	assert(address == false or type(address) == "string")
	if node_address[name] ~= address then
	-- address changed
	if rawget(node_channel, name) then
	node_channel[name] = nil -- reset connection
	table.insert(reload, name)
	end
	node_address[name] = address
	end

看到代码里已经允许 address 为 false 了，是不是漏了忽略 false 的代码？

if address ~= false then
    table.insert(reload, name)
end

[rangercyh]

准确来讲是我对 cluster.reload 的报错行为有点困惑
https://github.com/cloudwu/skynet/blob/2a076d81927579943e23be3aecbb42c145119cad/service/clusterd.lua#L72-#L117

cluster建立连接的过程是延迟到首次通信的时候才会建立，如果节点不可达或者其他因素也会延迟到通信时才会进行报错，比如call/send会因为节点不可达而报错，这个比较好理解，即使因为明确设置false是一种错误而非功能，也进行报错也可以理解。

但是我认为通常调用reload不应该因为通信原因而报错。但clusterd服务的具体实现却产生了一种额外的报错情况。如果你在reload节点信息之后没有进行过通信，那么无论你如何设置你的config内容，都不会发生报错，一旦某些节点已经发生过通信，从代码上看就是已经 open_channel 过，在 node_channel 里存过值，然后你修改节点的信息进行reload，这个时候因为旧的 node_channel 存在而需要重新进行 open_channel 的调用导致了 open_channel 里判断 address 是 false 而报错了。从现象来看，就是之前config正常配置加载，接着当你把config里的节点设置成false再进行reload的时候，那些之前通信过的节点就会发生报错，而没有通信过就不会报错，这导致reload的这条报错在一定程度上不可控。

我认为既然 cluster 的通信建立是延迟的，那么 reload 某个节点为 false 或者换了address，原来已经 hold 住的channel要么静默处理掉，要么也延迟到再次跟这个节点通信的时候处理比较好，而且把一个之前建立过channel的节点，明确赋值为false，跟这个节点的address发生变化而需要重新建立channel，这两个行为，我认为在内部处理原始channel的时候，是该报错还是打个警告还有商榷空间：D

[rangercyh]

另一个比较难以理解的地方在于，对于每一个连接过来cluster节点，会创建一个clusteragent服务来接收消息，而发送消息则是延迟创建clustersender服务，但如果节点下线了，clusteragent服务会感知到并立刻静默销毁掉。而clustersend服务会延迟到reload阶段报错，但不会销毁。对于那些下线的cluster节点，clustersender服务似乎并没有销毁的时机。接受流服务agent会根据网络断开自动静默销毁，而发送服务sender却一直保留不做销毁，甚至在reload跟每次发送消息的时候进行报错，感觉怪怪的

[cloudwu]

这两天忙。要不先确定一个改法？

[fisher-an]

个人感觉当一个节点设置为false时，对应的sender应该直接销毁。因为每个服务在第一次调用cluster.send/call时都会缓存对应node的sender地址。即使设置为false，依然可以通讯。由于节点间的断开/连接时经常需要同步数据之类的操作。希望clusterd能加上监听接口(类似erlang node monitor)，在节点连接/断开是抛出消息给注册监听了该事件的服务。
由于不想修改skynet源码，目前我的做法是开启一个独立的服务来定时call监控其他节点是否存在，由于发送与接收是两条socket，还得两边互call。当前节点连接列表直接放到C维护，每次取实时数据。 感觉比较lower。 --冷汗 尴尬

[rangercyh]

个人感觉当一个节点设置为false时，对应的sender应该直接销毁。因为每个服务在第一次调用cluster.send/call时都会缓存对应node的sender地址。即使设置为false，依然可以通讯。由于节点间的断开/连接时经常需要同步数据之类的操作。希望clusterd能加上监听接口(类似erlang node monitor)，在节点连接/断开是抛出消息给注册监听了该事件的服务。
由于不想修改skynet源码，目前我的做法是开启一个独立的服务来定时call监控其他节点是否存在，由于发送与接收是两条socket，还得两边互call。当前节点连接列表直接放到C维护，每次取实时数据。 感觉比较lower。 --冷汗 尴尬

我的做法和你类似，由一个节点维护cluster的节点状态，其他节点启动的时候主动注册到这个中心节点，同时定时向中心节点发送心跳保持自己的存活，下线时通知中心节点自己下线。中心节点无论是因为有新节点注册过来还是下线或者通过定时检测发现某个节点心跳超时把节点主动标记成false下线状态，无论是哪一种cluster节点状态发生变化就cluster.reload集群配置，同时广播给所有其他节点，让他们也reload到相同配置。可是无论在上层怎么处理，监控节点的下线都没办法做到实时，除非是修改skynet的cluster模块把连接状态变化的消息抛出来。
除此之外，cluster的sender服务目前没有看到有办法主动销毁，同时在sender存在的情况下reload相应节点的addr不同会触发尝试连接的过程导致报错。