一致性hash

一致哈希

https://zh.wikipedia.org/wiki/%E4%B8%80%E8%87%B4%E5%93%88%E5%B8%8C
一致哈希在互联网分布式缓存中非常有用的几个特性:
冗余少
负载均衡
过渡平滑
存储均衡
关键词单调

Nginx方案
https://github.com/replay/ngx_http_consistent_hash

redis方案
https://github.com/twitter/twemproxy

Memcached方案
https://github.com/couchbase/spymemcached

PHP算法
https://github.com/pda/flexihash

可能存在的问题和解决方案:

memcached(七)failure模式和standby节点
关于failure模式,可以看下memcached官方文档的解释https://code.google.com/p/memcached/wiki/NewConfiguringClient#Failure,_or_Failover

展开来说,在某个memcached节点挂掉或者由于其他故障连接断开的时候,大部分客户端的默认策略都是failover的,也就是会查找下一个可用的memcached节点继续使用,挂掉或者连接不上的节点的数据会转移到其他节点上,路由的策略可以是Round Robin,也可以是一致性哈希。这样的模式在节点意外故障挂掉的情况下运行的很好,但是memached节点也完全可能因为一个意外的事故而短暂挂掉,比如你不小心弄掉了网线又马上接上去,比如机房交换机突然停电又立即恢复了,假设在故障前,用户A正要更新数据到节点A,节点A意外断开,那么这些数 据就更新到下一个有效节点B,但是节点A又马上恢复,这时候用户又从节点A去读数据,读到却是更新前的老数据了(新数据更新到B节点去了),这种情况对用 户来说就非常困惑,你告诉我更新成功,但是看到却还是更新前的数据。

怎么解决呢?一个简单的方案就是所谓failure模式,当某个节点挂掉的时候,不会从节点列表移除,请求也不会转移到下一个有效节点,而是直接将请求置 为失败,就刚才的场景来说,在用户更新数据到节点A的时候,节点A意外断开,那么用户的这次更新请求不会转移到节点B,而是直接告诉用户更新失败,用户再 次查询数据则绕过节点A直接查询后端存储。这种模式很适合这种节点短暂不可用的状况,请求会穿透缓存到后端,但是避免了新旧数据的问题。
Xmemcached支持failure模式,只要你设置下failureMode为true即可

发表评论

电子邮件地址不会被公开。 必填项已用*标注