Anforderungsbeschreibung:
Die Peripherieplattform ruft die Schnittstelle auf, um die Songlisten-Empfehlungsinformationen des Benutzers basierend auf der Mobiltelefonnummer abzufragen. Jeder Benutzer verfügt über etwa tausend empfohlene Informationen, und jede empfohlene Information umfasst: 歌曲ID、歌曲名稱、版權(quán)ID、試聽(tīng)地址字段
.
Ich muss mehrere Tabellen abfragen. Jede Abfrage dauert etwa 4 Sekunden. Nachdem die Abfrage abgeschlossen ist, müssen die Daten zusammengestellt werden, bevor sie zur Schnittstelle zurückkehren.
Das Rückgabeformat ist JSON. In diesem Fall ist die Schnittstellenrückgabe langsamer.
Ich habe im Voraus darüber nachgedacht, die Daten im Redis-Cluster abzulegen, aber sp?ter habe ich es abgelehnt, da die Anzahl der Benutzer etwa 5 Millionen betr?gt und die empfohlene Informationsgr??e für jeden Benutzer etwa 200 KB betr?gt. Das Speichern in Redis würde viel Speicher verbrauchen. also habe ich es abgelehnt. Aber mir fallen keine anderen guten L?sungen ein. K?nnten Sie mir bitte helfen, herauszufinden, ob es gute Vorschl?ge gibt, wie man mit einer solchen Nachfrage umgehen kann? dankbar!
瓶頸出在查詢很多張表需要4秒上,這里面的邏輯有可以優(yōu)化的點(diǎn)嗎?如果沒(méi)有那么這4秒必須花費(fèi),其他的數(shù)據(jù)傳輸格式,網(wǎng)絡(luò)通信時(shí)間再優(yōu)化也無(wú)法小于4秒了。
要么在客戶端在某個(gè)用戶無(wú)感知的情況下發(fā)推薦請(qǐng)求,要么優(yōu)化查詢邏輯。
1.一次返回一千條?一次50條會(huì)不會(huì)快點(diǎn)呢?多次分頁(yè)請(qǐng)求呢?
2.覺(jué)得直接把緩存方案否了不妥,500多w的用戶,并不都是活躍用戶,估算出活躍用戶的量的redis可以接受不?
3
在【推薦信息】上添加ID屬性,保存在redis,這個(gè)量應(yīng)該不會(huì)大。
每個(gè)用戶推薦的信息也存在redis上,但是只保存1000個(gè)【推薦信息】的ID。
這樣的話就不會(huì)造成每個(gè)用戶的推薦信息有200kb了。