这个视频对我来说信息量很大。
2010年11月16日的视频。
视频地址:http://video.sina.com.cn/p/tech/i/v/2010-11-16/232961185323.html
1.新浪微博的基层架构也发展了3个大的版本。
2.第一版就LAMP架构,优点是可以非常快的实现我们的系统。仅用一周时间。
抢占市场,快速开发、反馈。
3.MPSS,就是多个端口可以布置在同一服务器上,加入有三个模块,则三个模块部署在每个服务器上都有,防止单点故障。
4.微博这个产品从架构上来分析,它需要解决的是发表和订阅的问题。我们第一版采用的是推消息模式,假如说我们一个明星用户他有10万个粉丝,那就是说用户发表一条微博的时候,我们把这个微博消息存成10万份,这样就是很简单了,第一版的架构实际上就是这两行字。
5.我们把
用户分成有效和无效 之后,我们把他们做一下区分,比如说当天登陆过的人我们分成有效用户的话,只需要发送给当天登陆过的粉丝,这样压力马上就减轻了,另外投递的延迟也减小了。
6.key-value是最容易扩展的一种数据。索引数据的拆分具有挑战,比如说一个用户发表了一千条微博,这一千条微博我们接口前端要分页访问,比如说用 户需要访问第五页,那我们需要迅速定位到这个记录。假如说我们把这个索引拆分成一个月一张表,我们记录上很难判断第五页在哪张表里,我们需要加载所有的索 引表。如果这个地方不能拆分,那我们系统上就会有一个非常大的瓶颈。最后我们想了一个方法,就是索引上做了一个二次索引,
把每个月记录的偏移记下来 ,就是 一个月这个用户发表了多少条,ID是哪里,就是按照这些数据迅速把记录找出来。
7.发表是一个非常繁重的操作,它要入库、统计索引、进入后台,如果我们要把所有的索引都做完用户需要前端等待很长的时间,如果有一个环节失败的话,用户得到 的提示是发表失败,但是入库已经成功,这样会带来数据不一致问题。所以我们做了一个异步操作,就是
发表成功我们就提示成功,然后在后台的消息队列慢慢做完 。
8.第二版我们做了这些改进之后,访问量增加,有很多新的问题出现。比如说系统问题,
单点故障导致的雪崩 ,第二个是访问速度问题因为国内网络环境复杂,会有用户反映说在不同地区访问图片、js这些速度会有问题。另外一个是数据压力以及峰值,
MySql复制延迟 、慢查询,另外就是
热门事件 , 比如说世界杯。
9.我们考虑如何改进,首先系统方面
允许任意模块失败 。另外
静态内容,第一步我们用CDN来加速 ,另外数据的压力以及峰值,我们需要
将数据、功能、部署尽可能的拆分 ,然后提前进行容量规划。
10.开放平台的需求是有差异的,Web系统它有用户行为才有请求,但是API系统特别是客户端的应用,只要用户一开机就会有请求,直到他关闭电脑这种请求一直会不间断的过来,另
外用户行为很难预测。
11.
Google首席科学家讲过一句话,就是一个大的复杂的系统,应该要分解成很多小的服务 。比如说我们在Google.com执行一个搜索查询的话,实际上这个操作会调动内部一百多个服务。
12.我们第三版的考虑就是
先有服务才有接口最后才有应用 ,我们才能把这个系统做大。基础服务里面有分布式的存储,我们做了一些去中心化、自动化的操作。在基础服务之上有平台服务,我们把微博常用的应用做成各种小的服务。然后我们还有应用服务,这个是专门考虑平台各种应用的需求。最上面我们有API,API就是新浪微博各种第三方应用都在上面跑。
13.平台服务和应用服务是分开的,这样实现了
模块隔离 ,另外我们把微博的引擎进行了改进,实现了一个分层关系。用户的关注关系,我们改成一个多惟度的索引结构,性能极大的提高。
14.
基础服务DB冷热分离多维度拆分 ,在微博里面我们是按照时间拆分的,但是一个大型的系统里面有很多业务需要有不同的考虑。比如说私信这个就不能按照时间来拆分。动态内容支持多IDC同时更新,这个是在国内比较新颖的。
15.我们的模块设计上要去状态,我们任意一个单元可以支持任意节点。另外是去中心化,避免单点及瓶颈。另外是可线性扩展。最后一个是
减少模块 。
16.我们看淘宝核心系统专家余锋说过的一句话“CPU访问L1就像从书桌拿一本书,L2是从书架拿一本书,L3是从客厅桌子上拿一本书,访问主存就像骑车去社区图书馆拿一书”。
17.给大家一个很重要的经验分享,就是说监控的指标尽量量化。比如说他延迟30秒是小问题,如果是延迟10分钟我们就要立即采取措施了,就是所有可以量化的指标都要量化。
18.
尽可能的将一些运作自动化 。比如说发布安装、服务、启用、停止。
19.一款理想的分布式存储产品它有哪些需求呢?首先它要支持海量规模、可扩展、高性能、低延迟、高可用。第二个是需要多机房分布,能够满足国内负责的网络环境,还要具备异地容灾能力。第三个就是要调用简单,具备丰富数据库特性。因此分布式存储需要解决一个多对多的数据复制。
20.复制策略,
Multi-Master方案 ,它需要应用避免冲突,就是我们不能多处改变。这个对于微博来说不会特别难,我们的用户通常只会再一个地方发表微博,用户不会同时在广州又在北京发表或者是修改自己的资料,这样的话我们应用上就已经避免了这种情况。
21.我们前端应用将数据写到数据库,再通过一个消息代理,相当于通过我们自己开发的一个技术,将数据广播到多个机房。
22.高并发的长连服务器。
23.垃圾信息我们的实时拦截可以做到50%的防止,离线分析大概可以做到40%的防止。
24.离线分析:有一个日志处理器,我们会根据一些行为进行判断是否是广告和垃圾信息。
25.架构很多地方是相通的。我们需要做一
个软件系统需要解决的本质问题是什么 ?
学到了很多。