dubbo负载均衡策略,redis负载均衡
zookeeper dubbo 怎么实现负载均衡
问题的由来:
大规模服务化之前,应用可能只是通过RMI或Hessian等工具,简单的暴露和引用远程服务,通过配置服务的URL地址进行调用,通过F5等硬件进行负载均衡。
(1)当服务越来越多时,服务URL配置管理变得非常困难,F5硬件负载均衡器的单点压力也越来越大。
此时需要一个服务注册中心,动态的注册和发现服务,使服务的位置透明。并通过在消费方获取服务提供方地址列表,实现软负载均衡和Failover,降低对F5硬件负载均衡器的依赖,也能减少部分成本。
(2)当进一步发展,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。
这时,需要自动画出应用间的依赖关系图,以帮助架构师理清理关系。
(3)接着,服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器?
为了解决这些问题,第一步,要将服务现在每天的调用量,响应时间,都统计出来,作为容量规划的参考指标。
其次,要可以动态调整权重,在线上,将某台机器的权重一直加大,并在加大的过程中记录响应时间的变化,直到响应时间到达阀值,记录此时的访问量,再以此访问量乘以机器数反推总容量
Dubbo负载均衡
在分布式集群架构下,负载均衡很重要。集群本来就是为了分担压力,负载均衡做的不好,就会失去了集群的意义。
1.按照权重随机分配
按照权重随机分配,即是不均等随机*。比如一块不均匀的硬币,字面30%概率,花面70%概率。这种就是不均等的随机*。
从数学上看,即是一个区间0-10,然后均等随机产生0-10的随机数。然后在这个区间上划分,0-3,3-6,6-10.分别把这个三个区间看做三个随机*,那么这个三个随机*的概率即是30%,30%,40%。
列子:
权重分别为[2,4,8],权重和为14,那么前面三个权重为2,4,8的三个*就对应[0,2,6,14]这个三个区间。比如6-14表示权重为8的随机*的概率为8/14。所以当产生一个随机数时,通过遍历权重数组,减等,当小于0时,他就落在那个权重*上。比如:随机数5落在2-6之间,2-6对应的是权重为4这个*,所以他属于权重为4的这个随机*。
2.轮询
当多线程出现时,使用原子类的整数去取莫轮询节点。
注意:sequences是成员变量,每次调用函数所有的权重都回归最初。
3.Hash方式
使用某种hash算法,同一请求总是会hash到同一台机子上。
传统的hash算法,存在当hash区间变化时,同样的值hash后的位置不一样了。而一致性hash算法把请求,节点都hash后,放到一个圆环上,按照顺时针转动到的第一个节点为结果。这样就减少了结果的变化。还可以通过增加虚拟节点的方式均衡hash后的概率问题,当然增加节点需要交叉增加。
1.怎么保证服务器少的情况下,hash的结果变化不大。
把消费者,提供者都去hash,hash的结果映射到一个环上。然后,要判断的那个消费者访问那个提供者的时候,进行顺时针的转动。遇到的第一个提供者节点就是。
2.怎么保证概率的问题
交叉的防止虚拟节点,只要节点够多,那就近似是想等的。
详见:一致性hash详解释
4.最少访问原则
如果有多台机子的最少活跃数相同,在这几个中使用第一种按权重随机的方式
最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。
使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大。
比如:同样是进行了10个请求,在一分钟内,A只处理了两个,B处理了5个。那么A的机会就更少,那么就会保证的系统整体的速度。
dubbo之Cluster(容错)
在介绍dubbo的cluster之前,先来看一下cluster在dubbo整体设计中的位置。按照*的说法,Cluster作为路由层,封装多个提供者的路由及负载均衡,并桥接注册中心,以 Invoker为中心,核心扩展接口为 Cluster, Directory, Router, LoadBalance,接口间的依赖关系如下:
虚拟Invoker暴露流程程: Cluster=>(Directory=> Router)=> LoadBalance=> Invoker,依照这个顺序,我们先来看Cluster。Cluster不属于核心层,目的是将多个 Invoker伪装成一个 Invoker,这样其它人只要关注 Protocol层 Invoker即可,加上 Cluster或者去掉 Cluster对其它层都不会造成影响,因为只有一个提供者时,是不需要 Cluster的。本文主要关注Cluster层的容错及其核心接口(LoadBalance在之前的文章已经做过介绍)。
先来看Cluster层中的Cluster接口,支持SPI扩展、自适应扩展,默认SPI实现是FailOverCluster,核心只有一个join接口
比较好理解,把Directory中的所有原始Invoker合并成一个虚拟Invoker,虚拟Invoker是一系列通过合并原始Invoker,并在此基础上扩展带有容错机制的Invoker。以FailOverCluster为例,join返回FailoverClusterInvoker,具体的invoke逻辑由虚拟Invoker( FailoverClusterInboker)实现,构造方法(这里以FailoverClsterInvoker为例,其他虚拟Invoker的构造方法大同小异)通过继承父类AbstractClusterInvoker实现,只有一个Directory参数:
当前dubbo版本提供的虚拟Invoker主要有下面几种,下面来分别介绍:
所有8种cluster中,除去AvailableCluster、MergeableCluster、BroadcastCluster,其他都需要根据LoadBalance选取可用Invoker,具体逻辑在AbstractClusterInvoker.select。先来看AbstractClusterInvoker的构造方法:
两个核心参数,Directory和URL,Directory本节先不做介绍,这里的URL是被调用服务的URL;*ailableCheck为了与服务的*ailableCheck做区分,这里的参数名是 cluster.*ailablecheck;核心关注上面提到的select方法,先来看逻辑:
整体select方法都是为了尽可能保证每次选出的Invoker不重复,也就是说最大限度的保证负载均衡;doSelect方法在处理的时候,通过loadBalance选出的Invoker,还会对其进一步判断是否已被选中过,步骤如下:
doSelect方法中的loadbalance.select已经在LoadBalance部分做了分析,这里不再冗述,重点关注reSelect方法;先把备选Invoker中,未被选中过的Invoker过滤出来,优先从中选取可用Invoker,步骤如下:
Cluster层的容错主要通过几种常用的容错机制配合负载均衡,保证最终通过Cluster暴露可用的Invoker;而且,dubbo在保证Invoker可用性前提下,要求尽可能均衡负载,过程会多次执行负载均衡策略。
注:dubbo源码版本2.7.1,欢迎指正。
dubbo与nginx都可以做负载均衡,哪个相对来说更优秀为什么
dubbo的负载均衡已经是服务层面的了,和nginx的负载均衡还在http请求层面完全不同。至于二者哪个优秀,当然没办法直接比较,要硬要选一个的话就是nginx了。 111涉及到负载均衡就涉及到你的业务,根据业务来选择才是最适合的。
拓展:
1、Nginx(“engine x”)是一个高性能的HTTP和反向代理服务器,也是一个IMAP/POP3/SMTP服务器。 Nginx是由 Igor Sysoev为俄罗斯访问量第二的 Rambler.ru站点开发的,第一个公开版本0.1.0发布于2004年10月4日。其将源代码以类BSD许可证的形式发布,因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。2011年6月1日,nginx 1.0.4发布。
2、Nginx是一款轻量级的Web服务器/反向代理服务器及*(IMAP/POP3)代理服务器,并在一个BSD-like协议下发行。由俄罗斯的程序设计师Igor Sysoev所开发,供俄国大型的入口网站及搜索引擎Rambler(俄文:Рамблер)使用。其特点是占有内存少,并发能力强,事实上nginx的并发能力确实在同类型的网页服务器中表现较好,*大陆使用nginx网站用户有:百度、新浪、网易、腾讯、淘宝等。
本文链接:http://www.ahdhgm.com/html/87965316.html
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件举报,一经查实,本站将立刻删除。