TL;DR :Единична нишка прави redis по-опростен, а redis все още е свързан с IO.
Паметта е I/O. Redis все още е I/O обвързан. Когато redis е под тежък товар и достига максимални заявки в секунда, той обикновено изпитва глад за мрежова честотна лента или честотна лента на паметта и обикновено не използва голяма част от процесора. Има определени команди, за които това няма да е вярно, но в повечето случаи на употреба redis ще бъде силно I/O обвързан с мрежа или памет.
Освен ако скоростите на паметта и мрежата внезапно не станат по-бързи с порядък, това обикновено не е проблем. Ако трябва да мащабирате отвъд една или няколко нишки (т.е. настройка на главен<->подчинен<->подчинен), вече разглеждате Redis Cluster. В този случай можете да настроите екземпляр на клъстер за ядро на процесора, ако по някакъв начин сте изтощени от процесора и искате да увеличите максимално броя на нишките.
Не съм много запознат с източника на redis или вътрешните елементи, но виждам как използването на една нишка улеснява прилагането на атомни действия без заключване. Нишките биха направили това по-сложно и изглежда не предлага големи предимства, тъй като redis не е свързан с процесора. Внедряването на едновременност на ниво над екземпляр на redis изглежда като добро решение и за това помагат Redis Sentinel и Redis Cluster.
Какво се случва с другите заявки, когато redis отнема много време?
Тези други заявки ще блокират, докато redis завърши дългата заявка. Ако е необходимо, можете да тествате това с помощта на client-pause команда.
