新浪微博技术架构.docx

新浪微博技术架构首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。第一版就是是非常快的，我们能够非常快的实现我们的模块。我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。我们第一版采用的是推的消息形式，假设讲我们一个明星用户他有10万个粉丝，那就是讲用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。第一颁的技术细节，典型的LAMP架构，是使用Myisam搜索引擎，它的优点就是速度非常快。另外一个是MPSS，就是多个端口能够布置在服务器上。为何使用MPSS？假设讲我们做一个互联网应用，这个应用里面有三个单元，我们能够由三种部署方式。我们能够把三个单元部署在三台服务器上，另外一种部署形式就是这三个单元部署在每个服务器上都有。这个解决了两个问题，一个是负载平衡，由于每一个单元都有多个结点处理，另外一个是能够防止单点故障。假如我们根据形式一来做的话，任何一个结点有故障就会影响我们系统服务，假如形式二的话，任何一个结点发生故障我们的整体都不会遭到影响的。我们微博第一版上线之后，用户非常喜欢这个产品，用户数增长非常迅速。我们技术上碰到几个问题。第一个问题是发表会出现延迟现象，尤其是明星用户他的粉丝多。另外系统处理明星用户发表时候的延迟，可能会影响到其他的用户，由于其他的用户同一时间发表的话，也会遭到这个系统的影响。我们就考虑这个系统怎么改良。首先是推形式，这肯定是延迟的首要原因，我们要把这个问题解决掉。其次我们的用户越来越多，这个数据库表从一百万到一亿，数据规模不一样处理方式是有差异的。我们第一版单库单表的形式，当用户数量增加的时候，它不能知足就需要进行拆分。第二个是锁表的问题，我们考虑的是更改引擎。另外一个是发表过慢，我们考虑的是异步形式。第二版我们进行了模块化，我们首先做了一个层，做了拆分，最右边的发表做了异步形式。第二个服务层，我们把微博基础的单元设计成服务层一个一个模块，最大是对推形式进行了改良。首先看一下投递形式的优化，首先我们要考虑推形式，假如我们做一下改良把用户分成有效和无效的用户。我们一个用户比方讲有一百个粉丝，我发一条微博的时候不需要推给一百个粉丝，由于可能有50个粉丝不会马上来看，这样同步推送给他们，相当于做无用功。我们把用户分成有效和无效之后，我们把他们做一下区分，比方讲当天登陆过的人我们分成有效用户的话，只需要发送给当天登陆过的粉丝，这样压力马上就减轻了，另外投递的延迟也减小了。我们再看数据的拆分，数据拆分有很多方式，很多互联网产品最常用的方法，比方讲如能够根据用户的UID来拆分。但是微博用户的一个特点就是讲大家访问的都是近期的服务器，所以我们考虑微博的数据我们根据时间拆分，比方讲一个月发一张表，这样就解决了我们不同时间的惟度能够有不同的拆分方式。第二个考虑就是要把内容和索引分开存放。假设讲一条微博发表的地址是索引数据，内容是内容数据。假设讲我们分开的话，内容就简单的变成了一种key-value的方式，key-value是最容易扩展的一种数据。比方讲一个用户发表了一千条微博，这一千条微博我们接口前端要分页放，比方讲用户需要访问第五页，那我们需要迅速定位到这个记录。假设讲我们把这个索引拆分成一个月一张表，我们记录上很难判定第五页在哪张表里，我们需要索引所有的表。假如这个地方不能拆分，那我们系统上就会有一个非常大的瓶颈。最后我们想了一个方法，就是讲索引上做了一个二次索引，改变我们还是根据时间拆分，但是我们把每个月记录的偏移记下来，就是一个月这个用户发表了多少条，ID是哪里，就是根据这些数据迅速把记录找出来。异步处理，发表是一个非常繁重的操作，它要入库、统计索引、进入后台，假如我们要把所有的索引都做完用户需要前端等待很长的时间，假如有一个环节失败的话，用户得到的提示是发表失败，但是入库已经成功。所以我们做了一个异步操作，就是发表成功我们就提示成功，然后我们在后台渐渐的消息队列渐渐的做完。另外新浪发表了一个很重要的产品叫做MemcacheQ，我们去年做了一个对大规模部署非常有利的指令，就是statsqueue，合适大规模运维。第二版我们做了这些改良之后，微博的用户和访问量并没有停止，还有很多新的问题出现。比方讲系统问题，单点故障导致的雪崩，第二个是访问速度问题由于国内网络环境复杂，会有用户反映讲在不同地区访问图片、js这些速度会有问题。另外一个是数据压力以及峰值，MySql复制延迟、慢查询，另外就是热门事件，比方讲世界杯，可能会导致用户每秒发表的内容到达几百条。我们考虑怎样改良，首先系统方面循序任意模块失败。另外静态内容，第一步我们用CDN来加速，另外数据的压力以及峰值，我们需要将数据、功能、部署尽可能的拆分，然后提早进行容量规划。另一方面我们还有平台化的需求，去年11月我们就讲要做开放平台，开放平台的需求是有差异的，Web系统它有用户行为才有请求，但是API系统十分是客户端的应用，只要用户一开机就会有请求，直到他关闭电脑这种请求一直会不间断的过来，另外用户行为很难预测。系统规模在持续的增大，另外也有平台化的需求，我们新架构应该怎么做才能知足这些需要？我们看一下同行，比方讲Google如何考虑这个问题的？Google首席科学家讲过一句话，就是一个大的复杂的系统，应该要分解成很多小的服务。比方讲我们在文档视界2022/0d4b51afdd3383c4bb4cd22e4dgfwcw3wnm.html执行一个搜索查询的话，实际上这个操作会调动内部一百多个服务。因而，我们第三版的考虑就是先有服务才有接口最后才有应用，我们才能把这个系统做大。此页面能否是列表页或首页？未找到适宜正文内容。