- 浏览: 137016 次
- 性别:
- 来自: 成都
文章分类
最新评论
-
elephant_xiang:
condition例子,搞错了吧public void pro ...
jdk1.5的多线程总结一 -
yinlei126:
这么好的文章没有评论,谢谢
Mina框架剖析--动态篇 -
xds2008:
写的不错,值得表扬,测了一下,还不错,就是有点慢,但是最起码远 ...
java实现远程桌面监控 -
exp111:
这个确实很强 但是能不能连接一次不停的传呢 这个好像是必须连一 ...
java实现远程桌面监控 -
seeallsea:
不错!可以相互转换了。
keystore证书转换
Lvs或者F5的负载体系中,所有的请求需要请过dispatcher,从体系上说,它就是所谓的热点设备,无论这个设备的性能多么卓越,迟早会成为性能瓶颈。看过memcached的系统架构后,结合自身的系统特点,也可以做到客户端来实现负载。memcached虽然称为分布式缓存服务器,但服务器端并没有分布式功能,是完全由客户端程序库实现的。
初步方案:
如上图所示:
前提:
1.Cluster对外有多个固定IP(ClusterIP1,ClusterIP2)供访问,实际是映射到cluster中的某几台Server.
2.图中的每个Server,其实也是个1+N的cluster,同时只有一个服务器位于cluster中服务。
3.Server之间以组播心跳方式发送负载信息,使所有的server都知道cluster中每个server的负载情况,以及服务器的活动状态。
访问步骤:
1.初始状态,Client只知道固定的cluster地址(IP1),向其中任何一个发送请求,获取cluster的负载信息。
2.clusterIP对应的server获取负载信息,返回给Client.
3.Client以某些算法分析出最轻负载server。
4.Client转向连到负载最轻的server.再次重新dispatch之前,一直访问这台server。
5.Client定时获取cluster负载信息,转向重连,这个时候cluster地址(IP1)就不会用到了。
算法:
第三步的负载信息分析,可以用lvs的负载算法,也可以用memcached的取余散列算法。
根据服务器台数的余数进行分散。但是当添加或移除服务器时,缓存重组的代价相当巨大。添加服务器后,余数就会产生巨变,这样就无法获取与保存时相同的服务器,从而影响缓存的命中率。基本不考虑。
问题:按照这个做法,在一定的时间内,client端上所有请求还是分发到一台server上,如果在这个时间段内,数据量特别大,就会造成server之间负载不均衡。要改进这个问题
1) 最好就是把转发过程平均到每个请求上去
2) Client端不需要反复地取负载信息,也就是负载算法可以根据最初获取的Server信息,均匀的分摊到所有的Server上去。
改进:采用memcached的Consistent Hashing算法。首先求出Server的哈希值,并将其配置到0~232的圆上。然后用同样的方法求出存储数据的键的哈希值,并映射到圆上。然后从数据映射到的位置开始顺时针查找,将数据保存到找到的第一个Server上。如果超过232仍然找不到Server,就会保存到第一台Server上。
Consistent Hashing最大限度地抑制了键的重新分布。而且,有的Consistent Hashing的实现方法还采用了虚拟节点的思想。使用一般的hash函数的话,服务器的映射地点的分布非常不均匀。因此,使用虚拟节点的思想,为每个Server在continuum上分配100~200个点。这样就能抑制分布不均匀,最大限度地减小Server增减时的缓存重新分布。
因此可能的改进如下:
1.Client定时向ClusterIP请求最新的服务器列表,同时client也维护上一个服务器信息,以交集为准。
2.Client对于每次请求,根据Client端存储的服务器列表,按照Consistent Hashing算法分析出目标Server地址,然后发送请求道这台指定server.
3.Consistent Hashing消耗要比较低,速度要比较快。
哈希函数的测试数据:拷贝自http://dennis-zane.iteye.com/blog/346682
测试场景:
从一篇英文小说(《黄金罗盘》前三章)进行单词统计,并将最后的统计结果存储到memcached,以单词为key,以次数为value。单词个数为 3061,memcached原来节点数为10,运行在局域网内同一台服务器上的不同端口,在存储统计结果后,增加两个memcached节点(也就是从10个节点增加到12个节点),统计此时的缓存命中率并查看数据的分布情况。
结果如下表格,命中率一行表示增加节点后的命中率情况(增加前为100%),后续的行表示各个节点存储的单词数。
CRC32_HASH表示采用CRC32 散列函数。
KETAMA_HASH是基于md5的散列函数也是默认情况下一致性哈希的推荐算法。
FNV1_32_HASH就是FNV 32位散列函数。
NATIVE_HASH就是java.lang.String.hashCode()方法返回的long取32位的结 果。
MYSQL_HASH是xmemcached添加的传说来自于mysql源码中的哈希函数。
CRC32_HASH KETAMA_HASH FNV1_32_HASH NATIVE_HASH MYSQL_HASH
命中率 78.5% 83.3% 78.2% 99.89% 86.9%
节点1 319 366 546 3596 271
节点2 399 350 191 1 233
节点3 413 362 491 0 665
节点4 393 364 214 1 42
节点5 464 403 427 1 421
节点6 472 306 299 0 285
节点7 283 347 123 0 635
节点8 382 387 257 2 408
节点9 238 341 297 0 55
节点10 239 375 756 0 586
范围 200~500 300~400 150~750 0~3600 50~650
结果分析:
1、命中率最高看起来是NATIVE_HASH,然而NATIVE_HASH情况下数据集中存储在第一个节点,显然没有实际使用价值。为什么会集中存储在 第一个节点呢?这是由于在查找存储的节点的过程中,会比较hash(key)和hash(节点IP地址),而在采用了NATIVE_HASH的情况下,所 有连接的hash值会呈现一个递增状况(因为String.hashCode是乘法散列函数),如:
192.168.0.100:12000 736402923
192.168.0.100:12001 736402924
192.168.0.100:12002 736402925
192.168.0.100:12003 736402926
如果这些值很大的会,那么单词的hashCode()会通常小于这些值的第一个,那么查找就经常只找到第一个节点并存储数据,当然,这里有测试的局限性, 因为memcached都跑在一个台机器上只是端口不同造成了hash(节点IP地址)的连续递增,将分布不均匀的问题放大了。
2、从结果上看,KETAMA_HASH维持了一个最佳平衡,在增加两个节点后还能访问到83.3%的单词,并且数据分布在各个节点上的数目也相对平均,难怪作为默认散列算法。
3、最后,单纯比较下散列函数的计算效率:
CRC32_HASH:3266
KETAMA_HASH:7500
FNV1_32_HASH:375
NATIVE_HASH:187
MYSQL_HASH:500
NATIVE_HASH > FNV1_32_HASH > MYSQL_HASH > CRC32_HASH > KETAMA_HASH
初步方案:
如上图所示:
前提:
1.Cluster对外有多个固定IP(ClusterIP1,ClusterIP2)供访问,实际是映射到cluster中的某几台Server.
2.图中的每个Server,其实也是个1+N的cluster,同时只有一个服务器位于cluster中服务。
3.Server之间以组播心跳方式发送负载信息,使所有的server都知道cluster中每个server的负载情况,以及服务器的活动状态。
访问步骤:
1.初始状态,Client只知道固定的cluster地址(IP1),向其中任何一个发送请求,获取cluster的负载信息。
2.clusterIP对应的server获取负载信息,返回给Client.
3.Client以某些算法分析出最轻负载server。
4.Client转向连到负载最轻的server.再次重新dispatch之前,一直访问这台server。
5.Client定时获取cluster负载信息,转向重连,这个时候cluster地址(IP1)就不会用到了。
算法:
第三步的负载信息分析,可以用lvs的负载算法,也可以用memcached的取余散列算法。
根据服务器台数的余数进行分散。但是当添加或移除服务器时,缓存重组的代价相当巨大。添加服务器后,余数就会产生巨变,这样就无法获取与保存时相同的服务器,从而影响缓存的命中率。基本不考虑。
问题:按照这个做法,在一定的时间内,client端上所有请求还是分发到一台server上,如果在这个时间段内,数据量特别大,就会造成server之间负载不均衡。要改进这个问题
1) 最好就是把转发过程平均到每个请求上去
2) Client端不需要反复地取负载信息,也就是负载算法可以根据最初获取的Server信息,均匀的分摊到所有的Server上去。
改进:采用memcached的Consistent Hashing算法。首先求出Server的哈希值,并将其配置到0~232的圆上。然后用同样的方法求出存储数据的键的哈希值,并映射到圆上。然后从数据映射到的位置开始顺时针查找,将数据保存到找到的第一个Server上。如果超过232仍然找不到Server,就会保存到第一台Server上。
Consistent Hashing最大限度地抑制了键的重新分布。而且,有的Consistent Hashing的实现方法还采用了虚拟节点的思想。使用一般的hash函数的话,服务器的映射地点的分布非常不均匀。因此,使用虚拟节点的思想,为每个Server在continuum上分配100~200个点。这样就能抑制分布不均匀,最大限度地减小Server增减时的缓存重新分布。
因此可能的改进如下:
1.Client定时向ClusterIP请求最新的服务器列表,同时client也维护上一个服务器信息,以交集为准。
2.Client对于每次请求,根据Client端存储的服务器列表,按照Consistent Hashing算法分析出目标Server地址,然后发送请求道这台指定server.
3.Consistent Hashing消耗要比较低,速度要比较快。
哈希函数的测试数据:拷贝自http://dennis-zane.iteye.com/blog/346682
测试场景:
从一篇英文小说(《黄金罗盘》前三章)进行单词统计,并将最后的统计结果存储到memcached,以单词为key,以次数为value。单词个数为 3061,memcached原来节点数为10,运行在局域网内同一台服务器上的不同端口,在存储统计结果后,增加两个memcached节点(也就是从10个节点增加到12个节点),统计此时的缓存命中率并查看数据的分布情况。
结果如下表格,命中率一行表示增加节点后的命中率情况(增加前为100%),后续的行表示各个节点存储的单词数。
CRC32_HASH表示采用CRC32 散列函数。
KETAMA_HASH是基于md5的散列函数也是默认情况下一致性哈希的推荐算法。
FNV1_32_HASH就是FNV 32位散列函数。
NATIVE_HASH就是java.lang.String.hashCode()方法返回的long取32位的结 果。
MYSQL_HASH是xmemcached添加的传说来自于mysql源码中的哈希函数。
CRC32_HASH KETAMA_HASH FNV1_32_HASH NATIVE_HASH MYSQL_HASH
命中率 78.5% 83.3% 78.2% 99.89% 86.9%
节点1 319 366 546 3596 271
节点2 399 350 191 1 233
节点3 413 362 491 0 665
节点4 393 364 214 1 42
节点5 464 403 427 1 421
节点6 472 306 299 0 285
节点7 283 347 123 0 635
节点8 382 387 257 2 408
节点9 238 341 297 0 55
节点10 239 375 756 0 586
范围 200~500 300~400 150~750 0~3600 50~650
结果分析:
1、命中率最高看起来是NATIVE_HASH,然而NATIVE_HASH情况下数据集中存储在第一个节点,显然没有实际使用价值。为什么会集中存储在 第一个节点呢?这是由于在查找存储的节点的过程中,会比较hash(key)和hash(节点IP地址),而在采用了NATIVE_HASH的情况下,所 有连接的hash值会呈现一个递增状况(因为String.hashCode是乘法散列函数),如:
192.168.0.100:12000 736402923
192.168.0.100:12001 736402924
192.168.0.100:12002 736402925
192.168.0.100:12003 736402926
如果这些值很大的会,那么单词的hashCode()会通常小于这些值的第一个,那么查找就经常只找到第一个节点并存储数据,当然,这里有测试的局限性, 因为memcached都跑在一个台机器上只是端口不同造成了hash(节点IP地址)的连续递增,将分布不均匀的问题放大了。
2、从结果上看,KETAMA_HASH维持了一个最佳平衡,在增加两个节点后还能访问到83.3%的单词,并且数据分布在各个节点上的数目也相对平均,难怪作为默认散列算法。
3、最后,单纯比较下散列函数的计算效率:
CRC32_HASH:3266
KETAMA_HASH:7500
FNV1_32_HASH:375
NATIVE_HASH:187
MYSQL_HASH:500
NATIVE_HASH > FNV1_32_HASH > MYSQL_HASH > CRC32_HASH > KETAMA_HASH
发表评论
-
Java上clear Squid缓存
2011-11-29 10:26 1203实现原理: 构造TCP请求,调用Squid自带 ... -
HttpURLConnection设置代理
2011-01-21 11:00 1400设置全局代理,JVM范围内有效: System ... -
JCE provider管理的问题
2010-08-23 13:24 3206现象 两个module A和B分别采用了infosec的不同版 ... -
Jar冲突解决二
2010-08-23 11:54 1720方案思想 自定义CustomClassLoader,彻底改变c ... -
Jar冲突解决一
2010-08-23 10:46 1200目的是classpath中线性的jar排列扩展成树型排列。方案 ... -
SelectableChannel关闭注意事项
2010-03-29 11:49 962SocketChannel和ServerSocketChann ... -
java clone备忘
2009-12-09 14:39 7881.Object clone 就是复制一个对象的复本,在Fac ... -
远程调用之RMI
2009-05-22 00:03 1014RMI(Remote Method Invocation ... -
Java修饰符归纳
2009-05-20 17:26 890final 1.final类 final类不能被继承, ... -
classloader整理
2009-05-18 18:08 1085classloader它就是用来加载Class文件到JV ... -
Java IO归纳
2009-05-17 14:39 1624Java的IO基于装饰器模式设计。根接口是InputS ... -
java实现远程桌面监控
2009-05-10 19:28 3817java里面的Robot类可以完成截图的功能,借助于这 ... -
简单的轮子--IOC容器
2009-05-10 15:48 1098产品的需求越来越多,则开发了越来越多的功能,同时也带来了 ... -
Java也可以截图
2009-05-10 14:48 1086java.awt.Robot类真的很好玩。玩Robot会给你带 ... -
jdk1.5的多线程总结二
2009-05-10 13:07 1519新的Synchronizer: Java 5.0里新加了4个协 ... -
jdk1.5的多线程总结一
2009-05-10 01:17 5992Java 5.0里新加入了三个多线程包:java.util.c ... -
JavaGC知识整理
2009-05-08 00:55 942堆 JVM管理的内存叫堆。在32Bit操作系统上有1.5G-2 ... -
ConcurrentHashMap
2009-05-08 00:54 999实现原理 锁分离 (Lock Stripping) C ... -
Java Socket异常整理
2009-05-08 00:41 3517最近跟进性能测试,碰 ... -
Java各种路径和参数
2009-05-08 00:39 11981.JSP中获得当前应用的 ...
相关推荐
基于LSTM的SDN流量预测与负载均衡python源码+数据+详细注释.zip基于LSTM的SDN流量预测与负载均衡python源码+数据+详细注释.zip基于LSTM的SDN流量预测与负载均衡python源码+数据+详细注释.zip基于LSTM的SDN流量预测与...
#========controller,负载均衡控制器======== worker.controller.type=lb worker.controller.balanced_workers=tomcat1,tomcat2 worker.controller.sticky_session=1 5 修改tomcat的端口号(3处) ...
主机名IP地址操作系统组件备注环境说明架构图目录结构配置文件docker-compose配置文件keepalived配置文件keepalived检测脚本hapr
数据中心服务器接入部署(1)-多网卡接入,网络部署方案 服务器多网卡接入简介 服务器NIC Teaming(多网卡接入) 服务器NIC Teaming,也称单机链路的负载均衡,一般指的是单台服务器利用多个网卡进行绑定而实现的...
前台门户网站架构 设计方案 北京宽连... 2) 采用硬件设备负载均衡器,实现网络流量的负载均衡 使用硬件设备负载均衡器,将网络流量均衡的分担到WEB服务器集群各节点 服务器,保障平台服务器资源均衡的使用。 3) 采用代
集成四千兆以太网接口 1.4 管理终端 1个Intel Xeon E5-2620处理器,内存大小8G,双千兆网口 2 网络设备 2.1 负载均衡器 RADWARE应用负载均衡设备,型号:为ODS-504,有,4个可选的千兆位电端口,1G主内存,500M处理能力...
STP (生成树协议):就是把一个环形的结构改变成一个树形的结构。用来将物理上存在环路的网络,通过一种算法,在逻辑...备注:现在的路由器不会产生环路,配置的主要目的是选择性能较好的交换机做根网桥实现负载均衡。
商城服务器技术架构及服务器配置方案 服务器架构 服务器配置需求 保证商城项目的顺利实施,结合企业规模及业务量的大小,现向贵公司建议服务器配置如下: 服务器类别 台数 服务器配置 备注 SLB 1 负载均衡(公网带宽...
服务器架构 服务器配置需求 保证商城项目的顺利实施,结合企业规模及业务量的大小,现向贵公司建议服务器配置如下: 服务器类别 台数 服务器配置 备注 SLB 1 负载均衡(公网带宽10M) ECS服务器 2 8核16G,300G(可...
服务器配置需求 保证商城项目的顺利实施,结合企业规模及业务量的大小,现向贵公司建议服务器 配置如下: "服务器类别 "台数 "服务器配置 "备注 " "SLB "1 " "负载均衡(公网带宽10" " " " "M) " "ECS服务器 "2 "8核...
示例如下: 二级系统安全需求网络拓扑结构示例 三级系统安全需求网络拓扑结构示例 2 负载均衡设计(可选) 此处描述系统具体采用的负载均衡产品型号及数量,部署位置,部署目的,主要的配 置策略 3 网络存储设计...
* 实现了三种不同的负载均衡策略:最小容量优先、随机均分、顺序轮询,支持 MD5 校验完整性 #### 技术原理 * 给每个 dataserver 分配等长 buffer,再根据 offset 在 buffer 中的不同位置写入数据 * offset 可以...
## 基于muduo高性能网络库,可以工作在nginx负载均衡环境中的集群聊天服务器 ### 项目编译方式 cd build rm -rf * cmake .. make 或者 ./chatServer.sh 【备注】 1、该资源内项目代码都经过测试运行成功,...
<module>orion-ribbon</module> 负载均衡算法 <module>orion-archer</module> 远程服务调度框架 <module>orion-monitor</module> 链路监控 <module>orion-client</module> 客户端测试包 <module>orion-server...
为保证在多条外网线路情况下带宽的合理分配使用,设备必须支持多链路负载均衡,负载均衡可基于带宽、时延、负载等多种方式。为防止虚假应标,需提供设备配置界面截图; 支持线路过载保护功能,当某条外网线路拥塞时...
使用Python Web框架Django开发的一个B2C网上蔬果商城,包含用户、商品、购物车、订单等模块等等,使用了Celery异步任务队列,MySQL数据库,Redis数据库,FastDFS分布式的图片存储服 务,Nginx负载均衡服务器,uWSGI...
- 日志记录、全局搜索、系统广播、负载均衡 ## 项目备注 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用! 2、本项目适合计算机相关专业(如计科、人工智能、通信工程、自动化、...
websocket入门到项目实战系列课程,20节左右的课程,每节课有课堂笔记和源码,主要讲解其的概念、基础...采用nginx负载均衡器,后端多节点集群部署的问题和解决方案;购买后加进技术问答群Q群699347262备注订单号后四位
该系统涉及 分销商、供应商、平台管理员等多种分销角色,技术采用spring-cloud 2.0微服务化框架、eureka注册中心、ribbon负载均衡、hystrix限流降级、spring security权限控制、redis缓存 elasticsearch索引等主流...