Description of Requirement:
The peripheral platform calls the interface to query the user's song list recommendation information based on the mobile phone number. Each user will have about a thousand pieces of recommendation information. Each piece of recommendation information includes, Song ID, song name, copyright ID, Audition address field
.
I need to query multiple tables. Each query takes about 4 seconds. After the query is completed, the data needs to be assembled before returning to the interface.
The return format is json. In this case, the interface return will be slower.
I thought about putting the data in the redis cluster in advance, but later rejected it because the number of users is about 5 million, and the size of recommended information for each user is about 200kb. Storing redis will consume a lot of memory, so I rejected it. But I can’t think of any other good solutions. Could you please help me find out if there are any good suggestions for how to deal with such a demand? grateful!
瓶颈出在查询很多张表需要4秒上,这里面的逻辑有可以优化的点吗?如果没有那么这4秒必须花费,其他的数据传输格式,网络通信时间再优化也无法小于4秒了。
要么在客户端在某个用户无感知的情况下发推荐请求,要么优化查询逻辑。
你链表查询,把你的sql贴出来,另外为什么不分开查询呢?估计你耗时在SQ
1.一次返回一千条?一次50条会不会快点呢?多次分页请求呢?
2.觉得直接把缓存方案否了不妥,500多w的用户,并不都是活跃用户,估算出活跃用户的量的redis可以接受不?
3
在【推荐信息】上添加ID属性,保存在redis,这个量应该不会大。
每个用户推荐的信息也存在redis上,但是只保存1000个【推荐信息】的ID。
这样的话就不会造成每个用户的推荐信息有200kb了。