FWQ
吐血整理!万亿级日访问量下,Redis在微博的9年优化历程
吐血整理!万亿级日访问量下,Redis在微博的9年优化历程 0浏览 收藏 本篇文章向大家介绍《吐血整理!万亿级日访问量下,Redis在微博的9年优化历程》,主要包括MySQL、Redis、数据库,具有一定的参考价值,需要的朋友可以参考一下。 一、Redis在微博的应用场景 Redis在微博内部分布在各个应用场景,比如像现在春晚必争的“红包飞”活动,还有像粉丝数、用户数、阅读数、转评赞、评论盖楼、广告推荐、负反馈、音乐榜单等等都有用到Redis。 1、业务&规模&挑战 线上的业务有前面提到的信息流、广告、用户关系等等,还有现在大家可能比较感兴趣的热搜,用户一般会去看发生了什么事情,还有引爆阅读量的话题,以及现在兵家必争之地的视频,微博大大小小的业务都有用到Redis。 线上规模方面,微博有100T+存储,1000+台物理机,10000+Redis实例。 关于面临的挑战,我们每天有万亿级的读写,线上的响应时间要求也比较高。 举一个简单的例子,我们部署资源是跨机房部署,但是有一些业务部门连跨机房部署存在的多余两毫秒的延迟都要投诉反馈(真的是臣妾做不到啊,如果单机房故障了呢?有些业务方真是异想天开)。响应时间基本上四个9是20毫秒。 成本的话因为我们线上有大量需求是上T的,所以成本压力其实也特别大。 2、技术选型 上图是微博数据库的技术选型,其实可以看到这里面不仅仅包含Redis等NoSQL,还有队列、存储,如果以后有机会的话可以给大家分享一下从0到1搭建微博的数据库,在内部分享的时候大概花了2-3个小时,时间有限,这次就只讲Redis这一部分。 3、优化 从2010年开始,我们就基于官方的2.0版本引进Redis,到现在已经有九个年头了,我们主要做了以下这些方面的改进: Redis编码格式,在特殊场景下可以节省30%的空间; 主从库方面有独立的复制线程; 我们定制化一些数据结构,比如:LongSet 数据结构,它是一个“固定长度开放寻址的 Hash 数组”,减少Redis dict 很多额外的指针开销; 在主从复制方面,独立复制线程 +…