Redis 集群方案 Dear 丶 2022-08-18 03:16 192阅读 0赞 根据一些测试整理出来的一份方案: # 1. Redis 性能 # > 对于redis 的一些简单测试,仅供参考: > > 测试环境:Redhat6.2 , Xeon E5520(4核)\*2/8G,1000M网卡 > > Redis 版本:2.6.9 > > > > 客户端机器使用redis-benchmark 简单GET、SET操作: > > ## 1. 1单实例测试 ## > > 1. Value大小:10Byte~1390Byte > > 处理速度: 7.5 w/s,速度受单线程处理能力限制 > > 2. Value 大小:1400 左右 > > 处理速度突降到5w/s 样子,网卡未能跑满;由于请求包大于MTU造成TCP分包,服务端中断处理请求加倍,造成业务急剧下降。 > > 3. Value大小:>1.5 k > > 1000M网卡跑满,速度受网卡速度限制 > 处理速度与包大小大概关系如下: > > [![image][]][image 1] > > ## 1.2 多实例测试 ## > > 前提是系统网卡软中断均衡到多CPU核心处理,测试机器网卡开启RSS,有16个队列: > > 操作:10字节Value SET,服务端开启8个实例,四台客户端服务器每台开启两个redis-benchmark,每个client 速度近4W/s,服务端总处理30w/s左右。 > > 网卡流量: > > [![image][image 2]][image_image 2] > > 其中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消耗、业务量。如果多实例是为了提高处理能力,需要注意配置网卡软中断均衡,否则处理能力也无法提升。 # 2. Redis 持久化 # > 测试策略: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对外提供服务完全无任何影响。 # 3. Redis 主从复制 # > 因为目前版本没有mysql 主从那样的增量备份,对网路稳定性要求很高,如果频繁TCP连接断开会对服务器和网络带来很大负担。 > > 就目前生产环境主从机器部署同一个机架下,几个月都不会又一次连接断开重连的情况的。 # 4. keepalived 简介 # > 参考官方文档:[http://keepalived.org/pdf/sery-lvs-cluster.pdf][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 不抢占。 # 5. 通过keepalived实现的高可用方案 # > > > [![image][image 3]][image_image 3] > > 切换流程: > > 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 文件(避免重启加载慢) # 6. 使用Twemproxy 实现集群方案 # > 一个由twitter开源的c版本proxy,同时支持memcached和redis,目前最新版本为:0.2.4,持续开发中;[https://github.com/twitter/twemproxy][https_github.com_twitter_twemproxy] .twitter用它主要减少前端与缓存服务间网络连接数。 > > 特点:快、轻量级、减少后端Cache Server连接数、易配置、支持ketama、modula、random、常用hash 分片算法。 > > [![image][image 4]][image_image 4] > > 这里使用keepalived实现高可用主备方案,解决proxy单点问题; > > 优点: > > 1. 对于客户端而言,redis集群是透明的,客户端简单,遍于动态扩容 > > 2. Proxy为单点、处理一致性hash时,集群节点可用性检测不存在脑裂问题 > > 3. 高性能,CPU密集型,而redis节点集群多CPU资源冗余,可部署在redis节点集群上,不需要额外设备 # 7 . 一致性hash # > 使用zookeeper 实现一致性hash。 > > redis服务启动时,将自己的路由信息通过临时节点方式写入zk,客户端通过zk client读取可用的路由信息。 > > > > 具体实现见我另外一篇:[redis 一致性hash][redis _hash] # 8 . 监控工具 # > 历史redis运行查询:CPU、内存、命中率、请求量、主从切换等 > > 实时监控曲线 > > 短信报警 > > 使用基于开源Redis Live 修改工具,便于批量实例监控,基础功能都已实现,细节也将逐步完善。 > > 源码地址如下: > > [https://github.com/LittlePeng/redis-monitor][https_github.com_LittlePeng_redis-monitor] > > > > > > > > 评论列表 > > > > [\#1楼][1] 2013-08-04 17:22 [蓝色京广线][Link 1] [ ][Link 2] > > 楼主的方案是否已经在生产环境中应用了? > > 支持(0) 反对(0) > > > > [\#2楼][2] \[ 楼主\] 2013-08-07 23:23 [LittlePeng][] [ ][Link 3] > > [@][1]蓝色京广线 > 嗯嗯,生产环境大多使用 redis+keepalived主备方式部署 > > 支持(0) 反对(0) > > > > [\#3楼][3] 2013-08-24 10:40 [gentlepong][] [ ][Link 4] > > 不错 感谢楼主分享! > > 支持(0) 反对(0) > > > > [\#4楼][4] 2013-09-26 19:45 [cluRty][] [ ][Link 5] > > 我们用的是master/slave的方式。这种方式得学习学习。 > > 支持(0) 反对(0) > > > > [\#5楼][5] 2013-10-07 17:39 [加盟][Link 6] [ ][Link 7] > > 楼主的做法,跟我之前参与的redis-ha项目很相似,方便透漏在哪高就吗 > > 支持(0) 反对(0) > > > > [\#6楼][6] 2013-10-12 17:31 [考拉鼠][Link 8] [ ][Link 9] > > 请问redis+keepalived主备方式对外提供同一个VIP,这种处理会不会导致内存的极大浪费?同一时刻只有一台机器对外提供读服务 > > 支持(0) 反对(0) > > > > [\#7楼][7] \[ 楼主\] 2013-10-16 13:55 [LittlePeng][] [ ][Link 3] > > [@][6]考拉鼠 > 对,浪费一半机器,对于重要、不能丢数据的业务,这是必要的 > > 如果业务要求不能么高,而且机器数也较多,可选用一致性hash方案 > > 支持(0) 反对(0) > > > > [\#8楼][8] 2013-10-21 09:39 [考拉鼠][Link 8] [ ][Link 9] > > 有没有考虑通过zookeeper实现,服务端通过node\_manager这样的工具实时监控集群状态,zookeeper维护一个集群状态。客户端通过zookeeper读取集群状态,采用一致性hash做shard,写操作在master执行,读操作在slave中轮询。 > > 支持(0) 反对(0) > > > > [\#9楼][9] 2013-11-06 21:34 [zd\_lff][zd_lff] [ ][Link 10] > > LZ您好,问一下 有没有方法能快速将数据通过Twemproxy 代理导入redis中? > Thank You > > 支持(0) 反对(0) > > > > [\#10楼][10] 2014-01-06 11:21 [bolobeach][] [ ][Link 11] > > 我弱弱的问一句,如果master宕机了,启用slave的时候,如果master数据库的数据没有同步到slave,那么你是怎么解决的。。 > > 支持(0) 反对(0) > > > > [\#11楼][11] 2014-03-21 16:39 [林义皓][Link 12] [ ][Link 13] > > 你好,我想问一下,我在一台服务器16G的内存8核CPU上面测试,redis.conf配置文件用的是默认参数,为什么写的效率只有几百条每秒,需要在配置参数上做调整吗 > > 支持(0) 反对(0) > > > > [\#12楼][12] \[ 楼主\] 2014-03-21 23:50 [LittlePeng][] [ ][Link 3] > > [@][11]林义皓 > 应该和默认参数没啥关系,建议检查一下redis-server 资源占用,还有就是包大小、带宽限制、客户端发送性能 > > 支持(0) 反对(0) > > > > [\#13楼][13] \[ 楼主\] 2014-03-21 23:57 [LittlePeng][] [ ][Link 3] > > [@][10]bolobeach > > 这种同步方式切换瞬间必然丢失少量数据,看业务场景需求,大多可以忽略不计,就算mysql 主从大多此种方式。 > 当然要强一致性,那现在的redis版本不支持,可以client实现double write。 > > 支持(0) 反对(0) > > > > [\#14楼][14] 2014-03-26 16:32 [snake\_j][snake_j] [ ][Link 14] > > 请教下LZ,keepalived结构中,master的2台redis如何保持数据的一致呢? > 能不能留个QQ方便请教下,谢谢! > > 支持(0) 反对(0) > > > > [\#15楼][15] 2015-04-14 09:58 [深蓝医生][Link 15] [ ][Link 16] > > Mark,学习 > > 支持(0) 反对(0) > > > > [\#16楼][16] 2015-05-15 11:49 [晓月天城][Link 17] [ ][Link 18] > > mark > > 支持(0) 反对(0) > > > > [\#17楼][17] 2015-07-03 11:18 [lubberland66][] [ ][Link 19] > > 第6个方案,如果redis节点故障或增加redis节点,twemproxy无法感知,只能改twemproxy的配置,然后重启? > > 支持(0) 反对(0) > > > > [\#18楼][18] \[ 楼主\] 2015-07-16 17:53 [LittlePeng][] [ ][Link 3] > > [@][17]lubberland66 > 节点故障是知道的,提供一致性hash模式的 > 目前版本不支持动态加载配置,添加节点只能重启了。不过服务是无状态的,无影响重启很容易做 > > 支持(0) 反对(0) > > > > [\#19楼][19] 2015-07-20 10:40 [lubberland66][] [ ][Link 19] > > [@][18]LittlePeng > [引用][18] @lubberland66 > 节点故障是知道的,提供一致性hash模式的 > 目前版本不支持动态加载配置,添加节点只能重启了。不过服务是无状态的,无影响重启很容易做 > 可以把6 和 7 结合起来吧,改改twemproxy的源码,订阅zookeeper里的配置信息,添加节点就不用重启了,正在看twemproxy的源码 > > 支持(0) 反对(0) > > > > [\#20楼][20] 2015-09-08 17:19 [野猪大改造][Link 20] [ ][Link 21] > > 测试写的很好!!! > > 支持(0) 反对(0) > > > > [\#21楼][21] 2015-09-08 17:21 [野猪大改造][Link 20] [ ][Link 21] > > redis-live 使用有遇到bug?比如redis停止什么? > > 支持(0) 反对(0) > > > > [\#22楼][22] 2015-09-21 14:10 [rana4504][] [ ][Link 22] > > 在实用master/slave模式的时候,遇到一个问题,想master写数据的时候,直接去slave读,数据有问题。怎么查看数据是否已经同步到slave? > 例如:向master写一个hashset,有1000条数据,直接向slave读的时候,可能只读出800条,下一次在读的时候,可能就是1000条了。这个问题怎么处理,请各位指点一下,谢谢!!! > > 支持(0) 反对(0) > > > > [\#23楼][23] \[ 楼主\] 2015-10-19 16:32 [LittlePeng][] [ ][Link 3] > > [@][22]rana4504 > 1000条数据 分1000次写,必然有这个问题。redis 是基于command的异步复制,可使用MHSET、或事务解决 > > 支持(0) 反对(0) > > > > [\#24楼][24] 2015-10-30 11:47 [54ebb][] [ ][Link 23] > > @LittlePeng 请问基于keepalived的针对机房的本地化、一主多从这种需求,有哪些资料或代码吗? > > > [image]: /images/20220731/f4c1eb6be21a4f9d85d703672cb4216a.png [image 1]: http://images.cnitblog.com/blog/28886/201306/10164145-a7d6055272894bcc8e893a5eb977ade2.png [image 2]: http://images.cnitblog.com/blog/28886/201306/10164148-5bdac6a03a6c414490810a44bad16e1d.png [image_image 2]: /images/20220731/feb7f3f5fcfd40e0b7b9d15d4b9ac333.png [http_keepalived.org_pdf_sery-lvs-cluster.pdf]: http://keepalived.org/pdf/sery-lvs-cluster.pdf [image 3]: http://images.cnitblog.com/blog/28886/201306/10164150-983fdb63f1f34b81947f384e4d819d35.png [image_image 3]: /images/20220731/6bb1124701564c81904ee963251cf7dc.png [https_github.com_twitter_twemproxy]: https://github.com/twitter/twemproxy [image 4]: http://images.cnitblog.com/blog/28886/201306/10164153-10d5562feeb5478cb0dd3df29293937e.png [image_image 4]: /images/20220731/435885f5f87448259c5cb5cbeb845e3a.png [redis _hash]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130906.html [https_github.com_LittlePeng_redis-monitor]: https://github.com/LittlePeng/redis-monitor [1]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2742944 [Link 1]: http://www.cnblogs.com/stzh2k/ [Link 2]: http://msg.cnblogs.com/send/%E8%93%9D%E8%89%B2%E4%BA%AC%E5%B9%BF%E7%BA%BF [2]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2745798 [LittlePeng]: http://www.cnblogs.com/lulu/ [Link 3]: http://msg.cnblogs.com/send/LittlePeng [3]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2759330 [gentlepong]: http://www.cnblogs.com/bruceyan/ [Link 4]: http://msg.cnblogs.com/send/gentlepong [4]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2783064 [cluRty]: http://home.cnblogs.com/u/378600/ [Link 5]: http://msg.cnblogs.com/send/cluRty [5]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2787496 [Link 6]: http://home.cnblogs.com/u/445436/ [Link 7]: http://msg.cnblogs.com/send/%E5%8A%A0%E7%9B%9F [6]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2791707 [Link 8]: http://www.cnblogs.com/piaolingxue/ [Link 9]: http://msg.cnblogs.com/send/%E8%80%83%E6%8B%89%E9%BC%A0 [7]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2794552 [8]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2798062 [9]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2811295 [zd_lff]: http://www.cnblogs.com/zdllff/ [Link 10]: http://msg.cnblogs.com/send/zd_lff [10]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2852786 [bolobeach]: http://www.cnblogs.com/bolobeach/ [Link 11]: http://msg.cnblogs.com/send/bolobeach [11]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2900574 [Link 12]: http://home.cnblogs.com/u/615711/ [Link 13]: http://msg.cnblogs.com/send/%E6%9E%97%E4%B9%89%E7%9A%93 [12]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2900778 [13]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2900780 [14]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#2904396 [snake_j]: http://home.cnblogs.com/u/617374/ [Link 14]: http://msg.cnblogs.com/send/snake_j [15]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#3162096 [Link 15]: http://www.cnblogs.com/bluedoctor/ [Link 16]: http://msg.cnblogs.com/send/%E6%B7%B1%E8%93%9D%E5%8C%BB%E7%94%9F [16]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#3184668 [Link 17]: http://www.cnblogs.com/-900401/ [Link 18]: http://msg.cnblogs.com/send/%E6%99%93%E6%9C%88%E5%A4%A9%E5%9F%8E [17]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#3220761 [lubberland66]: http://home.cnblogs.com/u/599912/ [Link 19]: http://msg.cnblogs.com/send/lubberland66 [18]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#3229196 [19]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#3231185 [20]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#3262652 [Link 20]: http://www.cnblogs.com/ChrisRIM/ [Link 21]: http://msg.cnblogs.com/send/%E9%87%8E%E7%8C%AA%E5%A4%A7%E6%94%B9%E9%80%A0 [21]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#3262654 [22]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#3270934 [rana4504]: http://www.cnblogs.com/rana4504/ [Link 22]: http://msg.cnblogs.com/send/rana4504 [23]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#3287671 [24]: http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html#3295228 [54ebb]: http://home.cnblogs.com/u/232804/ [Link 23]: http://msg.cnblogs.com/send/54ebb
还没有评论,来说两句吧...