memcache分布式原理解析

所谓的分布式就是将不同的数据放在不同的服务器上，获取数据时需要根据路由从不同的服务器上获取。在memcache中，服务器端并不支持分布式，而只是在客户端程序中设置分布式。

如果有多个memcache服务器，那么他们之间并不互相通信，数据也无法同步。所以在很多语言对memcache操作的类库中都可以配置，然后根据相应的路由算法决定将数据存储在哪个服务器中。

如果有多个memcache服务器，每个服务器上都存放着大量的数据，万一有一台服务器宕机，那么它上面存的数据就会全部丢失，这也就是分布式的一个弊端，不过就风险来讲比放在一个服务器上要小得多。

上图中可以看到，memcache api会调用路由算法来决定将数据放在哪个服务器上，同样在读取数据时调用路由算法决定去哪个服务器上取数据。

针对路由算法，目前常见得就两种，一种是余数Hash，一种是一致性Hash算法。

余数Hash：

将要存储的k-v数据的key进行hash运算得到一个值，然后根据memcache的数量进行整除取余，根据余数把数据放到对应的服务器上。由于hash值得随机性很大，所以服务器上存放的数据也就比较均衡，一般不会造成大量数据只存放在一台服务器上的情况。例如，username_099:xiaoming中key为username_099，通过hash运算得到的hashcode为21，memcache服务器的数量为3个，那么21%3=0，数据就会保存在标号为0的服务器中。读取数据时也会根据这个算法获得hashcode，从而去0服务器读取数据。但是也会出现问题，如果多加入一个服务器，即4台服务器，那么后续的数据再算出hashcode为21的话数据就会保存到21%4=1的服务器上，同样在读取原来key为username_099的数据时就会指引到1的服务器上，从而导致无法获取到数据的问题。

这种算法有弊端，但是在Python的memcache类库中依然使用这种算法。需要注意。

这个问题有解决方案，解决步骤为：

（1）在网站访问量低谷，通常是深夜，技术团队加班，扩容、重启服务器

（2）通过模拟请求的方式逐渐预热缓存，使缓存服务器中的数据重新分布

一致性Hash：

首先求出每个节点的hash值，可以根据ip port等进行求值，然后把值分布到一个0-2^32的圆环上，

然后根据k-v的key值进行hash运算得到hashcode，判断其处于哪两个节点之间，然后决定存放在哪个服务器上。

这个算法虽然可以减轻一部分由于加服务器带来的问题。但是也无法完全避免。

Consistent Hashing最大限度地抑制了hash键的重新分布。另外要取得比较好的负载均衡的效果，往往在服务器数量比较少的时候需要增加虚拟节点来保证服务器能均匀的分布在圆环上。因为使用一般的hash方法，服务器的映射地点的分布非常不均匀。使用虚拟节点的思想，为每个物理节点（服务器）在圆上分配100～200个点。这样就能抑制分布不均匀，最大限度地减小服务器增减时的缓存重新分布。用户数据映射在虚拟节点上，就表示用户数据真正存储位置是在该虚拟节点代表的实际物理服务器上。

看到我加了一个Node4节点，只影响到了一个Key值的数据，本来这个Key值应该是在Node1服务器上的，现在要去Node4了。采用一致性Hash算法，的确也会影响到整个集群，但是影响的只是加粗的那一段而已，相比余数Hash算法影响了远超一半的影响率，这种影响要小得多。更重要的是，集群中缓存服务器节点越多，增加节点带来的影响越小，很好理解。换句话说，随着集群规模的增大，继续命中原有缓存数据的概率会越来越大，虽然仍然有小部分数据缓存在服务器中不能被读到，但是这个比例足够小，即使访问数据库，也不会对数据库造成致命的负载压力。