Lvs或者F5的负载体系中，所有的请求需要请过dispatcher，从体系上说，它就是所谓的热点设备，无论这个设备的性能多么卓越，迟早会成为性能瓶颈。看过memcached的系统架构后，结合自身的系统特点，也可以做到客户端来实现负载。memcached虽然称为分布式缓存服务器，但服务器端并没有分布式功能，是完全由客户端程序库实现的。
[b]初步方案：[/b]
[img]http://dl.iteye.com/upload/attachment/226676/1e29cb8d-eafe-3161-b5bb-846d8cb9d320.png[/img]
如上图所示：
前提：
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上。
[img]http://dl.iteye.com/upload/attachment/226567/16063547-0cfd-3b17-9d0d-afcbd1880499.png[/img]
Consistent Hashing最大限度地抑制了键的重新分布。而且，有的Consistent Hashing的实现方法还采用了虚拟节点的思想。使用一般的hash函数的话，服务器的映射地点的分布非常不均匀。因此，使用虚拟节点的思想，为每个Server在continuum上分配100～200个点。这样就能抑制分布不均匀，最大限度地减小Server增减时的缓存重新分布。
因此可能的改进如下：
1.Client定时向ClusterIP请求最新的服务器列表，同时client也维护上一个服务器信息，以交集为准。
2.Client对于每次请求，根据Client端存储的服务器列表，按照Consistent Hashing算法分析出目标Server地址，然后发送请求道这台指定server.
3.Consistent Hashing消耗要比较低，速度要比较快。
哈希函数的测试数据：拷贝自[url]http://dennis-zane.iteye.com/blog/346682[/url]
测试场景：
从一篇英文小说（《黄金罗盘》前三章）进行单词统计，并将最后的统计结果存储到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
[b]初步方案：[/b]
[img]http://dl.iteye.com/upload/attachment/226676/1e29cb8d-eafe-3161-b5bb-846d8cb9d320.png[/img]
如上图所示：
前提：
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上。
[img]http://dl.iteye.com/upload/attachment/226567/16063547-0cfd-3b17-9d0d-afcbd1880499.png[/img]
Consistent Hashing最大限度地抑制了键的重新分布。而且，有的Consistent Hashing的实现方法还采用了虚拟节点的思想。使用一般的hash函数的话，服务器的映射地点的分布非常不均匀。因此，使用虚拟节点的思想，为每个Server在continuum上分配100～200个点。这样就能抑制分布不均匀，最大限度地减小Server增减时的缓存重新分布。
因此可能的改进如下：
1.Client定时向ClusterIP请求最新的服务器列表，同时client也维护上一个服务器信息，以交集为准。
2.Client对于每次请求，根据Client端存储的服务器列表，按照Consistent Hashing算法分析出目标Server地址，然后发送请求道这台指定server.
3.Consistent Hashing消耗要比较低，速度要比较快。
哈希函数的测试数据：拷贝自[url]http://dennis-zane.iteye.com/blog/346682[/url]
测试场景：
从一篇英文小说（《黄金罗盘》前三章）进行单词统计，并将最后的统计结果存储到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
扫一扫
3042
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
