Redis Command Options

[00:00:00]
>> Let's talk about some command options. So there's a thing called n x and x x. And basically what you want to do is like alright, Redis, set this and if it does exist fail or set this and if it doesn't exist fail, right so you're kind of giving it like a condition.

[00:00:19]
Did I only wanna set this if it already exists, or I only wanna set this if it doesn't exist. So let's just kind of do an example here. So if I say set color, and I haven't not set color yet, right? So if I say exists colour it's gonna say zero, right?

[00:00:37]
So if I say set colour blue and then I put x x here, this is gonna fail because this doesn't exist yet. Right and so if I say again exists colour. It's gonna say no still doesn't exist. So that's what this x x does. This option here basically says, if this doesn't exist, don't set it.

[00:01:00]
This should fail. Let me show you the flip side of that. If I say set color. NX. If it doesn't exist, then it's going to succeed. It doesn't exist right now. So this will work. So you can see here it says okay. Worked. Exist color, it does exist, get color, it should say blue.

[00:01:23]
Now let's say if I say set color green, and I put xx. This will succeed because color already exists. Right? Says okay, but now if I try and say set color yellow NX, this will fail because it does exist. So you're just kinda trying to say, you want to add a condition that this only works if it does or doesn't exist.

[00:01:55]
This is occasionally useful. I'm not going to say it's probably pretty rarely useful to me but it's probably just good to know that it's out there that if you do need something, some behavior like that, you can do it in one query instead of asking exists and then set it.

[00:02:10]
You can actually just do it in one query and say if this query fails, then a new ad already existed already didn't exist. So actually, if we go back to our like our set plane, the one that I was doing before this, get plane zero, zero. Before if I was doing this, I would have had to say I would have to do two queries every time.

[00:02:32]
Does this exist? And if it does, don't go that way. I could just do this with an NX, right? And then I could just see if the query succeeded or failed. That would be a good use case for using this XX and NX. Makes sense? For the record, I can never keep straight if XX or NX does what.

[00:02:55]
I have to look it up every single time. That's totally fine. I just the way that I can kind of keep it in my mind is that nx succeeds when it does not exist when it not exists, right. I'll forget that in 20 minutes though I can never remember you can see I have to look at my notes every single time that I say it out loud.

[00:03:14]
So I don't want like an idiot. More so than I already do. Let's talk about TTS. This one actually is fairly useful to me. I haven't talked about t TLS. In other databases, they actually do exist in Postgres. They do exist in MongoDB for sure. I'm gonna assume they exist in Neo Forge.

[00:03:33]
I've never actually looked but let's talk about because I use them all the time in Redis. TTL stands for time to live and basically it says that at some point I want this thing to expire like I want you to delete this after 30 seconds. So a good example of when to use this let's say you're querying your telemetry data, but you want to do it every single day.

[00:03:53]
What you can do is like okay put this in cash save it for a day and after a day Just go ahead and delete it. That's what a TTL does. So let's say you're writing like a fitness app. So you could say set fitness. The amount of total work done today by the user bt Holt.

[00:04:15]
And you can say that, you know, I burned 700 or I did 750 kilojoules of work today. I'd be proud of myself if I did that. I did not do that today. Okay. But let's say I need to refresh this view every single day and I don't want to just have it, you know, go stale.

[00:04:35]
So what you can do is you can give it a TTL. So if I put EX you can think expires In 3600 seconds, so the EX is in seconds, keep that in mind. Now, this will end up, staying alive for was it like, 12 hours or something like that.

[00:04:58]
Whatever 36 It's been a long day. I cannot do math in my head right now. So that's 300 minutes. Out of 65 hours. I don't know why I chose five hours but there you go. So Now I can say get fitness. Total PT Holt and it'll get that back that after a certain amount of time of 3600 seconds it's going to expire right So let's just see an example of that.

[00:05:30]
So I'm gonna say set temp key to be high and we'll give an expiry of five seconds. See if I can do this fast enough get temp key, they'll say hi. But if I keep doing this, in fact, there you can see there. It expired. Now it's gone.

[00:05:51]
It deletes itself. So that's a TTL. You can do with EX. There's also PX and this is milliseconds. So if I put 1000 that's like 1000 milliseconds. Typically I don't need PX but it's there if you need something more granular let's talk just just a moment about the thundering herd Now if you're a web developer, you've either heard that term before and you've just cringe inside when you hear the term thundering herd, or you haven't experienced it yet, and hopefully I can save you from experiencing it.

[00:06:29]
But I probably won't, you probably will at some point in your webdevelopment career. Thundering herd is this idea that your cache expires and before you can refresh the cache. All these people come in and start hitting your database, and everything just falls apart because it's the thundering herd that just crashes on your database.

[00:06:49]
So let me give you an example of that. A common way of doing caching is saying, if I can find this thing in the cache, serve it from the cache, if I can't find it from the cache, go get it from the database, and then serve it to or then set it in the cache and serve it to the user.

[00:07:05]
Right? That's kinda a obvious way of doing caching, right? If I can get it serve it, if I can't go get it and then set it, so I don't have to do it again later. And you'll do that with TTL. Right? You'll say this cache is good for six hours.

[00:07:19]
So here's the problem with that particular setup. If you set it up like that, during that very short window of when the caches expired and it hasn't yet been set in the cache again, there's a period of time where if you have a Mm users all hit that one endpoint.

[00:07:39]
They are all gonna hit the database and they're not gonna hit the cash. And it's it's called the Thundering Herd. It's gonna bring your app server down. This has happened to me multiple times specifically at Reddit. We had we were doing a flash sale on our Marketplace on red.

[00:07:55]
And we hit the thundering herd. And I think we went down for like two hours on Black Friday. I mean, it was a disaster for like our e commerce. So hopefully, I can save you a bit of grief. So let me talk about how do you avoid thundering herd with TTS?

[00:08:13]
Well, one, don't use TTS with caches in this particular scenario. The much better way of doing this is leaving that cache there. And then having a cron job or some periodically running job in the background, that will go and set the cache so that the cache is always there.

[00:08:29]
And then there's something some background job that's just resetting the cache every so often. And you're not relying on the app server to do it because you're going to hit the thundering herd.