Penerangan keperluan:
Platform persisian memanggil antara muka untuk menanyakan maklumat cadangan senarai lagu pengguna berdasarkan nombor telefon mudah alih Setiap pengguna akan mempunyai kira-kira seribu maklumat yang disyorkan, dan setiap maklumat yang disyorkan termasuk, 歌曲ID、歌曲名称、版权ID、试听地址字段.
Saya perlu menanyakan beberapa jadual Setiap pertanyaan mengambil masa kira-kira 4 saat Selepas pertanyaan selesai, data perlu dipasang sebelum kembali ke antara muka.
Format pemulangan ialah json. Dalam kes ini, pulangan antara muka akan menjadi lebih perlahan.
Saya terfikir untuk meletakkan data dalam kelompok redis terlebih dahulu, tetapi kemudian saya menolaknya kerana bilangan pengguna adalah kira-kira 5 juta dan saiz maklumat yang disyorkan setiap pengguna adalah kira-kira 200kb Menyimpan dalam redis akan menggunakan banyak memori, jadi saya menolaknya. Tetapi saya tidak dapat memikirkan penyelesaian lain yang baik. Bolehkah anda membantu saya mengetahui sama ada terdapat sebarang cadangan yang baik untuk menangani permintaan sedemikian? bersyukur!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Masalahnya ialah mengambil masa 4 saat untuk menanyakan banyak jadual. Jika tidak, maka 4 saat ini mesti dibelanjakan Dengan format penghantaran data lain, masa komunikasi rangkaian tidak boleh kurang daripada 4 saat tidak kira betapa dioptimumkannya.
Sama ada pelanggan menghantar permintaan pengesyoran tanpa disedari oleh pengguna atau logik pertanyaan dioptimumkan.
Untuk pertanyaan senarai terpaut, siarkan sql anda Mengapa tidak pertanyaan secara berasingan? Saya rasa anda menghabiskan banyak masa di SQ
1 Kembalikan seribu barang pada satu masa? Adakah lebih pantas untuk melakukan 50 item pada satu masa? Bagaimana pula dengan permintaan berbilang halaman?
2. Saya rasa adalah tidak wajar untuk melumpuhkan penyelesaian caching secara langsung Tidak semua pengguna dengan lebih daripada 500 W adalah pengguna aktif.
3
Tambahkan atribut ID pada [Maklumat yang Disyorkan] dan simpan dalam redis Jumlah ini tidak sepatutnya besar.
Maklumat yang disyorkan oleh setiap pengguna juga disimpan dalam redis, tetapi hanya ID 1,000 [maklumat yang disyorkan] disimpan.
Dalam kes ini, setiap maklumat yang disyorkan pengguna tidak akan menjadi 200kb.