看了一下程式碼，同時線上上做了觀察壓測。個人總結這個介面問題在於太過於依賴快取，根本不會走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取資訊
當然計算結果是要放到快取中避免併發的。下面是部門兩大明明可以靠顏值偏偏要靠才華的帥哥反饋：
不論多麼小一個功能，都能有人給你評價，提意見，幫助你提高。什麼樣的問題都會有人和你一起探討。這樣的部門你想來麼？直接留言聯絡我哦~~