Ако Redis е с една нишка, тогава защо изобщо се нуждаете от заключващ механизъм.
Redis наистина е (предимно) еднонишков, но се изисква заключване, когато множество клиенти се опитват да направят различни неща в съседна времева близост. Заключването, обсъждано в RiA, е точно това – гарантиране, че само един клиент/нишка изпълнява конкретна задача, или гарантиране, че актуализациите няма да се объркат.
Ето пример защо се нуждаете от заключване въпреки еднонишковостта на Redis:приемете, че имате стойност в Redis, число, например, съхранявано под ключ с име foo . Кодът на приложението ви чете този номер (GET foo ), прави нещо (напр. добавя 1) и го записва обратно (SET ). Когато стартирате кода си в една нишка, това ще изглежда така:
App Redis
|---- GET foo ---->|
|<------ 1 --------|
| |
| thinking... |
| |
|--- SET foo 2 --->|
|<----- OK --------|
Сега нека видим какво се случва, когато два клиента на приложението се опитат да направят това:
App 1 Redis App 2
|---- GET foo ---->| |
|<------ 1 --------|<--- GET foo -----|
| |------- 1 ------->|
| thinking... | |
| | thinking...|
|--- SET foo 2 --->| |
|<----- OK --------|<--- SET foo 2 ---|
| |------ OK ------->|
Тук можете веднага да видите какво се е случило без заключване, въпреки че сървърът е (предимно) еднонишков - вместо 3, foo Стойността на 's е 2. Когато добавяте повече нишки/клиенти/приложения, нещата могат да се объркат и ужасно да се объркат, когато множество писатели се опитат да променят данните без координация (напр. заключване).
Оптимистичното заключване е само един от начините за това, който Redis предлага вграден чрез WATCH механизъм. Понякога обаче оптимизмът - въпреки неговата лесна и щастлива природа - не е правилното решение, така че ще трябва да приложите по-добри/разширени/различни механизми, за да предотвратите условията на състезанието. Такива ключалки могат да се внедрят дори извън Redis, но ако вече го използвате, тогава има смисъл да управлявате и вашите ключалки в него.
