系统架构师大会-新浪微博redis优化历程

redis优化历程@fishermen大纲架构演进业务场景Redis一些经验Q&A2业务场景-业务Redis在的应用计数(counter)关系(graph)通知提醒3业务场景-数据一些数据6

IDC500+servers3700+

instances千亿条记录24T+内存7千亿cmds/day1.2万亿read/day2千亿write/day4Redis前时代5Redis前时代热数据mc全量

mysql数据量不大：Graph

mc

10G，计数器

mc

2G开发速度6问题出现2010年，Graph

mc

30G+，峰值10wTPSMysql成为瓶颈线程阻塞，

卡顿List类型业务不适合mysql新的关系计算需求实现大量关系计算：从MC取全量+本地计算->超时7解决方案初期方案增大mc容量到40G，Graphdb增至一主六从并及时清理僵死线程关系计算性能问题暂时无解最终方案引入Redis做storage

(graph/counter)关系计算在redis实现O(1)促进 复杂需求Graph

db恢复一主三从8小结项目初期30G-日PV5kw-技术选型熟悉度拼的是开发速度产品需求与新技术相互促进9Redis初期10Redis初期Redis

2.0Graph存hash，40G

10wTPS，4

ServerCounter:20G

2w

TPS，2Server11问题出现2011年，初期使用经验不足数据分片过少，扩容部分数据类型使用不当，内存超预期多业务混放，拆分不便可用性不够小业务初期没有slave，server故障→服务异常大业务挂载3-4个slave， 期write超时，请求失败重启耗时，10-20分钟服务异常12解决方案容量规划提前预估容量，上线前预拆足够的数据分片选择合适的数据类型，慎用zset业务独立

， 混放13解决方案提高可用性所有Redis全部增加SlaveMaster挂载slave不超过2个，采用M-S-S方式挂载多IDC

单Master，

同步凌晨低峰升级，

IP→不完美，但基本可work14问题升级2011年底，Graph

100G+灵异事件凌晨3点低峰期，redis无征兆批量升级、扩容拆分， 其他业务异常多个slave严重负载不均，请求数最大差1-2个数量级，峰值响应从不足1ms->3ms版本增多最多6个版本BUG重复修复，运维15问题分析：读写会用pageCache，导致redis进：

全量推送导致网络阻swap而其他服务塞负载不均：client通过，解析返回随机ip，结果连接不均衡，最终导致负载不均衡16问题解决紧急方案超过物理内存3/5→迁移端口错峰升级/扩容对网络仍然有一定冲击开发ClientBalancer组件，保持

下IP连接均衡，负载均衡进一步优化方案：（社区版psync,及时清理pagecache，减少对正常业务影响Aof去掉rewrite，改用rotate类似mysql，独立IO线程对rdb、aof转发repl-backlog-size,

repl-backlog-ttl）支持热升级，避免重启，提高可运维性Others…17小结1-2个集群小规模

50G–

运维中规模100G+，3+集群可运维性->重要开源组件->熟悉架构实现18Redis爆发期19Redis爆发期完全增量热升级SLAVE均衡大量子业务切入单业务数百G稳定20问题出现2013年，Graph海量规模数据T级，MS十T级数百台server，而且还在快速增加Graph用Hash结构， 效率不高21问题出现–

效率低<30%Counter业务增加，增长迅猛日增：计数亿条内存5G+总数据百G级，

MS T级Feed请求

计数近百倍读放大，

超时2013000001.rep8002013000001.cmt3602013000001.like10002013000001.read100002223问题出现占用机器增加迅猛，成本合理性需要考虑部分机房机架饱和解决方案Graph定位：storage→cache定制：hash→LongsetCounter定制cdb，通过table分段存储计数一个KV存多个计数2013000001.rep8002013000001.cmt3602013000001.like10002013000001.read100002013000001800|360|1000|1000024解决方案，Counter

结构cdb=schema+tables计数double-hash寻址结消除冗余robj构–

过多aux_dict–

数值过大extend_dict多管齐下，节省数百台机器下线低配server，寻找廉价新机房ta

b

le2682643795ta

b

le3752ta

b

le1502590a

ux

d

icte

xte

nd

d

ictsc

he

ma25小结量变->质变，业务定制大规模集群

T级3+idc成本单个请求成本总拥有成本26Redis高速稳定期27Redis高速稳定期Graph定位cache定制longset内存降为1/10性能接近Counter定制cdb内存降为1/5-性能增3-5倍28Redis高速稳定期继续定制CounterVectorOthers…SSD，容量提升20倍，8个月→10年2930问题出现2014，SLA目标6个96+IDC

跨地域分布数千关联Server海量数据24T+峰值5000w+TPS，响应毫秒级硬件/网络故障时有发生，如何实现？问题解决资源服务化

→Configserver用于服务的发布与订阅CacheService用于集群管理数据路由负载均衡数据

迁移服务治理（生命周期故障转移etc.）运维标准化、自动化（扩/缩容etc.）31服务化32服务化服务化

→业务服务化motan

✓资源服务化→c

a

c

he

Se

rvicemysq

lhb

a

sehb

a

seinvo

ke

rm

crrred

isc

o

n

figse

rve

rm

crrred

isc