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、歌曲名稱、版權ID、試聽地址字段.
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
0
0
瓶頸出在查詢很多張表需要4秒上，這里面的邏輯有可以優(yōu)化的點嗎？如果沒有那么這4秒必須花費，其他的數據傳輸格式，網絡通信時間再優(yōu)化也無法小于4秒了。
要么在客戶端在某個用戶無感知的情況下發(fā)推薦請求，要么優(yōu)化查詢邏輯。
1.一次返回一千條？一次50條會不會快點呢？多次分頁請求呢？
2.覺得直接把緩存方案否了不妥，500多w的用戶，并不都是活躍用戶，估算出活躍用戶的量的redis可以接受不？
3
在【推薦信息】上添加ID屬性，保存在redis，這個量應該不會大。
每個用戶推薦的信息也存在redis上，但是只保存1000個【推薦信息】的ID。
這樣的話就不會造成每個用戶的推薦信息有200kb了。
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
