首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >预告片优化方案

预告片优化方案

作者头像
静儿
发布2018-07-02 15:22:14
5140
发布2018-07-02 15:22:14
举报
文章被收录于专栏:编程一生编程一生

  看了一下代码,同时在线上做了观察压测。个人总结这个接口问题在于太过于依赖缓存,根本不会走DB。依赖缓存造成了依赖缓存的数据结构。首先要从缓存中取出一堆数据。而且要走两次,一次取正片的信息,一次取专辑内所有视频的信息。取出来的信息在CPU里计算筛选,排序。本身缓存取数据就比较快,再加上计算量大。其实我们并发量最大的api接口们都是采用这个模式设计的。调用的多了,我觉得我真是压测的狠的话,会造成CPU密集。其实现在的缓存之类的都可以持久化了,完全可以当数据库用。但是关系型数据作为一个长久的经典还有一个很重要的原因:保持一个IO和CPU使用的平衡。

  根据走索引每次穿透db按现在量也问题不大,mget本身key过多,性能下降快,导致其他服务处于等待超时。这个目前的问题和方针,将原有计算逻辑化简为几个简单的SQL:

1. 中文站点,中文语言:

SELECT * FROM con_video_info WHERE pid=专辑ID AND PLAY_PLATFORM LIKE '%,平台ID,%' AND PORDER>(SELECT PORDER FROM con_video_info WHERE ID=视频ID) ORDER BY PORDER LIMIT 5;

2. 中文站点,其他语言:

1>SELECT ID FROM con_video_info WHERE pid=专辑ID AND PLAY_PLATFORM LIKE '%,平台ID,%' AND PORDER>(SELECT PORDER FROM con_video_info WHERE ID=视频ID) ORDER BY PORDER LIMIT 5; 2>从缓存按ID取信息

3. 其他站点,中文语言:

1> SELECT * FROM con_video_info as v INNER JOIN con_video_site_info as s ON v.ID=s.vid WHERE v.pid=专辑ID AND s.PLAY_PLATFORM LIKE '%,平台ID,%' AND v.PORDER>(SELECT PORDER FROM con_video_info WHERE ID=视频ID) ORDER BY v.PORDER LIMIT 5;

4. 其他站点,其他语言:

1> SELECT ID FROM con_video_info as v INNER JOIN con_video_site_info as s ON v.ID=s.vid WHERE v.pid=专辑ID AND s.PLAY_PLATFORM LIKE '%,平台ID,%' AND v.PORDER>(SELECT PORDER FROM con_video_info WHERE ID=视频ID) ORDER BY v.PORDER LIMIT 5;

2>从缓存按ID取信息

  当然计算结果是要放到缓存中避免并发的。下面是部门两大明明可以靠颜值偏偏要靠才华的帅哥反馈:

 不论多么小一个功能,都能有人给你评价,提意见,帮助你提高。什么样的问题都会有人和你一起探讨。这样的部门你想来么?直接留言联系我哦~~

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2017-03-23 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档