There are, as of this writing, about 15 distinct operations available to someone wanting to work with sets in redis. This article seeks to cover some of the more basic ones using a reactive lettuce client, and a follow up article will seek to deal with explaining some of the more common operations against multiple sets, rather than a single set in this case.
There are about 15 or so commands you can execute against redis for hash types as of this writing. This article will demonstrate some of the more common operations you’re likely to need when using lettuce as your client.
As of this writing, there are a solid twenty or so commands you can execute against redis for the list data type. This article will be walking through some of the more common operations you are likely to need when interacting with redis and lists using lettuce, and the source code can be found on Github.
The source code for what follows can be found on Github.
There are, as of this writing, 27 different string operations available in the redis API. Lettuce appears to have interfaces that directly support all of them.
In clustered redis, any non hash tagged key can be sent unpredictably [well, actually predictably, if you know the formula] to any given primary node in the cluster. The very basic way it works is:
To follow along with this post, it would be best if you have already set up your local redis cluster and know how to connect to a redis cluster and interact with it via Lettuce. And the source code for what follows can be found on Github.
Lettuce has some pretty nice out of the box support for working with clustered redis. This combination–a reactive client and application along with clustered redis–is about as scalable, performant, and resilient as things can get in distributed systems [though there are other tradeoffs which are not the subject of this post].
The source code for this post can be found on Github.
Lettuce supports reading from redis replicas, but with the caveat that it doesn’t [out of the box] provide you with the fine-grained control over when to read from the replicas that you’re likely to want.
The source code for this post can be found on Github.
In a previous post, we detailed how to write integration tests for lettuce clients in spring boot webflux using a redis test container. That’s fine and well when you’re just writing code for a quick feedback loop, but is useless when it comes to running the application in real life. This post will start up redis locally and then explain how to best connect to it using lettuce in webflux.
The source code for this post can be found on Github.
Another way to write integration tests for code that verifies your interactions with redis actually make sense is to use a test container. This framework assumes you have docker up and running, but if you do it will pull a specified container image [typically you’ll just use docker hub, though it’s important to note that they rate limit you, so don’t go overboard], then you can interact with that container in your integration tests.
The source code for this article can be found on Github.
Lettuce is a redis client with reactive support. There is a super handy embedded redis for java project out there, and this kind of integration testing inside your service is worth its weight in gold, in my humble opinion. This post will detail how to merge both of these worlds together, and set up redis integration tests when you’re using a lettuce client.
A Reactor Mono comes with a lot of methods that allow you to do things when errors occur:
