分布式架构 Redis优化及高可用
分布式架构 Redis优化及高可用
优化说明:
Redis底层通讯协议对管道提供了支持,通过管道可以一次性发送多条命令,执行完后一次性将结果取回
Redis管道API命令中未体现、但支持管道
优化方案
- 1.精简键名和检键值
- 2.合理设计存储数据结构和数据关系,减少数据冗余
- 3.使用mset来赋值、高于set效率,类似 lpush、zadd等批量
- 4.如果条件允许,尽量使用LUA脚本来辅助获取和操作数据(LUA脚本所有指令一次性完成,效率高),如条件删除
- 5.hash结构来存储对象,占用少内存(zipmap存储数据值)
- 6.设置maxmemory 最大物理内存,使用了配置物理内存后开始拒接后续请求
- 7.数据采用RDB方式进行数据持久化备份,建议只在Slave上进行RDB持久化,而且较长的时间备份一次就好,(如20分钟保存一次 避免AOF带来继续IO操作,也避免了AOF
Rewrite最后将rewrite过程中产生的新数据写到新文件造成的阻塞,当然极端情况如果M/S同时挂了,可能会损失20分钟的数据) - 8.考虑在一台服务器启动多个Redis实例、充分利用CPU调度资源(但会带来严重的IO竞争,设置错开重写AOF)
高可用说明:
Redis单节点存在宕机的风险,为了解决这种风险,需要针对其进行高可用方案,
为了达到高效状态使其单台宕机情况下,业务正常运转
高可用方案如下
- 1.Redis复制
- 2.Redis集群 (version >=3.0)
复制描述
Redis支持复制功能,实现当一台服务器数据更新后,自动将新数据同步到另一台服务器,可以做Master主节点用于读写、Slave从节点用于读
复制的优势
- 1.实现读写分离
- 2.利于主服务器崩溃后数据恢复
复制开启过程:
从数据库redis.conf需开启“saveof 主服务器ip 主服务器端口” (saveof 127.0.0.1 6379)
通过info replication : 查看复制节点信息
slave-read-only 设置redis只读
slave-serve-stale-data 设置yes,用于响应主从同步期间,新的请求结果
repl-ping-slave-period 设置从节点向主节点报告心跳,默认10s
repl-timeout 设置主动超时时间
复制特性
- 如1主1丛部署结构 期间master出现问题,slave节点可以动态指向新的主节点服务器
从服务器运行 slaveof 可支持运行期间修改slave节点同步信息,(如 saveof 127.0.0.1 6390 ,从节点断掉和6379主从关系转向指定新的服务器) - 如1主1丛部署结构 期间master宕机,从服务器可以升级为主服务器
从服务器运行 slaveof no one,自动升级为主服务器
监控工具(哨兵)
实现原理:当主服务器宕机后,多个从服务中投票选举1个用于充当主服务器,选举轮次可能存在失败,多次选举最终达到成功状态
用途:监控主从服务器运行是否正常,当主服务器出现异常,自动将从服务器升级为主数据库
开启:
建立setinal.conf文件,设置要监控的服务器清单
setinal monitor redis主名称 地址 端口 1(选举参数)
/usr/local/bin/redis-setinal setinal.conf
Redis拆分数据过程
当一台Redis服务器存储的数据量过大,首先会采用垂直数据拆分,举例如下:
RedisA 存在(用户、产品、订单)数据,拆分成,RedisA、RedisB、RedisC分别存放 用户、产品、订单数据
针对RedisA、RedisB、RedisC还可以进行父子Master-Slave方式进行扩展
假如其配置是32G,按照5K条数据1M,保守估计可存储2-3亿数据
复制会存在问题及处理
复制中Redis每个数据库节点都拥有完整的数据,复制的总数据量受限于内存最小的数据库节点
由于复制数据量过大, 已经超过了复制的数据库内存最小的数据库节点的物理内存,复制过程就失败了
Redis集群
官网提供集群架构如下
如图所示,体现以下方面
- 所有的Redis节点互联,内部使用二进制协议优化传输速度和宽带
- 节点的Fail是通过集群中超过半数的节点监测失效时才生效
- 客户端与Redis节点直连,不需要中间Proxy代理,客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可
- 集群把所有物理节点映射到(0-16383)插槽上,集群负责维护 (节点-插槽-值)关系
集群描述
针对以上单个复制集存在问题,此时可多个复制集进行集群,形成水平扩展,每个复制集只存储整个复制集一分部数据
Redis分片:将数据拆分到多个Redis实例过程,这样每个Redis只包含实例的一部分完整数据
针对Redis3.0之前的版本,依靠客户端分片来完成集群,之后Redis支持集群模式,还提供网络分区后的访问性和支撑对主数据库的故障恢复
使用集群后,只能使用默认的0号数据库
分片方式如下
- 跟业务有关系:按照范围分片:如 时间、数据条数、编码等
- 跟业务无关系:一致性hash
分片的缺点
- 数据备份麻烦、聚集需要多个实例和主机持久化文件
- 不好扩容
- 不支持涉及多建操作,如果操作指令分在不同节点存在问题
- 故障恢复处理比较棘手
Redis3.0 集群优势
- 将数据自动切分到多个节点的能力
- 当集群中的一部分节点失效或者无法进行通讯时, 仍然可以继续处理命令请求的能力
总结:
Redis建议使用hash结构存储数据、数据传输、同步更高效、高可用方案优先级别如下:
1.单节点 父子级复制
2.多节点,垂直数据拆分并父子级复制,加上哨兵监控
3.分布式集群
作者简介:张程 技术研究
更多文章请关注微信公众号:zachary分解狮 (frankly0423)