Rumah >pangkalan data >Redis >Mari kita bincangkan secara ringkas tentang dua penyelesaian untuk Redis mengendalikan mati pucuk antara muka.
Pembelajaran yang disyorkan: Tutorial video Redis
Kata Pengantar: 接口幂等性
Masalah, bagi pembangun, adalah isu awam yang tidak berkaitan bahasa. Untuk sesetengah permintaan pengguna, mereka mungkin dihantar berulang kali dalam beberapa kes Jika ia adalah operasi pertanyaan, ia bukan masalah besar, tetapi sesetengah daripadanya melibatkan operasi tulis Setelah berulang, ia mungkin membawa kepada akibat yang serius, seperti transaksi . Jika antara muka diminta berulang kali, pesanan berulang mungkin dibuat. Idepotensi antara muka bermakna bahawa keputusan satu permintaan atau berbilang permintaan yang dimulakan oleh pengguna untuk operasi yang sama adalah konsisten dan tidak akan ada kesan sampingan yang disebabkan oleh berbilang klik.
Dalam HTTP/1.1, idempotensi telah ditakrifkan. Ia menerangkan bahawa satu dan beberapa permintaan untuk sumber harus mempunyai hasil yang sama untuk sumber itu sendiri, iaitu, permintaan pertama mempunyai kesan sampingan pada sumber, tetapi permintaan berikutnya tidak akan mempunyai kesan sampingan pada sumber. Kesan sampingan di sini tidak merosakkan keputusan atau menghasilkan keputusan yang tidak dapat diramalkan. Dalam erti kata lain, sebarang pelaksanaan berbilang mempunyai kesan yang sama ke atas sumber itu sendiri sebagai satu pelaksanaan.
Masalah jenis ini kebanyakannya berlaku dalam antara muka: operasi
insert
Dalam kes ini, berbilang permintaan mungkin menghasilkan data pendua. Operasi update
, jika hanya mengemas kini data, seperti: update user set status=1 where id=1
, tiada masalah. Jika terdapat pengiraan, seperti: update user set status=status 1 where id=1
, berbilang permintaan dalam kes ini boleh menyebabkan ralat data. Penyerahan berulang borang di bahagian hadapan: Apabila mengisi beberapa borang, pengguna melengkapkan penyerahan, dan banyak lagi. kali pengguna tidak akan diberi jawapan penyerahan yang berjaya dalam masa disebabkan turun naik rangkaian , menyebabkan pengguna berfikir bahawa penyerahan tidak berjaya, dan kemudian terus mengklik butang serah Pada masa ini, penyerahan berulang permintaan borang akan berlaku.
1.3. Kesan pada sistem selepas memperkenalkan mati pucuk
Tukar fungsi pelaksanaan selari kepada pelaksanaan bersiri, yang mengurangkan kecekapan pelaksanaan.
Kami juga boleh menggunakan 雪花算法(Snowflake)
untuk menjana ID unik.
Algoritma Kepingan Salji ialah algoritma yang menjana ID unik yang diedarkan secara global ID yang dijana dipanggil Snowflake IDs
. Algoritma ini dicipta oleh Twitter dan digunakan untuk ID tweet.
ID Snowflake mempunyai 64 bit.
Sudah tentu, anda juga boleh menggunakan Baidu Uidgenerator
atau Meituan Leaf
untuk ID unik global.
Proses pemprosesan idempoten, dalam analisis akhir, adalah untuk menapis permintaan yang diterima A全局唯一的ID标记
ha. Kemudian, bagaimana untuk menentukan sama ada permintaan telah diterima sebelum ini? Simpan permintaan. Apabila menerima permintaan, semak rekod storan dahulu. Jika rekod wujud, hasil terakhir akan dikembalikan. Jika rekod tidak wujud, permintaan akan diproses.
Pemprosesan idempoten am adalah seperti ini, seperti berikut:
Apa yang anda fikirkan ialah selagi permintaan itu mempunyai nombor permintaan unik, anda boleh menggunakan Redis untuk melakukan penyahduaan ini - selagi nombor permintaan unik itu wujud dalam Redis, ia terbukti Jika diproses, ia dianggap sebagai pendua.
Penerangan projek:
Apa yang dipanggil nombor urutan permintaan unik sebenarnya bermakna setiap kali permintaan dibuat kepada pelayan, ia disertakan dengan nombor urutan unik dan tidak berulang dalam tempoh masa yang singkat. Nombor jujukan boleh menjadi nombor urutan tertib .
Apabila pelayan huluan menerima maklumat permintaan, ia menggabungkan nombor siri dan ID pengesahan hiliran untuk membentuk Kunci untuk mengendalikan Redis, dan kemudian menanyakan Redis untuk melihat sama ada terdapat pasangan nilai kunci untuk yang sepadan Kunci. Menurut Hasilnya:
Operasi yang berkenaan:
Sekatan penggunaan :
Perkhidmatan hiliran menjana ID yang diedarkan sebagai nombor siri, dan kemudian melaksanakan permintaan untuk memanggil antara muka huluan, bersama-sama dengan "nombor siri unik" dan "ID Bukti Kesahan Pengesahan" yang diminta.
Perkhidmatan huluan melaksanakan pengesahan keselamatan dan mengesan sama ada terdapat "nombor siri" dan "ID bukti kelayakan" dalam parameter yang dihantar ke hiliran. Perkhidmatan huluan mengesan sama ada terdapat Kunci yang terdiri daripada "nombor siri" dan "ID pengesahan" yang sepadan dalam Redis Jika wujud, ia akan membuang mesej pengecualian pelaksanaan berulang dan kemudian membalas hiliran yang sepadan mesej ralat. Jika ia tidak wujud, gabungan "nombor siri" dan "ID pengesahan" akan digunakan sebagai Kunci, dan maklumat kunci hiliran akan digunakan sebagai Nilai, dan kemudian disimpan dalam Redis, dan kemudian logik perniagaan seterusnya akan dilaksanakan secara normal.Penerangan program:
Sekatan penggunaan:
Proses utama:
Pelayan menyediakan antara muka untuk mendapatkan Token boleh menjadi nombor siri, ID yang diedarkan atau rentetan UUID.
Pelanggan memanggil antara muka untuk mendapatkan Token Pada masa ini, pelayan akan menjana rentetan Token.
Kemudian simpan rentetan dalam pangkalan data Redis, menggunakan Token sebagai kekunci Redis (perhatikan masa tamat tempoh).
Kembalikan Token kepada pelanggan Selepas pelanggan mendapatnya, ia hendaklah disimpan dalam medan tersembunyi borang.
Apabila pelanggan melaksanakan dan menyerahkan borang, ia menyimpan Token dalam pengepala dan membawa pengepala bersamanya apabila melaksanakan permintaan perniagaan.
Selepas menerima permintaan, pelayan mendapat Token daripada Pengepala, dan kemudian menyemak sama ada kunci wujud dalam Redis berdasarkan Token.
Pelayan menentukan sama ada kunci wujud dalam Redis Jika ia wujud, ia memadamkan kunci dan kemudian melaksanakan logik perniagaan seperti biasa. Jika ia tidak wujud, pengecualian akan dilemparkan dan mesej ralat untuk penyerahan berulang akan dikembalikan.
Perhatikan bahawa dalam keadaan serentak, melaksanakan carian dan pemadaman data Redis perlu memastikan atomicity, jika tidak, mati pucuk mungkin tidak dijamin di bawah konkurensi. Pelaksanaannya boleh menggunakan kunci teragih atau menggunakan ungkapan Lua untuk log keluar pertanyaan dan memadam operasi.
Pembelajaran yang disyorkan: Tutorial video Redis
Atas ialah kandungan terperinci Mari kita bincangkan secara ringkas tentang dua penyelesaian untuk Redis mengendalikan mati pucuk antara muka.. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!