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

预告片优化方案