需求描述：
外圍平臺調(diào)用接口根據(jù)手機號查詢用戶的歌單推薦信息，每個用戶會有一千條左右的推薦信息，每條推薦信息包括了，歌曲ID、歌曲名稱、版權(quán)ID、試聽地址字段。
我需要關(guān)聯(lián)多張表查詢，每次查詢時間大概4s左右，查詢出來后還需要組裝數(shù)據(jù)，然后才返回接口。
返回格式是json。這樣的話接口返回會比較慢。
想過提前將數(shù)據(jù)放redis集群，但是后來否定了，因為用戶量大概是500多萬，每個用戶的推薦信息大小大概200kb,存redis的話會耗費大量的內(nèi)存，所以否定了。但是想不到其它給好的處理方法，請各位大神幫忙看看這樣一個需求有什么好的處理建議嗎？感謝！
5 回答
弒天下
TA貢獻1818條經(jīng)驗 獲得超8個贊
感謝各位大神的積極幫助，問題還是出自sql上，這個問題但是考慮的時候只考慮到以用戶為中心最終產(chǎn)出數(shù)據(jù)的方便性，忽略了數(shù)據(jù)中的共享性，用戶偏好的歌曲數(shù)據(jù)本身就存在大量的冗余，也就是可能大家都喜歡某一首歌曲，如果以用戶為中心存儲數(shù)據(jù)的話，可能每個用戶的數(shù)據(jù)里都包含了某一首歌曲。但是我先將歌曲信息單獨提取出來存儲，那么這個數(shù)據(jù)將精簡到幾十萬，然后再利用用戶偏好的歌曲id去關(guān)聯(lián)到歌曲信息。通過將原來的mobile——>songInfo 改為
mobile——>songId，songId——>songInfo，這樣一個關(guān)系進行解耦能達到去除冗余，提高效率的效果。
FFIVE
TA貢獻1797條經(jīng)驗 獲得超6個贊
瓶頸出在查詢很多張表需要4秒上，這里面的邏輯有可以優(yōu)化的點嗎？如果沒有那么這4秒必須花費，其他的數(shù)據(jù)傳輸格式，網(wǎng)絡(luò)通信時間再優(yōu)化也無法小于4秒了。
要么在客戶端在某個用戶無感知的情況下發(fā)推薦請求，要么優(yōu)化查詢邏輯。
慕俠2389804
TA貢獻1719條經(jīng)驗 獲得超6個贊
1.一次返回一千條？一次50條會不會快點呢？多次分頁請求呢？
2.覺得直接把緩存方案否了不妥，500多w的用戶，并不都是活躍用戶，估算出活躍用戶的量的redis可以接受不？
3
添加回答
舉報
0/150
提交
取消