预告片优化方案

  看了一下代码,同时在线上做了观察压测。个人总结这个接口问题在于太过于依赖缓存,根本不会走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取信息

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

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

极致之处,精彩无限 - 优化了一半的SQL

编辑手记:RWP(Real World Performance)团队是全球最优秀的性能优化团队,他们的目标在于系统性能千倍的提升。感谢刘永甫专家的授权,他从RW...

3475
来自专栏杨建荣的学习笔记

生产环境sql语句调优实战第八篇(r3笔记第24天)

生产环境中的sql语句执行时间是很关键的性能指标,如果某个sql语句执行几个小时,优化以后几分钟,几十秒的话。会有很大的成就感,同时如果某个sql语句执行10秒...

2627
来自专栏沃趣科技

SQL优化案例-正确的使用索引(二)

下面sql 30秒执行出结果,查看sql谓词中有like,我们知道谓词中有这样的语句是不走索引的(为了保护客户的隐私,表名和部分列已经重命名)。

1116
来自专栏杨建荣的学习笔记

MySQL中的derived table(r12笔记第47天)

初始MySQL中的derived table还是在一个偶然的问题场景中。 下面的语句在执行的时候抛出了错误。 UPDATE payment_data rr ...

3335
来自专栏后端技术探索

MySQL优化的奇技淫巧之STRAIGHT_JOIN

通过「SHOW FULL PROCESSLIST」语句很容易就能查到问题SQL,如下:

751
来自专栏数据和云

性能为王:SQL标量子查询的优化案例分析

黄廷忠(网名:认真就输) 云和恩墨技术专家 个人博客:http://www.htz.pw/ 本篇整理内容是黄廷忠在“云和恩墨大讲堂”微信分享中的讲解案例,S...

3395
来自专栏程序员宝库

电商系统设计之订单

用户交易将经历一段艰辛的历程,一般用户感觉不到,实际程序是经历了一段生死离别。具体付款流程如下:

972
来自专栏杨建荣的学习笔记

百倍性能的PL/SQL优化案例(r11笔记第13天)

我相信你是被百倍性能的字样吸引了,不过我所想侧重的是优化的思路,这个比优化技巧更重要,而结果嘛,其实我不希望说成是百倍提升,“”自黑“”一下。 有一个真...

3449
来自专栏架构师之路

MySQL的or/in/union与索引优化 | 架构师之路

本文缘起自《一分钟了解索引技巧》的作业题。 假设订单业务表结构为: order(oid, date, uid, status, money, time, …) ...

36411
来自专栏数据和云

MySQL:由USE DB堵塞故障引发的思考

遇到故障,我们往往想的是如何解决这个故障,而不是从故障的根本去思考出现这个故障的原因?这样的结果,只能使我们得到了鱼,失去了渔。今天,我们就来分享一个由USE ...

2845

扫码关注云+社区