Cara menggunakan Redis untuk fungsi caching inventori berjadual

1. Latar belakang perniagaan

Saya memutuskan untuk membandingkan soalan ini dengan soalan pada kertas peperiksaan untuk mengelak daripada memperkenalkan latar belakang projek syarikat kami. Mengenai butiran perniagaan, anda tidak perlu memberi perhatian kepadanya ~ lihat sahaja tajuk:

Katakan anda adalah pengumpul terbaik di negara tertentu, dan anda mempunyai pelbagai khazanah yang bernilai berturut-turut. di tangan anda. Suatu hari anda mungkin merasakan koleksi anda semakin membosankan dan memutuskan untuk menjual barangan berharga ini secara tunai.

Tetapi adalah terlalu rendah untuk menjual khazanah berharga ini di pasaran sayur-sayuran. Dalam era "Internet +", sudah tentu kita perlu menggunakan beberapa kaedah jualan yang berbeza: terdapat bangunan 300 bilik (bernombor 001 hingga 300) dalam nama anda, dan terdapat peti keselamatan berkunci kata laluan di setiap bilik (dari 1 Disember hingga 31 Disember), anda akan memilih 300 daripada "khazanah teratas" terbaik (juga dipanggil khazanah Kelas A) dan meletakkannya di dalam peti besi 300 bilik ini . Sesiapa yang ingin membeli harta karun mesti membuat tempahan dalam talian sekurang-kurangnya sehari lebih awal, dan kemudian menggunakan kod tempahan untuk membuka peti besi dan mengambil barang. Harta karun yang tidak disimpan akan diambil semula oleh anda dan tidak akan dijual lagi.

Untuk membina sistem tempahan dalam talian sedemikian, antara muka bahagian hadapannya mungkin kelihatan seperti ini:

Klik pada tiga kawalan untuk diisi dalam gambar di atas Kotak pilihan akan muncul. Masalahnya sekarang ialah hanya ada satu harta di dalam bilik dan ia tidak boleh ditempah dua kali. Selepas pembeli memilih jenis harta karun dan nombor bilik, adalah disyorkan untuk memberikan beberapa maklumat segera dalam kotak pemilihan tarikh apabila mereka memilih tarikh tempahan. Sebagai contoh, bilik No. 051 telah ditempah pada 3 Disember, dan kini pengguna lain telah memilih bilik No. 051. Kemudian apabila kotak pemilihan tarikh muncul, 3 Disember mesti ditetapkan sebagai tidak boleh dipilih. Seperti yang ditunjukkan di bawah (3hb Disember dipaparkan sebagai "hilang"):

Jadi, bagaimanakah sistem inventori mudah seperti ini boleh disimpan dalam redis?

2. Penyelesaian pengurusan inventori (Redis)

Idea awal kami ialah inventori kami boleh dilihat sebagai tatasusunan tiga dimensi yang besar, di mana dimensi pertama mewakili jenis harta, dan yang kedua Dimensi pertama mewakili nombor bilik, dan dimensi ketiga mewakili tarikh tempahan. Redis menyediakan lima jenis storan: String, Hash, Senarai, Set dan Set Isih. Kami boleh menggunakan jenis Hash untuk menyimpan data dalam senario semasa kerana ia boleh memenuhi keperluan kami, dan jenis Set juga merupakan pilihan yang boleh dilaksanakan.

Kunci Redis ditetapkan kepada jenis harta + nombor bilik (contohnya, A:205, A mewakili harta terbaik, 205 ialah nombor bilik), nilai Redis ialah jenis cincang dan kunci cincang ialah tarikh (contohnya, 2016-12- 05), nilai cincang adalah benar atau salah, menunjukkan bahawa ia telah ditempah atau tidak. Diwakili dalam rajah sebagai:

Jika Bilik 158, Harta Kelas A, telah ditempah pada 8 Disember, ia akan disimpan sebagai

1 2 3

Redis Key —— A:158   Redis Value —— hash table ['2016-12-08' => 1]

123

Redis Key —&mdash ; A: 158 Nilai Semula —— <code> => 1

3. Senario Lanjutan & Penyelesaian Pengurusan Inventori

Pelancaran khazanah teratas Kelas A telah dialu-alukan, dan sejumlah besar pesanan telah dibuat tidak lama selepas pelancarannya. Ramai orang kelas pertengahan berminat untuk mengumpul, tetapi harga yang tinggi sering melambatkan mereka. Jadi, anda memilih khazanah Kategori B daripada koleksi anda Ia lebih rendah sedikit daripada khazanah Kategori A, tetapi harganya lebih berpatutan, dan ia juga dipanggil "harta karun yang sangat baik".

Memandangkan terdapat lebih banyak harta dalam jenis B daripada jenis A, anda bercadang untuk menukar cara bermain Dalam 300 bilik ini, letakkan peti besi di setiap bilik harta karun ke dalam setiap 300 kotak bilik. Selepas pembeli membuat tempahan, dia akan mengambil harta karun mengikut waktu yang dijadualkan. Untuk khazanah Kategori B, sistem tempahan anda akan mempunyai pilihan tambahan, iaitu masa pengambilan. Seperti yang ditunjukkan di bawah:

Sekarang terdapat syarat tambahan yang telah ditetapkan (masa pengambilan), apabila melakukan penyimpanan inventori, fikirkannya secara kasar sebenarnya tatasusunan empat dimensi. Ayat ini boleh ditulis semula sebagai: Maklumat empat dimensi termasuk jenis harta karun, nombor bilik, tarikh tempahan dan masa pengambilan. Bagaimana untuk menyimpan harta jenis ini di Redis?

Malah, jika anda memikirkannya dengan teliti, apabila menyimpan khazanah kelas A yang berkualiti tinggi, storan kami dalam Redis adalah satu pembaziran dimensi

Malah, hanya satu storan hashValue digunakan pada masa itu Status yang telah ditetapkan tercapai, menyebabkan maklumat dalam dimensi ini menjadi sia-sia. Memandangkan masa pengambilan semuanya mengikut jam iaitu 0 hingga 1, 1 hingga 2,..., 23 hingga 24, sebanyak 24 situasi sepanjang hari, jadi kita boleh menggunakan integer binari sepenuhnya untuk mewakili masa item simpanan. Contohnya, 1 bermakna 0 hingga 1 mata, 2 bermakna 1 hingga 2 mata, 4 bermakna 2 hingga 3 mata,...,

23 hingga 24 mata boleh diwakili oleh 2 hingga kuasa ke-23 (8388608) . Untuk menempah beberapa tempoh masa, anda hanya perlu melakukan operasi OR logik pada nilai.

Dengan cara ini, struktur Redis kami menjadi seperti ini:

Contohnya, Bilik 103 harta karun Kelas B, pagi 5 dan 6 Disember Ditempah dari 8:00 hingga 12:00, disimpan dalam redis sebagai

1 2 3

Redis Key  —— B:103   Redis Value —— hash table ['2016-12-05' => 3840, '2016-12-06' => 3840]

12 3

Kunci Redis —— B:103 Nilai Redis —&mdash ; jadual cincang ['2016-12-05' => >=> 3840]

Untuk khazanah Kelas B, apabila membuat tempahan baharu, anda perlu mengeluarkan nilai cincang asal terlebih dahulu, melakukan operasi ATAU logik dengan masa pengambilan yang dijadualkan baharu, dan kemudian tulis hasilnya semula kepada Redis, bukannya melakukan perkara yang sama perkara seperti khazanah Kelas A, hSet dipanggil terus untuk menetapkan nilai cincangan apabila membatalkan tempahan, berhati-hati untuk mengeluarkan nilai cincang asal dahulu, tolak tempoh masa untuk dibatalkan daripada nilai cincang (XOR + logik DAN operasi; ), dan kemudian semula- Baki masa pengambilan yang ditempah ditulis kembali kepada Redis, dan hDel tidak boleh dipanggil terus untuk memadam.

4. Pelan Pengurusan Lanjutan & Inventori

Sejak pelancaran khazanah Kelas B, perniagaan anda telah menjadi lebih popular berbanding sebelum ini. Jadi permintaan baru datang lagi Sekarang terdapat sejumlah besar pelancong, pelajar dan orang lain tanpa simpanan yang besar yang sangat berminat dengan khazanah anda. Walaupun harga khazanah jenis B lebih rendah sedikit daripada jenis A, ia masih agak mahal untuk mereka ini. Jadi, anda memutuskan untuk menjual khazanah anda yang paling berpatutan (khazanah Kategori C).

Di antara 300 bilik ini, khazanah Jenis C menyimpan jumlah terbesar, jadi anda menambah 100 peti harta karun khusus untuk menyimpan khazanah Jenis C di setiap bilik. 100 kotak harta karun ini bernombor No 1, No 2,..., No 100. Begitu juga, setiap jam dalam sehari, anda akan meletakkan khazanah jenis C ke dalam 100 kotak harta karun dalam setiap 300 bilik ini (yang bermaksud bahawa keseluruhan bangunan akan mengemas kini 30,000 khazanah jenis C setiap jam). Jika tiada sesiapa yang membuat tempahan, harta itu akan diganti pada jam berikutnya. Akhirnya, keperluan setiap orang dapat dipenuhi.

Untuk khazanah jenis C, antara muka tempahan anda akan kelihatan seperti ini:

Kami telah menambah satu lagi syarat tempahan. Pada masa ini, kita berhadapan dengan masalah penyimpanan inventori. Seperti biasa, inventori ini sebenarnya adalah tatasusunan lima dimensi yang besar. Jenis harta karun, nombor bilik, tarikh tempahan, masa pengambilan dan nombor kotak harta karun masing-masing menduduki satu dimensi. Kami telah menggunakan semua kapasiti Redis sebelum ini. Apakah yang perlu kami lakukan sekarang untuk menyimpan data?

Kali ini storan inventori Redis mesti digabungkan dengan ciri perniagaan. Pertama sekali, dua dimensi nombor peti harta karun dan masa pengambilan tidak mempunyai julat nilai yang terlalu banyak. Hanya terdapat 100 nombor peti harta karun sahaja kepada tatasusunan dengan panjang 100, dan setiap kedudukan tatasusunan mengandungi INT Masa pengambilan yang ditunjukkan oleh jenis sudah mencukupi. Walau bagaimanapun, nilai cincang hanya boleh menjadi rentetan... Jadi, kita perlu melakukan operasi bersiri tatasusunan, dan kemudian menyahsirikannya semula apabila membaca. Nasib baik, panjangnya hanya 100, jadi kecekapan bersiri tidak akan menjadi hambatan sistem.

Kaedah penyimpanan ialah: pada 23 dan 24 Disember, antara khazanah jenis C di Bilik 258, peti harta karun bernombor 97 dan 99 telah ditempah antara 11 pagi dan 1 petang

1 2 3

Redis Key —— C:258   Redis Value —— hash table ['2016-12-23' => '[97 => 6144, 99 => 6144]', '2016-12-24' => '[97 => 6144, 99 => 6144]' ]

123 Redis Key &mdash ;— C:258 Nilai Semula —— kod> <kod>=> </kod><kod>'[97 => 24'</kod> => '[97 => 6144, 99 => 6144]' ]

Antaranya, 6144 dinyatakan dalam binari sebagai "110000000000", dan nilai cincang ialah rentetan selepas siri tatasusunan Format json boleh digunakan dalam projek sebenar. Okay, kini Redis mempunyai storan untuk tiga jenis khazanah.

Untuk khazanah Kategori C, apabila pengguna membatalkan tempahan atau menambah tempahan baharu, anda juga tidak boleh memanggil hSet dan hDel untuk menulis ganti tetapan dan memadam situasi yang telah dikhaskan mesti dikeluarkan , dan lakukan operasi bitwise dengan masa pengambilan yang dijadualkan.

5. Pengoptimuman Storan

Secara teori, inventori ialah tatasusunan berbilang dimensi Tugas utama yang kami lakukan ialah cara menyimpan setiap dimensi secara munasabah dan memudahkan untuk menambah, memadam dan membuat pertanyaan. beroperasi. Dari perspektif penjimatan ingatan, apabila tiada siapa yang membuat tempahan pada mulanya, Redis boleh menjadi kosong sepenuhnya Untuk khazanah Kelas A, nilai cincang adalah sama dengan palsu dan tiada kunci redis atau kunci cincang yang sepadan sama sekali, dsb. Berkesan.

Selain itu, menggabungkan jenis harta karun dan nombor bilik untuk membuat kunci redis akan menghasilkan bilangan kunci yang lebih besar yang berkaitan dengan inventori harta dalam redis Untuk memudahkan pengurusan bersatu kunci ini, kami boleh tambah satu lagi cache redis Ia digunakan khas untuk menyimpan semua nilai kunci redis yang berkaitan dengan inventori harta, seperti yang ditunjukkan dalam rajah di bawah. Perlu diingatkan bahawa dalam kes ini, menggunakan jenis data yang ditetapkan boleh memenuhi keperluan, bukannya menggunakan jenis data hash, kerana kerumitan penambahan, pemadaman, pengubahsuaian dan pertanyaan jenis data yang ditetapkan ialah O(1). Ia menyimpan semua nilai kunci inventori yang sudah wujud dalam redis.

Satu kelebihan melakukan ini ialah jika kami menghadapi beberapa keadaan istimewa suatu hari nanti dan perlu mengosongkan semua cache berkaitan inventori, kami boleh mengalih keluar semua kunci Inventori dan memadamkannya dengan mudah . Manfaat lain ialah ia memberikan kita idea untuk pengembangan berterusan... Bayangkan situasi paling rumit sekarang ialah khazanah jenis C, dengan jumlah 5 dimensi. Katakan pada masa hadapan, anda tidak lagi menggunakan 300 bilik dalam satu bangunan untuk menjual khazanah, tetapi berbilang bangunan, maka pengguna perlu menambah dimensi lain apabila membuat pesanan - nombor bangunan. Apabila menghadapi situasi ini, kami boleh mengurangkan sepenuhnya set Kunci inventori tambahan untuk membina nombor untuk digunakan, memastikan kebolehskalaan dalam situasi yang lebih kompleks yang mungkin timbul.

Selepas pengembangan ini, setiap kali anda menambah rekod tempahan baharu, anda perlu menyemak sama ada nilai kunci redis yang sepadan sudah wujud dalam set kunci inventori Jika ia tidak wujud, anda perlu menambah kunci redis nilai kepada set tengah inventori. Operasi pemadaman adalah serupa.

Atas ialah kandungan terperinci Cara menggunakan Redis untuk fungsi caching inventori berjadual. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!