Redis 集群方案
<!--[endif]-->
其中8个单数核心CPU全部耗尽,像是超线程没有利用上,测试已经达到很好效果,就没有继续测试下去了。从单实例跑满一个核心7.5w/s,8个实例跑满8个核心,30W/s来看,CPU使用和性能提升不成正比, RSS会造成redis-server线程基本每收到一个请求都切换一次CPU核心,软中断CPU占用太高。这种情况RPS/RFS功能也许就很合适了,RSS只需要映射1~2个核心,然后再讲软中断根据redis-server端口动态转发,保证redis进程都在一个核心上执行,减少进程不必要的切换。
?
开多实例可以充分利用系统CPU、网卡处理小包能力。具体看业务场景,考虑包平均大小、处理CPU消耗、业务量。如果多实例是为了提高处理能力,需要注意配置网卡软中断均衡,否则处理能力也无法提升。
测试策略:AOF + 定时rewriteaof
1. 准备数据量:
1亿,Key:12 字节 Value:15字节,存储为string,进程占用内存12G
2. Dump
文件大小2.8G,执行时间:95s,重启加载时间:112s
2. Bgrewriteaof
文件大小5.1G,执行时间:95s,重启加载时间:165s
3.开启AOF后性能影响(每秒fsync一次):
8K/s SET 操作时:cup 从20% 增加到40%
4.修改1Kw数据:
文件大小:5.6G,重启加载时间:194s
5.修改2K数据
文件大小:6.1G,重启加载时间:200s
另:Redis2.4 版本以后对fsync做了不少优化, bgrewriteaof,bgsave 期间对redis对外提供服务完全无任何影响。
因为目前版本没有mysql 主从那样的增量备份,对网路稳定性要求很高,如果频繁TCP连接断开会对服务器和网络带来很大负担。
就目前生产环境主从机器部署同一个机架下,几个月都不会又一次连接断开重连的情况的。
参考官方文档:http://keepalived.org/pdf/sery-lvs-cluster.pdf
Keepalived 是一个用c写的路由选择软件,配合IPVS 负载均衡实用,通过VRRP 协议提供高可用。目前最新版本1.2.7.Keepalived 机器之间实用VRRP路由协议切换VIP,切换速度秒级,且不存在脑裂问题。可以实现
可以实现一主多备,主挂后备自动选举,漂移VIP,切换速度秒级;切换时可通过运行指定脚本更改业务服务状态。
如两台主机A、B,可以实现如下切换:
1.A 、B 依次启动,A作为主、B为从
2 .主A 挂掉,B接管业务,作为主
3.A 起来,作为从SLAVEOF B
4.B 挂掉,A 切回主
将一台全部作为主,即可实现主从,可做读写分离;也可以通过多个VIP,在一台机器上多个实例中一半主、一半从,实现互备份,两机同时负责部分业务,一台宕机后业务都集中在一台上
安装配置都比较简单:
需要依赖包:openssl-devel(ubuntu 中为 libssl-dev),popt-devel (ubuntu中为libpopt-dev)。
配置文件默认路径:/etc/keepalived/keepalived.conf 也可以手动指定路径,不过要注意的是手动指定需要使用绝对路径。主要要确保配置文件的正确性,keepalived 不会检查配置是否符合规则。
使用keepalived -D 运行,即可启动3个守护进程:一个父进程,一个check健康检查,一个Vrrp,-D将日志写入/var/log/message,可以通过日志查看切换状况。
注意问题:
1. VRRP 协议是组播协议,需要保证主、备、VIP 都在同一个VLAN下
2. 不同的VIP 需要与不同的VRID 对应,一个VLAN 中VRID 不能和其他组冲突
3. 在keepalived 有两个角色:Master(一个)、Backup(多个),如果设置一个为Master,但Master挂了后再起来,必然再次业务又一次切换,这对于有状态服务是不可接受的。解决方案就是两台机器都设置为Backup,而且优先级高的Backup设置为nopreemt 不抢占。
?
<!--[if gte vml 1]><v:shape id="_x0000_i1027" type="#_x0000_t75" alt="Redis 集群议案" href="http://images.cnitblog.com/blog/28886/201306/10164149-517070bfdd8c4ecc832d3ad4e581f87c.png" style='width:436.5pt;height:272.25pt' o:button="t"> <v:imagedata src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\01\clip_image005.png" o:href="http://images.cnitblog.com/blog/28886/201306/10164150-983fdb63f1f34b81947f384e4d819d35.png"/></v:shape><![endif]--><!--[if !vml]--><!--[endif]-->
切换流程:
1. 当Master挂了后,VIP漂移到Slave;Slave 上keepalived 通知redis 执行:slaveof no one ,开始提供业务
2. 当Master起来后,VIP 地址不变,Master的keepalived 通知redis 执行slaveof slave IP host ,开始作为从同步数据
3. 依次类推
主从同时Down机情况:
1. 非计划性,不做考虑,一般也不会存在这种问题
2. 、计划性重启,重启之前通过运维手段SAVE DUMP 主库数据;需要注意顺序:
1. 关闭其中一台机器上所有redis,是得master全部切到另外一台机器(多实例部署,单机上既有主又有从的情况);并关闭机器
2. 依次dump主上redis服务
3. 关闭主
4. 启动主,并等待数据load完毕
5. 启动从
删除DUMP 文件(避免重启加载慢)
?
一个由twitter开源的c版本proxy,同时支持memcached和redis,目前最新版本为:0.2.4,持续开发中;https://github.com/twitter/twemproxy.twitter用它主要减少前端与缓存服务间网络连接数。
特点:快、轻量级、减少后端Cache Server连接数、易配置、支持ketama、modula、random、常用hash 分片算法。
<!--[if gte vml 1]><v:shape id="_x0000_i1028" type="#_x0000_t75" alt="Redis 集群议案" href="http://images.cnitblog.com/blog/28886/201306/10164151-f420e31e69844d859c32ea204976cb84.png" style='width:456.75pt;height:287.25pt' o:button="t"> <v:imagedata src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\01\clip_image007.png" o:href="http://images.cnitblog.com/blog/28886/201306/10164153-10d5562feeb5478cb0dd3df29293937e.png"/></v:shape><![endif]--><!--[if !vml]--><!--[endif]-->
这里使用keepalived实现高可用主备方案,解决proxy单点问题;
优点:
1. 对于客户端而言,redis集群是透明的,客户端简单,遍于动态扩容
2. Proxy为单点、处理一致性hash时,集群节点可用性检测不存在脑裂问题
3. 高性能,CPU密集型,而redis节点集群多CPU资源冗余,可部署在redis节点集群上,不需要额外设备
?
使用zookeeper 实现一致性hash。
redis服务启动时,将自己的路由信息通过临时节点方式写入zk,客户端通过zk client读取可用的路由信息。
?
具体实现见我另外一篇:redis 一致性hash
历史redis运行查询:CPU、内存、命中率、请求量、主从切换等
实时监控曲线
短信报警
使用基于开源Redis Live 修改工具,便于批量实例监控,基础功能都已实现,细节也将逐步完善。
源码地址如下:
https://github.com/LittlePeng/redis-monitor
?