Another Redis in Rust series. It’s really starting to come together now!
In this post, updating the state to store expiration times + a thread to handle said eviction + the implementation of a small pile more of the general Redis functions.
Another Redis in Rust series. It’s really starting to come together now!
In this post, updating the state to store expiration times + a thread to handle said eviction + the implementation of a small pile more of the general Redis functions.
And I’m back. It’s been a busy month with the [Genuary]([Genuary 2023]) series and life in general, but I’m still thinking about Redis in general 😄.
Up this time, let’s see what the official redis-cli app does when talking to our client and actually start handling some commands. Specifically, the very basic commands: SET and GET. With that, we would actually have a (very very basic) keystore up and running!
Okay, we’ve got a server and we can ping it. Let’s actually make a simple client, so I don’t have to do funny things with echo any more. Specifically, let’s make a REPL!
Following up from Cloning Redis in Rust: RESP [Part 1], we can parse the protocol. So now… let’s do something with it.
The obvious(ish) next step, in my mind? Make a server. It’s all going to be over the network eventually, so it’s either here or storing data. Here it is!
Specifically, my goal is not to build the networking and data structures for this project from scratch. Where there are primitives or libraries that will do something like networking for me, I’m going to use them.
Ergo:
So, how do I write a simple server in Tokio?
Recently, I read through Build Your Own Redis with C/C++. C/C++ are ugly, so let’s run through it in Rust!
My goal: implement some large subset of Redis (both server and client) in Rust. For any features I implement, it should be compatible with Redis off the shelf. I should be able to use their client with my server and their server with my client and it should just work.
No idea if this is going to work out, but it sounds like an interesting problem!
First task: the REdis Serialization Protocol (RESP).
Another thing that came up recently: we have many (many) sidekiq queues. Each has their own admin interface, but sometimes you just want all of the information in one place. Of course, you could bookmark all of the pages. Or make a single page with a lot of frames (remember HTML frames?). Or use their API. But where’s the fun in that? Instead, let’s dig straight into the redis backend and see what we can see!
When you’re starting out on a simple web application, eventually1 you will reach the point where you need to store some form of persistant data. Basically, you have three options2:
There are all manner of pros and cons to each, in particular how easy they are to get started in, how well they fit the data you are using, and how well they will scale horizontally (adding more machines rather than bigger ones).