新浪微博宋琦：PHP在微博优化中的“大显身手”

摘要：2013中国软件开发者大会编程语言与工具专题论坛中，新浪微博架构师宋琦介绍了PHP在新浪微博中的应用，而且分享了不少微博主站所作的性能优化的工做。

【CSDN报道】 2013中国软件开发者大会（如下简称SDCC）于8月30-31日在北京新云南皇冠假日酒店举办。做为CSDN和《程序员》杂志倾力打造、千人规模以上的顶级技术盛会，今年SDCC 2013以“软件定义将来”为主题，来自于国内外一线的技术精英，就大数据分析与BI、架构实践、研发管理、IT基础设施与运维、产品与设计、开放平台等专题和参会者进行了深刻的分享和探讨。此外，32小时编程马拉松、CTO论道论坛等量身定制的特点环节也受到了参会者的强烈关注。

31日下午的编程语言与工具专题论坛上，新浪微博主站架构师宋琦与你们分享和探讨了关于PHP在新浪微博实际中的应用状况。

在进入新浪微博以前，宋琦一直在作商业产品，使用的是传统的LAMP架构。而一般商业产品不涉及到很大流量，只是业务逻辑比较复杂。宋琦说当时他关注的主要是框架、扩展性、安全性方面的话题，对性能关注的较少。“以后选择作微博，是由于我认为对于程序员来讲，微博产品所带来的技术挑战是通常产品没法比的。在大数据和大访问量下，任何东西都有可能成为很是棘手的问题。”宋琦说。

由于微博自己的一些特性，使得传统的LAMP架构，传统的框架、模板系统等在微博中变得再也不适用，须要更加深刻了解系统底层，才能应对更多挑战。

微博海量数据不容小觑

宋琦列了一组数据，微博用户数大约5.5亿，假设每一个人有100条关注关系，那么总共就有550亿条用户关系，用两个long也就是16个字节来表示一个关注关系的话，那么单独保存这些关注关系就须要800G的存储空间。“以往在db里用一个map表就解决的事，放在这个场景下就变得好笑了。”宋琦说。

那么微博的访问量有多大呢？宋琦说，在2013年除夕当晚，蛇年第一秒共发出近35000条微博，第一分钟发出近73万条微博。这个只是上行的数据量，而下行的数据量是这个的N倍还多。因而可知，这样的数据量很是惊人。

响应速度关乎用户体验

在如此大的数据量和访问量下，微博对响应速度的要求很是高。有研究数据显示，若是一个页面响应速度超过3秒，那么57%的用户就会放弃；而在登陆某网站时，若超过5秒，74%的用户就不会再登陆；亚马逊的主页响应时间每延长1秒，每一年就会减小16亿美圆的销售额；而Google搜索结果每慢0.4秒，一天搜索量将减小800万次。

“总之，这些数据都说明了响应速度的重要性，能够说响应速度是保障流畅用户体验的基础。咱们Team的主要KPI之一就是提高微博的性能。”宋琦补充道。

数据加载的优化

宋琦指出，微博有不少的配置文件，有几十个，这些配置每一次请求都要被加载，都要从新申请内存存放这些配置。而配置文件的修改是很是少的，那么可不能够只加载一次就能够一直使用呢？很遗憾PHP是作不到的，PHP脚本中所申请的资源在请求结束后全都会被释放。“因而咱们一样使用PHP扩展来解决了它，咱们建立了一个名叫Weibo_Conf的扩展，他在php-fpm启动阶段扫描指定的目录，将其下的.ini文件加载到内存中，每5分钟更新一次。这样服务器每一次接到请求时，不须要从新加载这些配置，而是直接取用，效率提高了很多。”宋琦介绍说。

除了配置外，还有一些须要常驻内存，并且不常变化的东西，可是这些的量更大一些，好比白名单/黑名单，或者切词服务的字典等。这些东西以往都是放在数据库或者MC当中，而后经过http开放接口供远程调用。“由于他们的逻辑都比较简单或者固定，不太常变化，咱们将他们独立出来作成单独的C服务，用的是yar的兄弟yar-c，yar-c所作的工做就是提供一个基于C的RPC框架，帮你完成网络和进程方面的管理，让你能够专一于实现业务逻辑，同时更方便的是，经过PHP的yar扩展能够直接调用，也就是说PHP端不管是对于基于yar-c的socket RPC服务仍是基于yar的http RPC服务，无需作出改变既能够通用。”宋琦说道。

缓存优化

众所周知，对于访问量巨大的服务来讲，缓存是必不可少的，而微博是一个重度依赖缓存的应用。宋琦指出，微博前端展示的数据所有依赖于开放平台，开放平台提供的是基于http的RESTFul的接口，响应速度通常，因此为了提速同时下降对开放平台形成的负载，微博大量的使用了MC来缓存数据。“可是用MC也不是轻轻松松就能知足咱们须要的。咱们作个计算，假设咱们每台服务器上开启128个php-fpm，总共100台服务器，若是每一个请求响应时间是1秒，从请求开始就链接MC而且等到请求结束后才自动释放，那么每一台MC上至少有上万的链接，实际微博的量比这个还要大的多，这样MC的效率就会慢下来，同时增长了PHP处理请求的耗时，又进一步加重了链接占用的状况，很容易形成雪崩效应。”宋琦指出。

 

针对此问题，宋琦展现了两种解决方案：

一种是引入一个proxy来代理对MC的访问，twitter采用的是这种方案，经过代理，php-fpm与proxy、proxy与MC之间均可以维持长链接，而且请求能够在proxy上作合并。twitter开源了他们的这个代理twemproxy。能够看到在加入twemproxy以后，MC集群的链接数大大下降了。

可是在加入了一层proxy以后，由于要经过一层twemproxy，会使得MC请求的响应变慢，因而采用了另一个方案：增长一层缓存作成多级缓存。

 

首先经过会话保持，让一个用户的每一次访问都落到固定的一台机器上，而后咱们在前端机的本地开启一个本地缓存，用它来挡在MC集群以前，下降对MC的访问。这层本地缓存的实际命中率大概在60%~70%左右，这些请求只须要从本地缓存中获取数据，就不须要走网络从MC集群上获取数据。

 

 

 

摘自：http://www.csdn.net/article/2013-09-04/2816820-sina