先上图


无标题.jpg


明显可以看到,抖动已经完全消除。这个接口每天有2000万次请求,粗算QPS = 20000000次 / 40000秒 = 500。


一、feed推荐接口中包含哪些内容

根据唱吧的业务需求,feed推荐接口主要包含三部分内容:

1、你关注的好友中正在唱歌的。

2、你关注的好友中正在直播间直播。

3、你关注的好友中正在火星直播中表演的。

4、如果以上为空的话,会推荐热门的火星主播,一月推荐一次。


二、feed推荐接口都做哪些事?

在优化之前,这块纯粹是流程化的开发方式。先获取你关注了哪些好友,然后循环这些好友,依次从唱歌/直播间/火星直播三个库中获取你的关注是否正在表演。最后,如果取到了值,就获取正在收看他表演的观众数等维度来打分排序,取得分最高的好友,获取他的用户信息,把用户信息和正在做的事情返回给客户端。


三、思考。

我们来思考一下,这样的流程中,怎样来优化,哪里有优化的空间?

1、依次去唱歌/直播间/火星直播中取数据,起码需要三次网络请求,这块是不是融合成一个大列表,而不是维护着三个列表。大列表在晚高峰也不超过1万人,所以其实还好。

2、循环好友列表,每次循环都是要做上面的第一点。

3、如果我和你都关注了同一个网红主播,你feed推荐接口的请求和我feed推荐接口的请求进来的时候,我们都要查询的他的观众人数和计算得分,这是重复的操作。

4、最后返回之前都要查一下用户信息,用户修改昵称的频率并不会很高,这块也可以优化掉。

5、部分操作可以转入后台,比如crontab,从而减轻前台的压力。



四、操作。

1、后台起一个cron,10秒一次,从三个来源中依次取出正在表演的列表。

2、分别循环三个列表中的所有表演者,计算得分,获取正在唱什么歌,获取用户头像昵称等信息。

3、三个列表融合成一个大列表,并用type字段来标志是正在唱歌/直播间/火星直播,并根据他们当前的操作来拼接文案。

4、这个大列表写入memcache。

5、请求进来的时候,从memcache中获取这个大列表,把这个列表存入本地的opcache中,这样还避免了每次都有一个memcache的网络请求。

6、获取我的好友列表,选出我的好友中正在表演的人。


五、收获

缕清楚需求和现有代码,找到痛点,开动脑筋。

标签: PHP, Memcache, 优化

仅有一条评论

  1. a

    有意思

添加新评论