Redis 集群方案

Dear 丶 2022-08-18 03:16 237阅读 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