微博类系统我认为是互联网业务系统中最复杂和最吃性能的。简单举两个最常用的操作为例：
- pull操作分析：假设平均一个用户关注30个人，那么他的一次pull就会包含查询所有这30个人的最新若干条消息。然后拉通按照时间进行从近到远排序，选出若干条（假设15条）。然后再去查询出这15条微博的内容，再返回给该用户。这才完成一个用户的一次pull。而微博系统中pull的触发量是非常大的。一个在线用户如果在浏览时间线，那可能一分多钟就会触发一次。一百万在线光pull就会产生10万的QPS。
- post操作分析：一个大V就是几百万几千万的粉丝量。他的一次post，就会触发对这些粉丝的消息推送。其中有在线的，有不在线的。twitter对推送的要求是一个5千万粉的大V的一条消息需要在5秒内送达所有粉丝。
这个微博系统的设计和实现规格是支持百万级在线，十万级QPS。要支撑这个量级大概需要部署一百台左右的服务器（我算了一下账，发现个人私房钱有点撑不住），所有退而求其次，准备用一个缩量的配置（20台左右服务器），做一个十万在线一万QPS的性能测试。
测试环境服务器部署和规格设计：
-
frontSvr，2台(8核16G)
-
frontNotifySvr，2台(8核16G)
-
pullSvr，3台(16核32G)
-
usrMsgIdSvr，2x2台（8核16G）
-
contentSvr，2x2台（8核16G）
-
followSvr，1台（8核32G）
-
followedSvr，1台（8核32G）
-
pushSvr，1台（8核16G）
-
frontSvrMng，notifySvrMng，releationChangeSvr，msgIdGen，postSvr，共享1台 (8核16G)
-
dbSvr，1台（8核16G）
-
mongodb，4台（8核32G）
数量上，包含db一共22台服务器。配置上，也算普通不算奢华。
这个系统的测试数据设计还是花了不少心思，要保证量，还要保证比较符合真实情况，这样才能模拟出比较真实的压力环境。
测试数据生成的程序在test/performTestDataGen里。
用户关系数据设计如下：
- //用户id（10000000~19999999）一千万用户，每人10个粉丝。模拟普通用户。
- //用户id（20000000~20009999）一万用户，每人一千粉丝。
- //用户id（20010000~20007999）八千用户，每人三千粉丝
- //用户id（20018000~20019999）两千用户，每人一万粉丝
- //用户id（20020000~20020999）一千用户，每人两万粉丝
- //用户id（20021000~20021799）八百用户，每人三万粉丝
- //用户id（20021800~20019999）两百用户，每人十万粉丝
- //用户id（20022000~20022099）一百用户，每人二十万粉丝
- //用户id（20022100~20022199）一百用户，每人三十万粉丝
- //用户id（20022200~20022299）一百用户，每人四十万粉丝
- //用户id（20022300~20022302）三个用户，每人100万粉丝
- //用户id（20022303~20022305）三个用户，每人150万粉丝
- //用户id（20022306~20022308）三个用户，每人200万粉丝
- //用户id（20022309~20022309）一个用户，每人300万粉丝
总用户数10022310。总follow的关系有3亿多。粉丝会按照算法随机到所有一千万普通用户中。平均每个用户大概关注了30多个人。
发帖数设计如下：
- //普通用户0~15条微博
- //10万粉以下用户15~150条微博
- //其他用户50~300条
搞数据是个艰辛的活。唉，说多了都是泪啊
用户操作的模拟也是比较费神。
操作模拟如下：
- 所有在线用户，每人平均每10秒一次pull操作
- 每1千在线普通用户，每秒选1个用户进行一次post操作
- 测试时人工手动用功能测试工具登录大V进行post操作
性能测试整个耗费了好几天，包括做数据（数次），搭环境（数次），正式测试（数次），问题修正（若干）。期间发现了不少功能测试时没有能发现的问题。服务器+流量花费大概1千RMB左右吧（所以说一百多台的全性能测试做不起啊）。
上图是10万在线1万QPS时的状态监控截图。所有队列无阻塞，无一条异常日志输出。整个系统如丝般润滑 ：）
不过我继续加压下到1.4万QPS时，出现大量的pull超时。当时也是紧张出了一身汗。当时发现ssh终端都动不了了，突然想到是不是带宽满了。赶紧上云监控上看了下，果不其然。两台frontSvr设定的40Mbps带宽全部吃满，能不超时吗？赶紧撤下部分客户端，恢复到1万QPS。这个时候系统又恢复了美妙的安宁。
系统稳定时，查看了整个系统所有svr的负载情况，发现除了frontSvr的内存和带宽接近满负荷，frontNotifySvr内存接近满负荷外，其他svr都尚有较大余量。所以大胆推测，如果再加上两台frontSvr和两台frontNotifySvr，就这样20来台的集群配置大概支撑2万QPS是没啥问题的。不过，荷包烧的心痛就不去做了。有同学赞助的话可以再玩玩大的：）
期间我手动登录大V，发起post。在线推送基本都是一秒内客户端就收到notify。但由于登录量有限，实际在线的粉丝大概是几千级别。
如下是各svr的负载截图：
frontSvr两台，每台cpu基本吃掉3个核，内存基本耗尽，带宽占到40Mbps。整个系统配置的瓶颈就在这里。
pullSvr三台，每台吃掉6个核。还剩一半多的富裕。
userMsgIdSvr，2x2台，每台吃掉2个核。富裕较大。
contentSvr，2x2台，每台吃掉不到2个核，富裕较大。
followSvr一台，吃掉3个核，内存占用也较少。富裕较大。不过真实系统的话cache的数据会大很多，毕竟压力测试时并没有让所有用户id都登录一遍。
followedSvr一台，吃掉1个核，内存占用也较少。富裕较大。不过真实系统大V的活跃比例会较高，cache的粉丝数会很多。
pushSvr一台，吃掉1个核。不过这个不是在我用大v post的时候截图的。但根据notify收到的迅捷程度来看，大V post时压力也不过太大。
frontNotifySvr两台，吃掉1核，内存基本耗尽。这里的内存也是一个配置瓶颈，增加两台的配置整体系统负载能提高一倍。
多服务共享服务器，这上面都是业务量不大的svr，没啥压力。
dbSvr一台，没啥压力。由于大多数据已经被各svr cache了，所以db压力几乎没有。
下图是一台frontSvr的网络统计。可见外网出带宽40Mbps在高峰期完全被耗尽。
至此，这一轮性能测试算是圆满。cheers