redis集群

 

根据一些测试整理出来的一份方案:

 

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

 

1.2 多实例测试

前提是系统网卡软中断均衡到多CPU核心处理,测试机器网卡开启RSS,有16个队列:

 

操作:10字节Value SET,服务端开启8个实例,四台客户端服务器每台开启两个redis-benchmark,每个client 速度近4W/s,服务端总处理30w/s左右。

 

网卡流量:

 

image

 

其中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

 

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

 

切换流程:

 

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 .twitter用它主要减少前端与缓存服务间网络连接数。

 

特点:快、轻量级、减少后端Cache Server连接数、易配置、支持ketama、modula、random、常用hash 分片算法。

 

image

 

这里使用keepalived实现高可用主备方案,解决proxy单点问题;

 

优点:

 

1. 对于客户端而言,redis集群是透明的,客户端简单,遍于动态扩容

 

2. Proxy为单点、处理一致性hash时,集群节点可用性检测不存在脑裂问题

 

3. 高性能,CPU密集型,而redis节点集群多CPU资源冗余,可部署在redis节点集群上,不需要额外设备

 

 

 

7 . 一致性hash

使用zookeeper 实现一致性hash。

 

redis服务启动时,将自己的路由信息通过临时节点方式写入zk,客户端通过zk client读取可用的路由信息。

 

 

 

具体实现见我另外一篇:redis 一致性hash

 

 

8 . 监控工具

历史redis运行查询:CPU、内存、命中率、请求量、主从切换等

 

实时监控曲线

 

短信报警

 

使用基于开源Redis Live 修改工具,便于批量实例监控,基础功能都已实现,细节也将逐步完善。

 

源码地址如下:

 

https://github.com/LittlePeng/redis-monitor  

原文网址http://www.cnblogs.com/lulu/archive/2013/06/10/3130878.html 

### Redis 集群的搭建与配置 #### 一、Redis 集群简介 Redis 是一种高性能的键值存储系统,支持多种数据结构操作。通过集群模式可以实现分布式存储和高可用性。Redis 集群允许多个 Redis 实例协同工作,提供更高的吞吐量和更强的数据持久化能力。 --- #### 二、环境准备 在开始之前,需确认以下条件已满足: - 所有服务器的操作系统版本一致(如 CentOS 7 或 Windows),并安装了相同版本的 Redis 软件。 - 已关闭防火墙或开放必要的端口(默认 Redis 使用 6379 及其衍生端口)。 - 每台服务器上至少有两个 Redis 实例运行,分别作为主节点和从节点[^1]。 --- #### 三、具体步骤 ##### 1. 下载并解压 Redis 文件 下载指定版本的 Redis 压缩包(如 Redis 6.2.5 或更高版本),将其解压到目标路径下。例如,在 Linux 中执行以下命令: ```bash wget http://download.redis.io/releases/redis-6.2.5.tar.gz tar -zxvf redis-6.2.5.tar.gz cd redis-6.2.5 make ``` ##### 2. 创建多个实例目录 为每个 Redis 实例创建独立的工作目录,并复制 `redis.conf` 至对应文件夹中。例如: ```bash mkdir -p /service/redis/{6379,6380} cp redis.conf /service/redis/6379/ cp redis.conf /service/redis/6380/ ``` ##### 3. 修改配置文件 编辑每个实例下的 `redis.conf` 文件,设置不同的监听端口号和其他必要参数。以下是关键配置项: - 设置绑定 IP 地址:`bind 0.0.0.0` - 关闭保护模式:`protected-mode no` - 开启集群功能:`cluster-enabled yes` - 指定集群配置文件位置:`cluster-config-file nodes-{port}.conf` - 设定日志级别:`loglevel notice` ##### 4. 启动 Redis 实例 依次启动各个 Redis 实例。例如: ```bash redis-server /service/redis/6379/redis.conf redis-server /service/redis/6380/redis.conf ``` 如果是在多台物理机上部署,则需要远程登录每台机器重复上述过程[^2]。 ##### 5. 构建集群拓扑 利用 `redis-cli` 的集群管理工具完成初始化操作。假设当前存在六个节点分布在三台主机上,则可输入如下指令构建集群关系: ```bash redis-cli --cluster create \ 192.168.x.y:6379 192.168.x.z:6379 ... \ --replicas 1 ``` 其中 `--replicas` 参数表示每个主节点分配几个副本[^4]。 ##### 6. 验证集群状态 最后可以通过以下方式验证集群是否正常运作: ```bash redis-cli -c -h {任意IP} -p {任一口号} CLUSTER INFO CLUSTER NODES PING SET key value GET key ``` --- #### 四、注意事项 - 如果使用 Docker 容器来部署 Redis 集群,请确保容器间网络互通良好。 - 对于 Windows 平台上的开发测试场景,可通过批处理脚本来简化服务启动流程[^3]。 --- #### 五、示例代码片段 下面展示了一个简单的 Python 程序用于连接至 Redis 集群并向其中写入一条记录: ```python import redis r = redis.StrictRedisCluster(startup_nodes=[{"host": "127.0.0.1", "port": "6379"}], decode_responses=True) r.set('foo', 'bar') print(r.get('foo')) ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值