简单高可用redis架构实践
2017-02-07 00:00
471 查看
摘要:简单高可用redis架构实践
背景:支撑线上千万级别的天级查询请求,要求高可用。
Redis是一个开源、基于C语言、基于内存亦可持久化的高性能NoSQL数据库,同时,它还提供了多种语言的API。近日,Redis3.0在经过6个RC版本后,其正式版终于发布了。Redis3.0的最重要特征是对Redis集群的支持,此外,该版本相对于2.8版本在性能、稳定性等方面都有了重大提高。
综合考虑之后扩展性和稳定性之后,选择版本redis3.2.3-1版本进行部署
评估:单机的稳定数据承载量:2000w(126/1.56)0.6=96923w
结论:9T的数据承载量,远超当前千万级别的数据量
写操作1000w,80%在20ms一下,98%在30ms,最大218ms,qps5w/s,总耗时197s
读操作1000w,97%在10ms一下,99.99%在24ms,qps6w/s,总耗时160s
评估:当前的调用量在千万每天,qps的话在百/s。
结论:当前单机的redis完全满足需求
因此:在单机远能够满足当下业务需求的情况下,决定不采用的集群的方式来部署redis,减少技术债务风险。
容灾和稳定性,经过思考之后采用采用极简的主从从结构,001实时同步数据002和003;001读写,002,003只读,机构图如下
https://redis.io/
添加密码:pwd
关闭压缩:rdbcompressionno【硬盘最够,降低cpu的能耗更利于提升性能】
开启守护进程:daemonizeyes【master开启守护,增加稳定性】
关闭protect-mode:允许他机器访问
添加白名单:bindxxx
修改log地址,pid地址和数据存储地址:logfilepidfile【便于维护和安全】
添加慢查询:slowlog-log-slower-than500【根据业务需求,便于优化】
最大内存限制:maxmemory【考虑稳定性和性能,一般不超过最大内存的60%】
设置主库:slaveofip:port
主库密码:masterauthmasterpwd
只读:slave-read-onlyyes
备份:master全量备份,slave全量备份。
备份安全:本机保存,hadoop同步保存一份。
监控和探活:监控机分钟级探活和预警
被动容灾:
slave宕机:重启之后直接从master恢复
master宕机且硬盘数据为损坏:重启后数据自动恢复且和从库一致。
master宕机且数据损坏:删除损坏数据,使用slave1的数据恢复,保证数据一致。
master和slave1同时宕机:slave2保证读正常,业务不影响,利用slave2数据备份恢复master,启动slave即可
三台全宕机:服务挂掉,从hadoop获取数据恢复服务。
noeviction->谁也不删,直接在写操作时返回错误。
之后采用:
volatile-lru->根据LRU算法删除带有过期时间的key。最少使用算法删除。
如果达到内存限制,手工清理,通过监控脚本监控内存情况
背景:支撑线上千万级别的天级查询请求,要求高可用。
一、方案调研
1.1redis版本选择
redis当前主流版本是redis2.x和redis3.x,3.0对集群支持比较不错,官方解释如下:Redis是一个开源、基于C语言、基于内存亦可持久化的高性能NoSQL数据库,同时,它还提供了多种语言的API。近日,Redis3.0在经过6个RC版本后,其正式版终于发布了。Redis3.0的最重要特征是对Redis集群的支持,此外,该版本相对于2.8版本在性能、稳定性等方面都有了重大提高。
综合考虑之后扩展性和稳定性之后,选择版本
1.2是否选择搭建集群
是否搭建集群关键要看单机是否能够满足业务需求,做了个简单的数据评估。数据量评估
测试:单机写入2000w业务数据,占用内存1.5g,本机126g内存评估:单机的稳定数据承载量:2000w(126/1.56)0.6=96923w
结论:9T的数据承载量,远超当前千万级别的数据量
性能评估
测试:简单压测了下写操作1000w,80%在20ms一下,98%在30ms,最大218ms,qps5w/s,总耗时197s
读操作1000w,97%在10ms一下,99.99%在24ms,qps6w/s,总耗时160s
评估:当前的调用量在千万每天,qps的话在百/s。
结论:当前单机的redis完全满足需求
因此:在单机远能够满足当下业务需求的情况下,决定不采用的集群的方式来部署redis,减少技术债务风险。
1.3初定方案和架构图
选定了版本和基本部署方案之后,主要考虑服务的二、实现过程
2.1redis安装
此处略去,参考官方文档2.2配置读写master
修改端口:port【目的:简单的修改默认端口是最好的防攻击】添加密码:pwd
关闭压缩:rdbcompressionno【硬盘最够,降低cpu的能耗更利于提升性能】
开启守护进程:daemonizeyes【master开启守护,增加稳定性】
关闭protect-mode:允许他机器访问
添加白名单:bindxxx
修改log地址,pid地址和数据存储地址:logfilepidfile【便于维护和安全】
添加慢查询:slowlog-log-slower-than500【根据业务需求,便于优化】
最大内存限制:maxmemory【考虑稳定性和性能,一般不超过最大内存的60%】
2.3配置只读slave
同master设置主库:slaveofip:port
主库密码:masterauthmasterpwd
只读:slave-read-onlyyes
2.4启动测试
启动主库写入数据
进入从库查看
最初没有数据,主库写入之后,从库去到数据查看log确认过程
三、架构能力评估
3.1容灾能力
主动容灾备份:master全量备份,slave全量备份。
备份安全:本机保存,hadoop同步保存一份。
监控和探活:监控机分钟级探活和预警
被动容灾:
slave宕机:重启之后直接从master恢复
master宕机且硬盘数据为损坏:重启后数据自动恢复且和从库一致。
master宕机且数据损坏:删除损坏数据,使用slave1的数据恢复,保证数据一致。
master和slave1同时宕机:slave2保证读正常,业务不影响,利用slave2数据备份恢复master,启动slave即可
三台全宕机:服务挂掉,从hadoop获取数据恢复服务。
3.2性能评估
压测数据,参见方案选择,完全hold住。四、问题思考
4.1内存清理策略
暂时采用:noeviction->谁也不删,直接在写操作时返回错误。
之后采用:
volatile-lru->根据LRU算法删除带有过期时间的key。最少使用算法删除。
如果达到内存限制,手工清理,通过监控脚本监控内存情况
4.2伸缩性和单节点问题
扩展slave可以直接扩展,扩展master需要master之间数据同步,暂时是个瓶颈。对于主读业务的需求,暂时问题不大;写需求的话,暂时的想法是代码转写的方式。4.3采用redissentinal监听
默认不错的监听,尝试了下效果不错,还在调研中,配置conf即可,完成后可以查看监听的情况2 3 4 5 6 7 8 | #Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=redis115,status=ok,address=ip:port,slaves=2,sentinels=1 |
五:常用代码
2 3 4 5 6 7 8 | psaux|grepredis|awk'{print$2}'|xargskill-9 #重启,指定conf /home/work/xxx/bin/redis-server/home/work/xxx/etc/redis.conf #压测,具体参数可以参考benchmark [cuihuan@cuihuanbin]$./redis-benchmark-h127.0.0.1-p端口-a密码-c1000-n10000000-d1024-r100000-tset,get,incr,del |
相关文章推荐
- 【redis学习三】简单高可用redis架构实践 靠谱崔小拽
- 简单高可用redis架构实践
- Redis 高可用架构最佳实践
- Redis 高可用架构最佳实践
- Redis 高可用架构最佳实践
- Redis 高可用架构最佳实践
- Redis 高可用架构最佳实践
- 构建高并发高可用的电商平台架构实践
- 数据库高可用架构(MySQL、Oracle、MongoDB、Redis)
- 构建高并发高可用的电商平台架构实践
- 构建高并发高可用的电商平台架构实践(转)
- [置顶] 构建高并发高可用的电商平台架构实践
- 构建高并发高可用的电商平台架构实践
- 构建高并发高可用的电商平台架构实践
- 构建高并发高可用的电商平台架构实践
- redis 主从同步配置以及redis+keeplived高可用架构
- 构建高并发高可用的电商平台架构实践
- 构建高并发高可用的电商平台架构实践
- 构建高并发高可用的电商平台架构实践
- 转载-- 构建高并发高可用的电商平台架构实践