Analisis ringkas kunci dalam Redis, mari bercakap tentang Redlock (kunci edaran redis)

Artikel ini akan membincangkan tentang kunci dalam Redis dan memperkenalkan mengapa kunci digunakan Adakah anda benar-benar memerlukan Redlock (kunci diedarkan redis) Saya harap ia akan membantu semua orang!

Mengapa menggunakan kunci

Syarikat pendidikan k12 tempat saya bekerja, kami mempunyai senario perniagaan adalah seperti ini. Pihak perniagaan perlu mengatur kelas untuk pelajar Sesekali, akan ada maklum balas bahawa waktu kelas pelajar jelas mencukupi tetapi terdapat masa kelas tidak mencukupi Apabila halaman dimuat semula, didapati bahawa waktu kelas pelajar tidak lagi mencukupi. Apa yang lebih menakutkan ialah kadangkala waktu kelas pelajar akan ditolak kepada nombor negatif (waktu kelas syarikat akan digunakan secara percuma). [Cadangan berkaitan: Tutorial video Redis]

Contoh lain ialah berikut

Dua soalan di atas dihantar kepada masalah yang timbul daripada perniagaan kami. Penyelesaian teras kepada masalah ini ialah hanya satu permintaan boleh dibenarkan untuk membaca dan menulis data sensitif (penting) ini pada masa yang sama. Oleh itu, kunci yang diedarkan mesti digunakan pada masa ini untuk mengehadkan pelaksanaan serentak program.

Apakah masalah dengan setnx

Mari kita lihat dahulu cara melaksanakan kunci teragih menggunakan Redis, yang mesti diketahui oleh semua orang . Sebagai contoh, untuk masalah penjadualan kelas pelajar yang dinyatakan pada permulaan artikel saya, kita boleh menguncinya seperti ini

Beginilah cara kita menggunakan setnx secara rutin untuk melaksanakan penguncian.

Sekarang mari kita anggap ada senario sedemikian. Apabila meminta A untuk mendapatkan kunci, atur cara menutup dalam langkah 2 apabila menjadualkan kelas untuk pelajar, dan kunci tidak dilepaskan. Kemudian kunci menjadi kebuntuan Permintaan seterusnya untuk mengendalikan pelajar yang sama tidak akan mendapat kunci, dan pelajar tidak boleh dijadualkan. Pada masa ini, anda perlu melepaskan kunci secara manual.

Untuk menyelesaikan masalah kebuntuan, kami menambah masa tamat tempoh pada kunci.

Selepas menambah masa tamat tempoh, jika permintaan A tidak melepaskan kunci secara aktif, ia akan dilepaskan secara aktif selepas kunci tamat tempoh, supaya permintaan B juga boleh mendapatkan kunci memproses logik perniagaan. Tetapi jika masa tamat tempoh ditambah, program ranap antara langkah 1 dan 2. Kemudian masih akan ada masalah kebuntuan. Punca masalah ini ialah dua arahan setnx dan tamat tempoh bukan arahan atom. Oleh itu, lebih baik jika setnx dan tamat tempoh sama ada boleh melaksanakan semua atau tiada satu pun daripadanya.

Atas sebab ini, sebelum Redis2.8, sejumlah besar pakej sambungan muncul dalam komuniti untuk menyelesaikan masalah ini. Untuk mengawal kekacauan ini, pegawai menambah parameter lanjutan arahan set dalam versi 2.8 supaya arahan setnx dan tamat tempoh boleh dilaksanakan bersama, jadi sekarang kita harus menggunakan kunci yang diedarkan seperti ini

Ini kelihatan sempurna dan telah mencapai jangkaan kami "Alangkah bagusnya jika setnx dan expired boleh melaksanakan kesemuanya atau tiada satu pun". Mari kita anggap bahawa kita kini mempunyai senario berikut:

Permintaan kini telah memperoleh kunci dan tamat masa kunci ditetapkan kepada 5 saat. Dalam langkah 2, logik perniagaan dilaksanakan, tetapi atas sebab tertentu logik perniagaan tidak dilaksanakan selepas 5 saat Pada masa ini, kunci dilepaskan secara automatik kerana tamat masa. Pada masa ini, permintaan B juga datang, dan selepas mendapat kunci, logik perniagaan mula dilaksanakan. Pada masa ini, logik perniagaan permintaan A telah dilaksanakan, dan langkah ketiga dimulakan, dan kunci dilepaskan. Pada masa ini, kunci itu diperolehi atas permintaan B, tetapi dilepaskan atas permintaan A. Kemudian permintaan C boleh mendapatkan kunci. Pada masa ini, permintaan B dan permintaan C akan menyebabkan masalah konkurensi. Oleh itu, dapat dilihat dari contoh ini bahawa penetapan masa tamat dalam kunci teragih adalah sangat penting Jika masa yang ditetapkan kurang daripada masa tindak balas antara muka ini, masalah konkurensi masih akan berlaku. Oleh itu, kita boleh merujuk kepada pemantauan masa tindak balas antara muka untuk menetapkan masa tamat tempoh kunci.

Kunci Merah

Penyelesaian kami di atas semuanya berdasarkan pelaksanaan Redis satu titik. Pelaksanaan satu titik Redis kunci yang diedarkan pada asasnya boleh memenuhi 95% senario perniagaan. Baki 5% adalah senario perniagaan dengan keperluan yang sangat ketat mengenai konsistensi data dan toleransi sifar untuk kehilangan kunci. Pada masa ini, anda perlu mempertimbangkan Redlock. Bagi Redis titik tunggal, walaupun ia memastikan ketersediaan yang tinggi melalui sentinel, jika nod induk menukar induk-hamba atas sebab tertentu, dan jika penyegerakan data induk-hamba tidak tepat pada masanya, kehilangan data pasti akan berlaku dan mengunci kerugian akan berlaku.

Anggapkan terdapat berbilang kejadian Redis ini adalah bebas sepenuhnya dan tidak perlu menggunakan replikasi atau mana-mana sistem untuk menyelaraskan data kunci, langkahnya akan Menjadi seperti ini:

• Dapatkan masa pelayan semasa dalam milisaat

• Cuba gunakan kunci dan nilai rawak yang sama untuk memperoleh kunci Pelanggan harus mempunyai masa tamat apabila memperoleh kunci pada setiap mesin Contohnya, jika masa tamat tempoh kunci ialah 10s, kemudian dapatkan kunci nod tunggal. Masa tamat masa hendaklah kira-kira 5 hingga 50 milisaat Tujuannya adalah untuk memastikan pelanggan tidak menghabiskan masa tambahan untuk menyambung ke mesin yang gagal! Jika data tidak diperolehi dalam tempoh tamat masa, nod akan ditinggalkan dan nod Redis seterusnya akan diperolehi.

• Selepas pemerolehan selesai, dapatkan masa semasa tolak masa yang diperolehi dalam langkah 1, jika dan hanya jika pelanggan memperoleh kunci daripada lebih separuh (di sini, 3 nod) daripada nod Redis dan Jika masa untuk memperoleh kunci adalah kurang daripada tamat masa kunci, ia membuktikan bahawa kunci itu berkesan!

• Jika kunci diperoleh, masa sah sebenar kunci adalah sama dengan masa sah tolak masa yang digunakan untuk memperoleh kunci (hasil dikira dalam langkah 3).

• Jika lebih separuh daripada mesin yang memperoleh kunci tidak berpuas hati, atau tamat masa kunci negatif selepas pengiraan, atau operasi luar biasa lain, sistem akan cuba membuka kunci semua kejadian, walaupun beberapa kejadian Redis tidak dikunci sama sekali Tidak ada penguncian yang berjaya, yang menghalang beberapa nod daripada memperoleh kunci tetapi pelanggan tidak mendapat respons dan kunci tidak boleh diperoleh semula dalam tempoh masa seterusnya

Jadi, kita dapat melihat kunci merah itu sebenarnya Ia adalah kunci yang kelihatan lebih dipercayai daripada Redis satu titik.

Jika anda seorang pengaturcara Node.js seperti saya, maka terdapat pustaka pihak ketiga redlock yang boleh anda gunakan secara langsung.

Adakah kita benar-benar memerlukan redlock?

Sebenarnya ada suara lain tentang redlock, Martin Kleppmann (penyelidik di Universiti Cambridge, terlibat dalam pangkalan data, Projek TRVE DATA di persimpangan sistem teragih dan keselamatan maklumat telah menulis blog tentang beberapa pandangan tentang redlock Jika anda berminat, anda boleh membacanya. Pengarang Redis Salvatore juga membuat beberapa respons kepada soalan dalam artikel ini, yang agak menarik. Perkara utama blog penulis adalah seperti berikut:

Tidak lebih daripada dua kegunaan kunci yang diedarkan:

• Kecekapan: Menggunakan kunci boleh mengelakkan kerja yang sama dua kali yang tidak perlu ( seperti beberapa pengiraan yang mahal). Jika kunci gagal dan kedua-dua nod akhirnya melakukan kerja yang sama, hasilnya ialah sedikit peningkatan dalam kos (anda akhirnya membayar AWS 5 sen lebih daripada sebaliknya) atau sedikit kesulitan (contohnya, pengguna akhirnya menerima e-mel yang sama pemberitahuan).
• Ketepatan: Menggunakan kunci menghalang proses serentak daripada mengganggu antara satu sama lain dan merosakkan keadaan sistem. Jika kunci gagal dan dua nod memproses sekeping data yang sama pada masa yang sama, akibatnya ialah kerosakan fail, kehilangan data, ketidakkonsistenan kekal, dos ubat yang salah diberikan kepada pesakit, atau masalah lain yang sangat serius.

Jika untuk kecekapan, tidak perlu menanggung kos dan kerumitan Redlock Berbanding dengan kos menghantar beberapa e-mel lagi kerana kehilangan kunci dan kos menjalankan 5 Pelayan Redis, lebih baik hanya menggunakan satu Contoh Redis. Jika anda menggunakan satu contoh Redis dan nod Redis tiba-tiba kehilangan kuasa atau ranap, atau masalah lain berlaku, sudah tentu kunci akan hilang pada masa ini. Tetapi jika anda hanya menggunakan kunci sebagai pengoptimuman kecekapan, dan ranap jenis ini tidak kerap berlaku, itu bukan masalah besar. Senario "bukan masalah besar" ini adalah tepat di mana Redis cemerlang. Sekurang-kurangnya jika anda bergantung pada satu contoh Redis, semua orang yang melihat sistem akan dapat mencari masalah dengan lebih mudah.

Jika ia adalah untuk ketepatan, maka secara tegasnya, redlock tidak mempunyai ketegasan konsistensi yang kuat sama sekali. Beberapa contoh diberikan

• Masa dan jam sistem membuat andaian berbahaya dan sangat bergantung pada jam setiap pelayan. Disebabkan terdapat GC dalam sistem, seluruh pelayan dirempuh semasa GC, dan masa tidak berubah, jadi kami tidak boleh mempunyai pergantungan yang kuat pada jam.

• Tiada token. Pelayan tidak mengeluarkan token setiap kali pelanggan memperoleh kunci Pelayan harus mengesahkan bahawa token pelanggan mesti konsisten dengan token semasa pelayan semasa setiap operasi untuk menyukarkan pengendalian kunci.

Penulis memberi tumpuan terutamanya kepada perkara di atas Jika anda berminat, adalah disyorkan untuk membaca artikel asal.

Untuk lebih banyak pengetahuan berkaitan pengaturcaraan, sila lawati: Pengenalan kepada Pengaturcaraan! !

Atas ialah kandungan terperinci Analisis ringkas kunci dalam Redis, mari bercakap tentang Redlock (kunci edaran redis). Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!