关于虚拟节点的思考

[Twwy]

由于网络的不稳定性，导致任务的相对高失败率，使得重试在这个面前如同螳臂挡车。
我思考能否将我们的稳定的部分构成一个任务闭环，然后不稳定的部分又变成另外一个闭环。
(中心->任务调度->虚拟节点) -> 构成管控调度系统
(虚拟节点 -> 实体节点 -> DNS) -> 构成管控通信系统

一个用户添加一个域名之后，通过任务的调度实现虚拟节点的配置文件更新(这个可以保证100%)的成功率。

虚拟节点 -> 实体节点 的一致性问题由节点健康检查守护来解决，他负责把节点之间保持一致性，同时把控制DNS的权限也交给节点来管理，节点上的某个配置文件生效之后，他就有权生效DNS记录，节点的某个配置文件失效，他也有权删除DNS记录。

也就是说，管控调度系统不再负责DNS的管理，这个让节点守护来管理打向他的这个节点流量能够由几个域名组成。管控调度只控制由这个域名由哪几个节点来负载。至于什么时候开始负载，什么时候不负载，这个都由节点的自身的健康状态来决定。

[Twwy]

虚拟节点不会去质疑配置文件的准确性，或者说配置文件准确性是调度系统做的，只要是在虚拟节点里面的配置文件，都是对的，他只干的事情只要是实体节点和他这个虚拟节点的配置文件一致就OK了。

[firefoxbug]

解释下：管控通信系统，这个系统大概是这样工作的。
专门负载通信的系统，有一个守护是做配置文件版本号检测，通过数据库找到某个域名下所有节点，然后根据检测虚拟节点中配置文件版本号，和所有节点上配置文件版本号匹配是否一致。
如果所有节点一致就代表这个节点是生效的（不需要反向代理检测了），再是DNS操作（如果不存在则添加）
如果某个节点不一致，那么就尝试推送配置文件，如果推送配置文件失败，则说明节点已经失效(撤DNS)，如果推送配置文件成功，调用reload模块。

while True:
    # 找到domain下所有节点
    node_list = search_domain_nodes(domain)

    # 从虚拟节点获取conf version
    virtual_version = get_conf_version_from_virtual_proc(domain)

    # 检测virtual_version是否和节点上conf version一致
    result = check_conf_version_consistency(domain, virtual_version)


function check_conf_version_consistency(node_list, virtual_version)
    for node in node_list:
        # 获取某个节点上conf version
        node_version = get_node_conf_version(node)
        if virtual_version == node_version
            # 如果节点conf version 和虚拟节点conf version一致,尝试增加DNS
            try_add_dns(domain)
        else 
            # 如果不一致，尝试推送conf
            result = try_push_conf(virtual_version, node)
            if result :
                # 如果推送成功，尝试reload节点
                try_reload_node()
                update_mysql(success, node)
            else :
                # 推送失败，证明节点down了，撤销DNS
                try_del_dns()
                update_mysql(failure, node)