java - Wie optimiere ich die Schnittstelle, um große Datenmengen zurückzugeben?
世界只因有你
世界只因有你 2017-05-17 10:00:33
0
4
927

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!

世界只因有你
世界只因有你

Antworte allen(4)
我想大声告诉你

瓶颈出在查询很多张表需要4秒上,这里面的逻辑有可以优化的点吗?如果没有那么这4秒必须花费,其他的数据传输格式,网络通信时间再优化也无法小于4秒了。
要么在客户端在某个用户无感知的情况下发推荐请求,要么优化查询逻辑。

洪涛

你链表查询,把你的sql贴出来,另外为什么不分开查询呢?估计你耗时在SQ

给我你的怀抱

1.一次返回一千条?一次50条会不会快点呢?多次分页请求呢?
2.觉得直接把缓存方案否了不妥,500多w的用户,并不都是活跃用户,估算出活跃用户的量的redis可以接受不?
3

某草草

在【推荐信息】上添加ID属性,保存在redis,这个量应该不会大。

每个用户推荐的信息也存在redis上,但是只保存1000个【推荐信息】的ID。

这样的话就不会造成每个用户的推荐信息有200kb了。

Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage