看了一下代码，同时在线上做了观察压测。个人总结这个接口问题在于太过于依赖缓存，根本不会走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取信息
当然计算结果是要放到缓存中避免并发的。下面是部门两大明明可以靠颜值偏偏要靠才华的帅哥反馈：
不论多么小一个功能，都能有人给你评价，提意见，帮助你提高。什么样的问题都会有人和你一起探讨。这样的部门你想来么？直接留言联系我哦~~
