新浪微博:
用户拆分 数据拆分 异步处理 接口监控 多机房异地分布 实时推送 平台安全
第一版就LAMP架构,优点是可以非常快的实现我们的系统。微博这个产品从架构上来分析,它需要解决的是发表和订阅的问题。我们第一版采用的是推消息模式,假如说我们一个明星用户他有10万个粉丝,那就是说用户发表一条微博的时候,我们把这个微博消息存成10万份。
第一版的技术细节,典型的LAMP架构,是使用MyISAM搜索引擎,它的优点就是速度非常快。
另外一个是MPSS,就是多个端口可以布置在同一服务器上。为什么使用MPSS?假如说我们做一个互联网应用,这个应用里面有三个单元,我们可以由2种部署方式。我们可以把三个单元分别部署在三台服务器上,另外一种部署模式就是这三个单元部署在每个服务器上都有。我推荐第2种方法。这个方法解决了两个问题,一个是负载均衡,因为每一个单元都有多个节点处理,另外一个是可以防止单点故障。如果我们按照模式1来做的话,任何一个节点有故障就会影响我们系统服务,如果模式二的话,任何一个结点发生故障我们的整体都不会受到影响的。
技术上碰到几个问题。第一个问题是发表会出现延迟现象:明星用户他的粉丝多系统需要处理很长时间;
考虑这个系统怎么改进。首先是推模式,这肯定是延迟的首要原因,我们要把这个问题解决掉。其次我们的用户越来越多,这个数据库表从一百万到一亿,数据规模不一样处理方式是有差别的。我们第一版单库单表的模式,当用户数量增多的时候,它不能满足就需要进行拆分。第二个是锁表的问题,我们考虑的是更改引擎。另外一个是发表过慢,我们考虑的是异步模式。
第二版我们进行了模块化,我们首先做了一个分层,最底层叫基础层,首先对数据做了拆分,图上最右边是发表做了异步模式。第二个服务层,我们把微博基础的单元设计成服务层一个一个模块,最大改进是对推模式进行了改进。首先看一下投递模式的优化,首先我们要思考推模式,如果我们做一下改进把用户分成有效和无效的用户。我们一个用户比如说有一百个粉丝,我发一条微博的时候不需要推给一百个粉丝,因为可能有50个粉丝不会马上来看,这样同步推送给他们,相当于做无用功。我们把用户分成有效和无效之后,我们把他们做一下区分,比如说当天登陆过的人我们分成有效用户的话,只需要发送给当天登陆过的粉丝,这样压力马上就减轻了,另外投递的延迟也减小了。
数据的拆分,数据拆分有很多方式,很多互联网产品最常用的方法,比如说如可以按照用户的UID来拆分。但是微博用户的一个特点就是说大家访问的都是最近的数据,所以我们考虑微博的数据我们按照时间拆分,比如说一个月放一张表,这样就解决了我们不同时间的维度可以有不同的拆分方式。第二个考虑就是要把内容和索引分开存放。假如说一条微博发表的uid,微博id是索引数据,140个字的内容是内容数据。假如我们分开的话,内容就简单的变成了一种key-value的方式,key-value是最容易扩展的一种数据。索引数据的拆分具有挑战,比如说一个用户发表了一千条微博,这一千条微博我们接口前端要分页访问,比如说用户需要访问第五页,那我们需要迅速定位到这个记录。
异步处理,发表是一个非常繁重的操作,它要入库、统计索引、进入后台,如果我们要把所有的索引都做完用户需要前端等待很长的时间,如果有一个环节失败的话,用户得到的提示是发表失败,但是入库已经成功,这样会带来数据不一致问题。所以我们做了一个异步操作,就是发表成功我们就提示成功,然后在后台慢慢的消息队列慢慢的做完。
静态内容,第一步我们用CDN来加速,另外数据的压力以及峰值,我们需要将数据、功能、部署尽可能的拆分,然后提前进行容量规划。
第三版,首先我们把底层的东西分成基础服务,基础服务里面有分布式的存储,我们做了一些去中心化、自动化的操作。在基础服务之上有平台服务,我们把微博常用的应用做成各种小的服务。然后我们还有应用服务,这个是专门考虑平台各种应用的需求。
平台服务和应用服务是分开的,这样实现了模块隔离,即使应用服务访问量过大的话,平台服务不会首先影响。另外我们把微博的引擎进行了改进,实现了一个分层关系。用户的关注关系,我们改成一个多惟度的索引结构,性能极大的提高。第四个层面就是计数器的改进
分布式存储需要解决一个多对多的数据复制
做复制无非是三种策略,第一个是Master/Slave,但是它也两个缺点,第一个是Master是中心化的,如果Master在北京那广州访问就非常慢。第二个缺点是有单点风险的,比如说Master在北京,能立即迁到广州吗?这样有个时间窗口的数据就丢失了,而且需要人工的干预,而且日常广州的用户访问北京的Master是有很大延迟问题的,所以一般来说要做的非常优秀是不会考虑第一种方案的。第二种就是Multi-Master方案,它需要应用避免冲突,就是我们不能多处改变。这个对于微博来说不会特别难,我们的用户通常只会再一个地方发表微博,用户不会同时在广州又在北京发表或者是修改自己的资料,这样的话我们应用上就已经避免了这种情况。第三个就是Paxos就是可以达到强一致写,就是一条数据如果成功肯定是多个机房都成功了,这个也显而易见就是延迟性非常大。因此总结一下Multi-Master是最成熟的策略,但是它现在没有成熟的产品,因为确实没有。
前端应用将数据写到数据库,再通过一个消息代理,相当于通过我们自己开发的一个技术,将数据广播到多个机房。这个不但可以做到两个机房,而且可以做到三个、四个。具体的方式就是通过消息广播方式将数据多点分布,就是说我们的数据提交给一个代理,这个代理帮我们把这些数据同步到多个机房,那我们应用不需要关心这个数据是怎么样同步过去的。
用这种消息代理方式有什么好处呢?可以看一下Yahoo是怎么来做的?第一个是数据提供之后没有写到db之后是不会消失的,我只要把数据提交成功就可以了,不需要关心数据怎么到达机房。第二个特点YMB是一款消息代理的产品,但是它唯一神奇的地方是为广域网设计的,它可以把多机房应用归到内部,我们应用不需要关注这个问题。这个原理跟我们目前自己开发的技术相似。
推送架构怎么从架构底层做到实时性的。从左上角的一条微博在我们系统发布之后,我们把它放在一个消息队列里面,然后会有一个消息队列的处理程序把它拿过来,处理以后放到db里面。假如说我们不做持久化,因为我们推送数据也不能丢失,我们就要写一个很复杂的程序,将数据异步去存,这样就会非常复杂,而且系统也会有不稳定的因素。从另外一个角度来说,我们做持久化也是做过测试的。我们推送整个流程可以做到100毫秒和200毫秒之间,就是说我们在这个时间能把数据推送出去。
平台安全部分。由于我们的接口是完全开放的,所以我们要防范很多恶意行为,有很多人担心我们接口是开放的,是不是有人通过这个接口发垃圾广告,或者是刷粉丝,我们技术架构怎么来防范这一点呢?这是我们的安全架构,做了三个层面的事情。最上面是我们有一个实时处理,比如说根据频度、内容的相似性来进行判断,判断发的是不是广告或者是垃圾内容。中间这个是一个日志处理器,我们会根据一些行为进行判断,比如说如果我们只是实时拦截的话,有些行为很难防止,我们做了个离线纠正的模块,比如说他潜伏的几个月开始发广告了,我们可以事后把这些人清除掉,以保证我们平台的健康。最后是通过监控的维度来保证内容的安全。目前内容安全的架构大概是541的体系,就是说我们的实时拦截可以做到50%的防止,离线分析大概可以做到40%的防止。
微博平台需要为用户提供安全及良好的体验应用,以及为开发者营造一个公平的环境,所以我们的接口需要清晰安全的规则。从一个APP调用我们的接口,需要几个阶层,需要划分不同的业务模块。第二个是安全层。第三个是权限层。这是我们平台安全的两个维度,一个接口安全,一个是内容安全。
微博技术架构