Ada beberapa pertanyaan di sini.
1) Mengapa kita tidak bisa mengeksekusi kenaikan transaksi yang tidak bisa diinterupsi oleh perintah lain?
Harap dicatat terlebih dahulu bahwa "transaksi" Redis benar-benar berbeda dari apa yang kebanyakan orang pikirkan tentang transaksi dalam DBMS klasik.
# Does not work
redis.multi()
current = redis.get('powerlevel')
redis.set('powerlevel', current + 1)
redis.exec()
Anda perlu memahami apa yang dieksekusi di sisi server (di Redis), dan apa yang dieksekusi di sisi klien (dalam skrip Anda). Dalam kode di atas, perintah GET dan SET akan dieksekusi di sisi Redis, tetapi penugasan ke arus dan perhitungan arus +1 seharusnya dieksekusi di sisi klien.
Untuk menjamin atomisitas, blok MULTI/EXEC menunda eksekusi perintah Redis hingga exec. Jadi klien hanya akan menumpuk perintah GET dan SET di memori, dan mengeksekusinya dalam satu kesempatan dan secara atom pada akhirnya. Tentu saja, upaya untuk menetapkan arus ke hasil GET dan peningkatan akan terjadi jauh sebelumnya. Sebenarnya metode redis.get hanya akan mengembalikan string "QUEUED" untuk menandakan perintah tertunda, dan inkremen tidak akan berfungsi.
Dalam blok MULTI/EXEC Anda hanya dapat menggunakan perintah yang parameternya dapat diketahui sepenuhnya sebelum blok dimulai. Anda mungkin ingin membaca dokumentasi untuk informasi lebih lanjut.
2) Mengapa kita perlu mengulang dan menunggu sampai tidak ada yang mengubah nilai sebelum transaksi dimulai?
Ini adalah contoh pola optimis bersamaan.
Jika kami tidak menggunakan WATCH/MULTI/EXEC, kami akan memiliki kondisi balapan potensial:
# Initial arbitrary value
powerlevel = 10
session A: GET powerlevel -> 10
session B: GET powerlevel -> 10
session A: current = 10 + 1
session B: current = 10 + 1
session A: SET powerlevel 11
session B: SET powerlevel 11
# In the end we have 11 instead of 12 -> wrong
Sekarang mari tambahkan blok WATCH/MULTI/EXEC. Dengan klausa WATCH, perintah antara MULTI dan EXEC dijalankan hanya jika nilainya tidak berubah.
# Initial arbitrary value
powerlevel = 10
session A: WATCH powerlevel
session B: WATCH powerlevel
session A: GET powerlevel -> 10
session B: GET powerlevel -> 10
session A: current = 10 + 1
session B: current = 10 + 1
session A: MULTI
session B: MULTI
session A: SET powerlevel 11 -> QUEUED
session B: SET powerlevel 11 -> QUEUED
session A: EXEC -> success! powerlevel is now 11
session B: EXEC -> failure, because powerlevel has changed and was watched
# In the end, we have 11, and session B knows it has to attempt the transaction again
# Hopefully, it will work fine this time.
Jadi, Anda tidak perlu mengulangi untuk menunggu sampai tidak ada yang mengubah nilainya, melainkan mencoba operasi berulang kali hingga Redis yakin nilainya konsisten dan menandakan bahwa itu berhasil.
Dalam kebanyakan kasus, jika "transaksi" cukup cepat dan kemungkinan pertengkaran rendah, pembaruan sangat efisien. Sekarang, jika ada pertentangan, beberapa operasi tambahan harus dilakukan untuk beberapa "transaksi" (karena iterasi dan percobaan ulang). Namun data akan selalu konsisten dan tidak diperlukan penguncian.
