分布式节点协调实现方式

       分布式系统是多个节点通过网络连接再一起并通过消息的传递来进行协调的系统。通常节点间的协调与控制主要是通过以下几种方式完成的。

 

一、硬件负载均衡


分布式节点协调实现方式_第1张图片

       这是一个远程通讯过程,请求发起方和请求处理方之间有一个硬件负载均衡设备(例如F5,很贵。。。。),所有请求都要通过此设备。

 

二、软件负载均衡


分布式节点协调实现方式_第2张图片

       和上图的差别就是换成了软件(例如LVSNginx,免费~~~可控~~~)。一般称这种方式为透明代理,因为对双方都是透明的。不过,这种方式有两个不足:

  1. 增加网络开销:流量和延迟方面。如果使用LVSTUN或者DR模式,那从处理请求的结果或直接返给发起方,不再通过中间代理。在发送包小返回数据包大的情况下,代理与非代理模式相比只有很小的流量增加,但如果发送请求包很大的情况下,流量增长还是很明显的。延时的影响实际中是很小的。
  2. 透明代理是请求必经之路,代理出问题肯定请求会有问题,增加了出错的概率与条件。我们需要考虑代理服务器的热备份,但切换时依然会有影响。

 

三、名称服务直连


分布式节点协调实现方式_第3张图片

      这种方式中请求发起方与处理方直连,他们之间有一个“名称服务”的角色,作用有两个:

  1. 收集提供请求处理的服务器的地址信息;
  2. 提供这些地址信息给请求发起方。

名称服务只是起到地址交换的作用,发起请求的机器需要根据从名称服务器上得到的地址进行负载均衡工作,即原透明代理的工作拆分到名称服务和发起请求的机器上了。这个方案较好的解决了2中存在的问题,但是代码升级较复杂。(作者认为,Dubbo+zookeeper就是此方式,但也兼具以下方式。)

 

四、规则服务器控制路由请求


分布式节点协调实现方式_第4张图片

 

      这种方式与前一个很像,但是这里采用的是规则服务器。请求发起方与处理方也是直连的方式,但是发起方应该选择哪个处理方进行连接呢?这就需要规则处理器了,在发起请求的机器上会有对规则进行处理从而进行请求处理器选择的逻辑代码,规则服务器本身不和请求处理的机器进行交互,只负责将规则提供给它。

 

五、master+worker


分布式节点协调实现方式_第5张图片

      这种方式通过master节点管理任务,由master把任务分配给不同的worker中取处理,更多的是任务的分配与管理。

 

 以上就是分布式节点间协调与控制的主要方式,本文主要参考《大型网站系统与Java中间件实践》,欢迎大家与我有更多交流。


你可能感兴趣的:(【分布式】)