当前位置:Gxlcms > mysql > Memcached集群/分布式的单点故障

Memcached集群/分布式的单点故障

时间:2021-07-01 10:21:17 帮助过:24人阅读

口水: Memcached在2009风靡全球,现在对Memcached态度大家各自褒贬不一,话不多说进入正题。 我看到过这样一段文字 memcached如何处理容错的? 不处理!:) 在memcached节点失效的情况下,集群没有必要做任何容错处理。如果发生了节点失效,应对的措施完全取

口水:Memcached在2009风靡全球,现在对Memcached态度大家各自褒贬不一,话不多说进入正题。

我看到过这样一段文字

memcached如何处理容错的?
不处理!:) 在memcached节点失效的情况下,集群没有必要做任何容错处理。如果发生了节点失效,应对的措施完全取决于用户。节点失效时,下面列出几种方案供您选择:
* 忽略它! 在失效节点被恢复或替换之前,还有很多其他节点可以应对节点失效带来的影响。
* 把失效的节点从节点列表中移除。做这个操作千万要小心!在默认情况下(余数式哈希算法),客户端添加或移除节点,会导致所有的缓存数据不可用!因为哈希参照的节点列表变化了,大部分key会因为哈希值的改变而被映射到(与原来)不同的节点上。
* 启动热备节点,接管失效节点所占用的IP。这样可以防止哈希紊乱(hashing chaos)。


同学们,根据上面的说法,memcached其中一个节点失效以后,memcached本身是没有任何策略维持失效转发的,这对于大型系统是一个无法接受的事实。

Memcached分布式每个服务器端本身没有相互相连的关系,数据分布是由客户端来维持的,也可以说Memcached还没有为集群提供真的高可用方案,因为从集群的定义上来说需要满足:1.压力分载 2.失效转发。

在项目组中lianjie.you同学问我如果在分布式中的其中一台Memcached节点down掉了,应该如何解决?我当时愣住了,一时之间还不能给出任何完整的答案。

今早在座公车来上班的路上用手机上网Google了一下,发现原来在网上有很多人与我们有相同的问题,我Google的关键字是“Memcached 单点” 、“Memcached 单点故障”。给出的搜索结果都不算让人满意,我才打算写一篇关于解决集群中Memcached单点故障的文章。Javabloger只向大家提供2种解决思路,暂时不提供具体代码。

现象描述:
在客户端连接的部分写入多个服务器端的ip地址,客户端将会自动的把缓存数据分布的放在每个不同的机器上,如图所示:

https://img.gxlcms.com//Uploads-s/new/2019-09-30-201930/092Ia530-0.png
查看大图请点击这里

现象后果:
如果其中一个缓存节点的机器down机,那么客户端存入的缓存数据将会丢失一部分,就是图中红色字体描述的“Losed 33% Cache Data”,也就是说那部分数据彻底没有了!如果是用户的关键性信息那么就玩大了,如图所示:https://img.gxlcms.com//Uploads-s/new/2019-09-30-201930/092I92544-1.png
查看大图请点击这里

解决方案1:本地备份缓存
在本地放一份缓存,同时也在分布式Memcached上放一份缓存,如果当其中一台节点当机了,客户端程序直接读取本地的缓存,本地客户端维护一个HashMap即可,这样的方案虽然很简陋,但是可以满足一部分场景的需要,当你很急需的时候可以作为临时方案暂时替代一下。

解决方案2:采用缓存代理服务器
采用 Magent 缓存代理,防止单点现象,缓存代理也可以做备份,通过客户端连接到缓存代理服务器,缓存代理服务器连接缓存服务器,缓存代理服务器可以连接多台Memcached机器可以将每台Memcached机器进行数据同步。这样的架构比较完善了,如果其中一台缓存代理服务器down机,系统依然可以继续工作,如果其中一台Memcached机器down掉,数据不会丢失并且可以保证数据的完整性,以上描述的系统架构如图所示:
https://img.gxlcms.com//Uploads-s/new/2019-09-30-201930/092Ia358-2.png
查看大图请点击这里

还是那句话:没有任何架构是最完美的,只是最合适的,任何架构都不可能一步到位,都是经过一步一步演变过来的。

–end–

人气教程排行