feed推荐接口优化,降低响应时间,消除抖动。
先上图
明显可以看到,抖动已经完全消除。这个接口每天有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、获取我的好友列表,选出我的好友中正在表演的人。
五、收获
缕清楚需求和现有代码,找到痛点,开动脑筋。