been learning redis properly for a side project and putting together notes as I go so I actually remember this stuff.
always just knew "redis is in memory so it's fast" and left it at that. turns out the part that actually matters is that it runs commands on a single thread. that's not a downside, it's what removes the need for locking, which is the real reason it stays predictable instead of just fast most of the time. the catch is if one command is slow (a big scan, a big sort) it blocks every other request until it finishes, since nothing else can run at the same time. apparently that's exactly why you're told never to run keys in production and to use scan instead.
feels obvious now but I definitely didn't know this a week ago. anyone have other redis basics that took way too long to click for you.
[link] [留言]
