标签:新浪 架构 技术 解析
你要问我新浪微博有什么技术压力。
我觉得,本质上:
第一,如何快速共享数据,如何快速的将new message在网状社区中传递开来。
第二,长期大量积累下来的数据如何分布,分散储存,保证性能。数据库的横纵切分。
第三,机房的多备份,多备份机房之间的同步策略。
第四,业务上的实时性是不是必须,是否能够根据业务的重拍,将一部分业务异步化,减轻系统压力。
第五,高并发的请求重压之下,如何能够保证相应速度。
新浪微博首席架构师杨卫华的讲座上很好的解答了以上的这些问题。
具体参见以下资料:
http://mp.weixin.qq.com/s?__biz=MzA4NDc2MDQ1Nw==&mid=2650237833&idx=2&sn=a02e5ced24f6ea7141904324dd534627#rd
问题:[第一,如何快速共享数据,如何快速的将new message在网状社区中传递开来。]
回答:采取push的方法,有选择性的,向长期活跃的用户push new message。
手机上的app中,每个app都会和服务器建立长连接,一旦平台API中有new message,就会实时推送给app
问题:[第二,长期大量积累下来的数据如何分布,分散储存,保证性能。数据库的横纵切分。]
回答:weibo是非常有时效性的业务数据。绝大多数的数据请求都集中在最近,所以数据可以按月份横切分。同时可以在月份横切的基础上建立二级索引表。
同时,绝大多数的请求和发帖都集中在单一的省份。因此在纵切分上,在每省都建立了独立的数据中心。
问题:[第三,机房的多备份,多备份机房之间的同步策略。]
回答: 每个机房都不是单点部署,单个机房的数据更新之后,都会广播到全部的所有机房,进行快速同步。
问题:[第四,业务上的实时性是不是必须,是否能够根据业务的重拍,将一部分业务异步化,减轻系统压力。]
回答:发weibo本身这个事情,需要经过漫长的事务链条,所以我们可以打断这个链条,将其异步化,在接收到weibo以后将其推入messageQueue,然后让其异步更新处理。
问题:[第五,高并发的请求重压之下,如何能够保证相应速度。]
回答:广泛的应用缓存,cache,memcached,内存数据库,将数据放在离CPU越近的地方越好。
本文出自 “djh01” 博客,请务必保留此出处http://djh01.blog.51cto.com/10177066/1796093
标签:新浪 架构 技术 解析
原文地址:http://djh01.blog.51cto.com/10177066/1796093