Mengapa kunci teragih diperlukan dalam Redis? Bagaimana untuk mencapai-Redis-php.cn

Artikel ini akan memperkenalkan anda kepada kunci yang diedarkan dalam Redis, mengapa kunci yang diedarkan diperlukan dan cara Redis melaksanakan kunci yang diedarkan saya harap ia akan membantu anda.

Mengapa kunci teragih diperlukan dalam Redis? Bagaimana untuk mencapai

Mengapa kunci yang diedarkan diperlukan

Mengapa kunci yang diedarkan diperlukan

Gunakan Tujuan kunci yang diedarkan tidak lebih daripada untuk memastikan hanya satu pelanggan boleh beroperasi pada sumber yang dikongsi pada masa yang sama.

Kami sering menghadapi masalah konkurensi apabila melakukan pemprosesan logik dalam aplikasi yang diedarkan. [Pengesyoran berkaitan: Tutorial video Redis]

Sebagai contoh, jika operasi memerlukan pengubahsuaian status pengguna, mengubah suai status memerlukan membaca status pengguna terlebih dahulu, mengubah suai dalam memori dan kemudian menyimpannya semula selepas pengubahsuaian. Jika operasi sedemikian dilakukan pada masa yang sama, masalah konkurensi akan timbul kerana kedua-dua operasi membaca dan keadaan menyimpan bukan atom.

Pada masa ini, kunci yang diedarkan digunakan untuk mengehadkan pelaksanaan serentak program. Sebagai sistem perisian tengah caching, redis boleh menyediakan mekanisme kunci teragih seperti ini

Intipatinya adalah untuk menduduki lubang dalam redis Apabila proses lain mahu menduduki lubang itu telah mendudukinya, tunggu dan cuba lagi kemudian

Secara umumnya, kunci teragih yang tersedia dalam persekitaran pengeluaran perlu memenuhi perkara berikut:

Pengecualian bersama ialah ciri asas kunci Hanya satu utas boleh memegang kunci pada masa yang sama dan melakukan operasi kritikal Membandingkan konfigurasi
innodb_lock_wait_timeout, dalam persekitaran teragih, benang yang sama pada nod yang sama Jika kunci diperoleh, permintaan; masih boleh berjaya lagi;

Kaedah pelaksanaan

Gunakan SETNX untuk melaksanakan

Kaedah penggunaan SETNX ialah :

Hanya apabila kunci kunci tidak wujud, nilai kunci kunci ditetapkan kepada nilai Jika kunci kunci wujud, SETNX tidak mengambil sebarang tindakan.

SETNX key value

Penyelesaian ini mempunyai masalah maut, iaitu selepas benang memperoleh kunci dan tidak dapat melakukan operasi membuka kunci secara normal disebabkan oleh beberapa faktor yang tidak normal (seperti masa henti), maka kunci tidak akan dilepaskan. .

boolean result = jedis.setnx("lock-key",true)== 1L;
if  (result) {
    try {
        // do something
    } finally {
        jedis.del("lock-key");
    }
 }

Salin selepas log masuk

Untuk tujuan ini, kita boleh menambah tempoh tamat masa pada kunci ini

Kesan melaksanakan

adalah bersamaan dengan kesan melaksanakan

SET key value EX secondsSETEX key seconds valueMelaksanakan

SET key value PX millisecondsPSETEX key milliseconds value

String result = jedis.set("lock-key",true, 5);
if ("OK".equals(result)) {
    try {
        // do something
    } finally {
        jedis.del("lock-key");
    }
}

Salin selepas log masuk

Penyelesaian kelihatan sempurna, tetapi sebenarnya masih ada masalah

Bayangkan benang A tertentu memperoleh kunci dan menetapkan masa tamat tempoh ialah 10s, dan kemudian mengambil masa 15s untuk melaksanakan logik perniagaan Pada masa ini, kunci yang diperolehi oleh utas A telah dilepaskan secara automatik oleh mekanisme tamat tempoh Redis

Selepas utas A memperoleh kunci dan 10s. telah berlalu, tukar Kunci mungkin telah diperolehi oleh benang lain. Apabila utas A selesai melaksanakan logik perniagaan dan bersedia untuk membuka kunci (

), adalah mungkin untuk memadamkan kunci yang telah diperoleh oleh utas lain.

DEL keyJadi cara terbaik ialah menentukan sama ada kunci itu milik anda semasa membuka kunci Kami boleh menetapkan nilai kepada nilai unik

(boleh menjadi nilai rawak, UUID atau gabungan nombor mesin, benang. nombor, tandatangan, dsb.).

keyApabila membuka kunci, iaitu, apabila memadamkan kekunci, tentukan dahulu sama ada nilai yang sepadan dengan kunci itu sama dengan nilai yang ditetapkan sebelum ini, jika ia sama, kunci itu boleh dipadamkanuniqueValue

Di sini kita boleh melihatnya sepintas lalu Masalah timbul:

dan

String velue= String.valueOf(System.currentTimeMillis())
String result = jedis.set("lock-key",velue, 5);
if ("OK".equals(result)) {
    try {
        // do something
    } finally {
      	//非原子操作
	      if(jedis.get("lock-key")==value){
		        jedis.del("lock-key");
        }    
    }
}

Salin selepas log masuk

ialah dua operasi berasingan Pengecualian mungkin berlaku dalam jurang antara pelaksanaan GET dan sebelum pelaksanaan DEL.

GETJika kita hanya perlu memastikan bahawa kod buka kunci adalah atom, kita boleh menyelesaikan masalah DEL

Di sini kami memperkenalkan kaedah baharu, iaitu

skrip Lua

, contohnya adalah seperti berikut :

di mana

mewakili nilai unik yang ditentukan semasa menetapkan kunci.

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

Salin selepas log masuk

Disebabkan atomicity skrip Lua, semasa proses Redis melaksanakan skrip, arahan klien lain perlu menunggu skrip Lua dilaksanakan sebelum ia boleh dilaksanakan. ARGV[1]

Pastikan bahawa masa tamat tempoh adalah lebih besar daripada masa pelaksanaan perniagaan

Untuk mengelakkan berbilang rangkaian daripada melaksanakan kod perniagaan pada masa yang sama, adalah perlu untuk memastikan bahawa masa tamat tempoh adalah lebih besar daripada masa pelaksanaan perniagaan

Tingkatkan Atribut jenis boolean

yang digunakan untuk mengenal pasti sama ada untuk mendayakan masa tamat penyegaran semula yang dijadualkan

sedang menambah kaedah isOpenExpirationRenewal untuk mendayakan utas untuk menyegarkan masa tamat tempoh

kod penguncian sedang diperolehi Selepas kunci berjaya, tetapkan isOpenExpirationRenewal kepada benar dan panggil kaedah scheduleExpirationRenewal untuk memulakan urutan yang menyegarkan masa tamat tempoh 🎜>Tambah baris kod pada kod buka kunci, tetapkan atribut isOpenExpirationRenewal kepada palsu dan hentikan mengundi urutan yang menyegarkan masa tamat tempoh.

scheduleExpirationRenewalPelaksanaan Semula

Tugas berjadual akan dimulakan jika kunci berjaya diperoleh dan tugas berjadual akan diperiksa secara berkala untuk pembaharuan

Perbezaan masa antara setiap panggilan jadual berjadual ini ialah internalLockLeaseTime / 3, iaitu 10 saat

Secara lalai, masa penguncian ialah 30 saat Jika perniagaan terkunci belum selesai, maka saat, pembaharuan akan dilakukan dan kunci akan ditetapkan semula kepada 30 saat 30-10 = 20

RedLock

Dalam kelompok, apabila nod induk dimatikan, hamba Nod akan menggantikannya, tetapi tidak akan ada persepsi yang jelas pada klien. Ternyata pelanggan pertama berjaya memohon kunci pada nod induk, tetapi sebelum kunci itu boleh disegerakkan ke nod hamba, nod induk tiba-tiba mati. Kemudian nod hamba menjadi nod induk ini tidak mempunyai kunci ini di dalam, jadi apabila pelanggan lain datang untuk meminta kunci, ia diluluskan serta-merta. Ini akan menyebabkan kunci yang sama dalam sistem dipegang oleh dua pelanggan pada masa yang sama, mengakibatkan rasa tidak selamat

Algoritma Redlock adalah untuk menyelesaikan masalah ini

Untuk gunakan Redlock, anda perlu menyediakan berbilang

contoh, yang sebelum ini bebas antara satu sama lain dan tidak mempunyai hubungan tuan-hamba. Seperti kebanyakan algoritma yang diedarkan, kunci merah juga menggunakan kebanyakan mekanisme Redis

apabila mengunci, ia akan menghantar arahan yang ditetapkan kepada lebih separuh daripada nod Selagi lebih separuh daripada nod

berjaya, kunci itu dipertimbangkan berjaya. Apabila melepaskan kunci, arahan del perlu dihantar ke semua nod. Walau bagaimanapun, algoritma Redlock juga perlu mempertimbangkan banyak isu terperinci seperti percubaan semula ralat dan drift jam Pada masa yang sama, kerana set perlu membaca dan menulis ke berbilang nod, ini bermakna berbanding dengan contoh tunggal Redis, prestasi akan. menjadi lebih rendah. Redlock

Algoritma Redlock Ia ialah mod ketersediaan tinggi yang diperkenalkan berdasarkan satu nod Redis tunggal berdasarkan N nod Redis yang bebas sepenuhnya, biasanya nombor ganjil lebih daripada 3 (biasanya N boleh ditetapkan kepada 5), yang pada asasnya boleh menjamin bahawa setiap nod dalam kluster tidak akan Downtime pada masa yang sama.

Dengan mengandaikan bahawa kluster semasa mempunyai 5 nod, pelanggan yang menjalankan algoritma Redlock melakukan langkah berikut untuk melengkapkan operasi pemerolehan kunci

Cuba dapatkan kunci daripada 5 kejadian Redis menggunakan kunci yang sama dalam urutan Apabila meminta untuk mendapatkan kunci daripada Redis, pelanggan harus menetapkan sambungan rangkaian dan tamat masa tindak balas tamat masa hendaklah kurang daripada masa tamat tempoh kunci untuk mengelakkan masalah akibat kegagalan rangkaian
Pelanggan menggunakan masa semasa tolak masa untuk mula memperoleh kunci untuk mendapatkan masa untuk memperoleh kunci, jika dan hanya jika ia adalah daripada separuh Nod Redis di atas memperoleh kunci, dan apabila masa yang digunakan kurang daripada masa tamat tempoh kunci, kunci itu dianggap berjaya; adalah sama dengan masa berkesan tolak masa yang digunakan untuk memperoleh masa kunci untuk mengurangkan peluang tamat masa
Jika pemerolehan kunci gagal, pelanggan harus membuka kuncinya pada semua kejadian Redis. permintaan operasi sebelumnya gagal, untuk mengelakkan mesej respons pelayan daripada hilang, tetapi Ketidakkonsistenan disebabkan oleh penambahan data sebenar yang berjaya.
Dalam erti kata lain, dengan mengandaikan bahawa kunci tamat tempoh dalam 30 saat, ia mengambil masa 31 saat untuk mengunci tiga nod Sememangnya, penguncian gagal

Dalam Redis mengesyorkan pelanggan Java secara rasmi

mempunyai pelaksanaan terbina dalam

RedissonRedLockhttps://redis.io/topics/distlock

https://github.com/redisson/redisson/ wiki

Masalah RedLock:

RedLock hanya memastikan ketersediaan tinggi kunci, tetapi tidak menjamin ketepatan kunci

RedLock ialah

Sistem teragih yang banyak bergantung pada jam sistem

Kritikan Martin terhadap RedLock:

RedLock terlalu berat untuk senario peningkatan kecekapan.

Artikel ini diterbitkan semula daripada: https://juejin.cn/post/7018968452136173576

Pengarang: Dengan Hati yang Jauh

Lebih banyak pengaturcaraan berkaitan Untuk pengetahuan, sila layari:
Video Pengaturcaraan

! !

Atas ialah kandungan terperinci Mengapa kunci teragih diperlukan dalam Redis? Bagaimana untuk mencapai. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!