新浪微博火了，对于大众而言可以在新浪微博上交流，聊话题，提及他人，聊各种“体”，疯传“元芳你怎么看”，刷粉丝，关注他人等，在如此大量的用户访问下，新浪微博随着一次一次的升级，解决了遇到的各种问题，但是对于程序员来讲，弄懂新浪微博的架构设计，一定是一件了不起的事。
如想提前了解新浪微博的架构，请浏览新浪微博架构与平台安全演讲稿。
新浪微博三次升级新浪微博在短短一年时间内从零发展到五千万用户，新浪微博的基层架构也发展了3个大的版本。
第一版就是LAMP架构，优点是可以非常快的实现新浪微博的系统。技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。新浪微博第一版采用的是推消息模式。
推送消息模式:举例说明，如今姚晨已经拥有粉丝3千万，推送的概念即是，姚晨每发一篇微博，会向他的粉丝推送一条信息，存成3千万份。很显然这样的架构以不足以支撑现在微博用户量。
第一版的技术细节，典型的LAMP架构，是使用MyISAM搜索引擎，它的优点就是速度非常快。
第一版本的不足1、发表出现延迟（明星用户发表微博，推模式带来阻塞），新浪微博的解决办法，用异步模式来处理。
2、随着用户数量的增多，单库单表的结构不能满足需求，那就用多库多表来解决这个问题。
3、出现锁表的问题，更改数据库引擎来解决
注：其实这些问题，同时是我们建站时需要考虑的，根据需求设定不同的解决方案，而不至于在用户大访问量的情况出现网站崩溃、卡死现象。
第二版本的改进第二版本新浪微博进行了模块化处理，建立基础层和服务层，而这个版本最大的亮点是对推模式的改进，产生一种新的模式——投递模式，推模式是不管用户登录还是没有登录都把信息推送给用户，如果用户100个粉丝，当天只有50个人登录，那对另外50个用户的推送就相当于做了不必要的操作。可以把用户登录时间作为一个判断点，只需要发送给当天登录的粉丝，这样服务器的压力就减少了许多。
我们再看数据的拆分，数据拆分有很多方式，很多互联网产品最常用的方法，比如说如可以按照用户的UID来拆分。但是微博用户的一个特点就是说大家访问的都是最近的数据，所以我们考虑微博的数据我们按照时间拆分，比如说一个月放一张表，这样就解决了我们不同时间的维度可以有不同的拆分方式。第二个考虑就是要把内容和索引分开存放。假如说一条微博发表的uid,微博id是索引数据，140个字的内容是内容数据。假如我们分开的话，内容就简单的变成了一种key-value的方式，key-value是最容易扩展的一种数据。索引数据的拆分具有挑战，比如说一个用户发表了一千条微博，这一千条微博我们接口前端要分页访问，比如说用户需要访问第五页，那我们需要迅速定位到这个记录。
假如说我们把这个索引拆分成一个月一张表，我们记录上很难判断第五页在哪张表里，我们需要加载所有的索引表。如果这个地方不能拆分，那我们系统上就会有一个非常大的瓶颈。最后我们想了一个方法，就是索引上做了一个二次索引，把每个月记录的偏移记下来，就是一个月这个用户发表了多少条，ID是哪里，就是按照这些数据迅速把记录找出来。
注：现在的时间线产品就出自这种设计，大致是这个样子，细节就是具体分析啦！
异步处理，发表是一个非常繁重的操作，它要入库、统计索引、进入后台，如果我们要把所有的索引都做完用户需要前端等待很长的时间，如果有一个环节失败的话，用户得到的提示是发表失败，但是入库已经成功，这样会带来数据不一致问题。所以我们做了一个异步操作，就是发表成功我们就提示成功，然后在后台慢慢的消息队列慢慢的做完。另外新浪发表了一个很重要的产品叫做MemcacheQ，我们去年做了一个对大规模部署非常有利的指令，就是statsqueue，适合大规模运维。
注：人才的聚集，总是能创造奇迹。
新浪微博第二版本的不足及问题微博的用户和访问量并没有停止，还有很多新的问题出现。比如说系统问题，单点故障导致的雪崩，第二个是访问速度问题因为国内网络环境复杂，会有用户反映说在不同地区访问图片、js这些速度会有问题。另外一个是数据压力以及峰值，MySql复制延迟、慢查询，另外就是热门事件，比如说世界杯，可能会导致用户每秒发表的内容达到几千条。我们考虑如何改进，首先系统方面允许任意模块失败。另外静态内容，第一步我们用CDN来加速，另外数据的压力以及峰值，我们需要将数据、功能、部署尽可能的拆分，然后提前进行容量规划。
新浪微博第三次改进首先新浪微博把底层的东西分成基础服务，基础服务里面有分布式的存储，做了一些去中心化、自动化的操作。在基础服务之上有平台服务，把微博常用的应用做成各种小的服务。应用服务，这个是专门考虑平台各种应用的需求。最上面我们有API，API就是新浪微博各种第三方应用都在上面跑。
平台服务和应用服务是分开的，这样实现了模块隔离，即使应用服务访问量过大的话，平台服务不会首先影响。另外把微博的引擎进行了改进，实现了一个分层关系。用户的关注关系，改成一个多惟度的索引结构，性能极大的提高。第四个层面就是计数器的改进，新版改成了基于偏移的思路，就是一个用户他原来读的一个ID比如说是10000，系统最新的ID是10002的话，我们很清楚他有两条未读。原来的版本是采用绝对计数的，这个用户有几条未读都是用一个存储结构的话，就容易产生一致性的问题，采用这种偏移的技术基本上不会出错。
另外基础服务DB冷热分离多维度拆分，在微博里面我们是按照时间拆分的，但是一个大型的系统里面有很多业务需要有不同的考虑。比如说私信这个就不能按照时间来拆分，这个按照UID来拆分可能更简单。然后我们突出存储还做了一个去中心化，就是用户上传图片的速度会极大的提高，另外察看其他用户的图片速度也会极大的提高。另外是动态内容支持多IDC同时更新，这个是在国内比较新颖的。
当然新浪微博第三个版本的改进，有些地方不是那么容易理解了，如果想继续研究的话，可以去新浪微博架构发布会看一个究竟。
写在最后
新浪微博发展至今，我们不得不说，他是一个成功的产品，值得我们业内人士的借鉴。对于我们程序员来说，更应该去借鉴这种分析问题、解决问题的方式，好的架构、好的解决方案一定是可以复用的，所以学习新浪微博的架构设计对于我们来说，是有必要的，也是必须的。
本文由PHP乐知博客提供 http://tech.42xiu.com
扫一扫
4798
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
