主页 > 网络知识, 运维知识 > redis集群高可用以及性能的折中方案[原创]

redis集群高可用以及性能的折中方案[原创]

2013年1月25日 发表评论 查看评论
redis集群高可用以及性能的折中方案。
为了实现业务逻辑是实时性,我们直接把redis当成mysql来用,这样这个REDIS集群是作为持久化存储来用的,所以需要考虑到高可用.如果作为缓存使用,则不需要考虑这个。
 
之前明月对redis做的优化是主从读写分离,并且用keepalived和脚本实现的故障自动切换.这种方案也具备了高可用,但是存在下面几个问题:
1.当redis里面存储的数据多到一定程度,并且服务器内存不足的时候,如何扩展是个大问题。
2.写的时候只能是访问master服务器,导致master服务器连接数暴涨,压力也大。
redis的作者也已经在考虑实现集群的问题了。
 
目前为了解决这两个问题,明月引入了twitter在apache上面的一个开源项目twemproxy(nutcracker)。这是一个轻量级的Redis和memcached代理。使用它可以减少缓存服务器的连接数,并且利用它来作分片。这个代理的速度是相当快的,明月在网上查到会有20%的性能损耗,但明月用redis-benchmark做了测试,发现性能几乎是无损的,甚至有时更快。后来找到英文原文,作者是说最差情况下,性能损耗不会多于20%。明月觉得这个很了不起,按道理说,有了一层代理,怎么说都得折损一部分性能,但是他切能使得访问更快。看了源码,原来是用了pipeline.首先redis是支持使用pipeline批处理的。twemproxy与每个redis服务器都会建立一个连接,每个连接实现了两个FIFO的队列,通过这两个队列实现对redis的pipeline访问。将多个客户端的访问合并到一个连接,这样既减少了redis服务器的连接数,又提高了访问性能。
 
当然这个twemproxy也有不足:
1.虽然可以动态移除节点,但该移除节点的数据就丢失了。
2.redis集群动态增加节点的时候,twemproxy不会对已有数据做重分布.maillist里面作者说这个需要自己写个脚本实现
从上面这两点看,twemproxy代理的设计应该是更加倾向于redis缓存集群,对于持久化存储的支持并不充分。
 
 
因此明月整了一个性能和高可用的折中方案。
这个是参考Greenplum这类云数据库的备份方案。下图是K+1方案。
 
 
备份此采用交叉备份方式,也就是每个redis在另外一个服务器上都有一个备份,主备redis配置keepalived实现动态故障切换。
多个twemproxy,配置文件相同,分布也算法相同,直接代理每个keepalived提供的VIP。这里多少个视力情况而定。最好不少于两个。
再通过haproxy将连接负载均衡到多个twemproxy。
这种方式可以将一台REDIS上的压力均摊到多台服务器上。并且对于高可用要求也有一定保障。
 
如果结点较多,也可以做成K+2,既下图方案:
 
这个方案缺点是,如果要动态增加节点,需要自己实现rehash。这个也是用了twemproxy导致的。这种方案性能会有一定损耗。如果不是数据量太大,或者并发数几多,单台redis足以。目前这个只当做后备方案。
 

原创文章,转载请注明: 转载自肚腩照明月'blog

本文链接地址: redis集群高可用以及性能的折中方案[原创]

文章的脚注信息由WordPress的wp-posturl插件自动生成


  1. 本文目前尚无任何评论.

SEO Powered by Platinum SEO from Techblissonline