問題描述

需求描述：

外圍平臺(tái)調(diào)用接口根據(jù)手機(jī)號查詢用戶的歌單推薦信息，每個(gè)用戶會(huì)有一千條左右的推薦信息，每條推薦信息包括了，歌曲ID、歌曲名稱、版權(quán)ID、試聽地址字段。

我需要關(guān)聯(lián)多張表查詢，每次查詢時(shí)間大概4s左右，查詢出來后還需要組裝數(shù)據(jù)，然后才返回接口。

返回格式是json。這樣的話接口返回會(huì)比較慢。

想過提前將數(shù)據(jù)放redis集群，但是后來否定了，因?yàn)橛脩袅看蟾攀?00多萬，每個(gè)用戶的推薦信息大小大概200kb,存redis的話會(huì)耗費(fèi)大量的內(nèi)存，所以否定了。但是想不到其它給好的處理方法，請各位大神幫忙看看這樣一個(gè)需求有什么好的處理建議嗎？感謝！

問題解答

瓶頸出在查詢很多張表需要4秒上，這里面的邏輯有可以優(yōu)化的點(diǎn)嗎？如果沒有那么這4秒必須花費(fèi)，其他的數(shù)據(jù)傳輸格式，網(wǎng)絡(luò)通信時(shí)間再優(yōu)化也無法小于4秒了。要么在客戶端在某個(gè)用戶無感知的情況下發(fā)推薦請求，要么優(yōu)化查詢邏輯。

你鏈表查詢，把你的sql貼出來，另外為什么不分開查詢呢？估計(jì)你耗時(shí)在SQ

1.一次返回一千條？一次50條會(huì)不會(huì)快點(diǎn)呢？多次分頁請求呢？2.覺得直接把緩存方案否了不妥，500多w的用戶，并不都是活躍用戶，估算出活躍用戶的量的redis可以接受不？3

在【推薦信息】上添加ID屬性，保存在redis，這個(gè)量應(yīng)該不會(huì)大。

每個(gè)用戶推薦的信息也存在redis上，但是只保存1000個(gè)【推薦信息】的ID。

這樣的話就不會(huì)造成每個(gè)用戶的推薦信息有200kb了。