分布式缓存集群伸缩性设计

分布式缓存系统中，路由算法决定着我们去访问缓存集群中哪台缓存服务器。
小网站用的余数hash，可以简单解决分配问题:缓存数据的key利用java的HashCode()得到个490806430(乱写的数)，然后除服务器的数量，比如说有3台，得到余数1就是3台服务器对应的三个节点中的node1。因为hashcide具有随机性，所以使用余数算法可保证缓存数据在整个缓存服务器集群中的均衡分布。也可以通过改进，升级成加权余数路由。
但是如果说3台服务器不满足访问量了，我们要扩容到4台，除数变成了4，刚刚那个key对应的hash值除了4得到余数2，对应节点node2，本来缓存的在node1，找不到就只能去访问数据库。这种缓存命中失败的概率此时大约有75%，也就是说缓存一旦新添了服务器，需要时间预热，这时候根本没有起到缓存效果，反倒增加了数据库的压力。特别是如果有100台服务器，增加一台命中失败概率就变成了99%。这肯定不能被接受。
现在流行的路由算法是
一致性hash算法
就是一个环，长度是0-----2的32次方，节点名称算一下hash值，扔到环上，key呢算完了hash也扔到环上，顺时针找，最先碰到的节点就是要去访问的缓存服务器。
现在我们要增加一台服务器，计算节点的hash扔到环上，第二张图里，加粗的那部分就是影响的key的范围，他们不找node1了，改找node3了，也就是这数据会不得不去访问数据库进行预热，这么一计算，命中率高到75%了，特别是你的服务器越多，命中率改变越高，100台加1台，命中率高达99%。

但是这还有问题，我们加了台node3仅仅影响了node1，剩下两个节点没影响到，没有分担压力。

于是又有了新的解决办法，计算机的任何问题都可以通过增加一个虚拟层来解决，什么意思呢，就是我环上不直接扔节点了，把节点(也就是缓存服务器)对应一堆虚拟的节点，这些虚拟节点是自己定义的，均衡的扔到环上，如果再添加节点，同样的方式以近似的规则扔到环上n多个位置，这样就是整个环都有被我新添加的服务器影响的地方了。

书上说实践中一台服务器虚拟150个虚拟服务器节点比较合适，当然也看情况，当然我也没地方试。。

以上摘自《大型网站技术架构--核心原理与案例分析》一书