Jika Redis Berulir Tunggal, lalu mengapa perlu mekanisme Penguncian sama sekali.
Redis memang (kebanyakan) berulir tunggal tetapi penguncian diperlukan ketika banyak klien mencoba melakukan hal yang berbeda pada kedekatan temporal yang berdekatan. Penguncian yang dibahas di RiA adalah persis seperti itu - memastikan bahwa hanya satu klien/utas yang melakukan tugas tertentu, atau memastikan pembaruan tidak salah.
Berikut adalah contoh mengapa Anda perlu mengunci meskipun Redis 'tunggal-threadedness:anggap Anda memiliki nilai di Redis, nomor misalnya disimpan di bawah kunci bernama foo . Kode aplikasi Anda membaca nomor itu (GET foo ), melakukan sesuatu (mis. menambahkan 1) dan menulisnya kembali (SET ). Saat Anda menjalankan kode dalam satu utas, beginilah tampilannya:
App Redis
|---- GET foo ---->|
|<------ 1 --------|
| |
| thinking... |
| |
|--- SET foo 2 --->|
|<----- OK --------|
Sekarang mari kita lihat apa yang terjadi ketika dua klien aplikasi mencoba melakukan ini:
App 1 Redis App 2
|---- GET foo ---->| |
|<------ 1 --------|<--- GET foo -----|
| |------- 1 ------->|
| thinking... | |
| | thinking...|
|--- SET foo 2 --->| |
|<----- OK --------|<--- SET foo 2 ---|
| |------ OK ------->|
Di sini Anda dapat langsung melihat apa yang terjadi tanpa mengunci, meskipun server (kebanyakan) berulir tunggal - alih-alih 3, foo 's value adalah 2. Saat Anda menambahkan lebih banyak utas/klien/aplikasi, banyak hal bisa menjadi salah dan sangat salah ketika banyak penulis mencoba memodifikasi data tanpa koordinasi (mis. mengunci).
Penguncian yang optimis hanyalah salah satu cara untuk melakukannya, yang ditawarkan Redis bawaan melalui WATCH mekanisme. Namun, terkadang optimisme - meskipun sifatnya santai dan bahagia - bukanlah solusi yang tepat sehingga Anda perlu menerapkan mekanisme yang lebih baik/maju/berbeda untuk mencegah kondisi balapan. Kunci seperti itu, bisa dibilang, dapat diterapkan bahkan di luar Redis, tetapi jika Anda sudah menggunakannya maka masuk akal untuk mengelola kunci Anda di dalamnya juga.
