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.
When you update an item in DynamoDB, you can optionally update the item in place. That is, instead of read-increment-write, you can just issue a command that says increment this value in place. This behavior is detailed in the AWS documentation, and I will provide an example for how to do so with the Java AWS SDK 2.0, which has full reactive support.
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:
Leveraging Mono.zip appropriately will [with the right configuration] lead to a high amount of performance and concurrency. There is one caveat to its usage though:
There’s a very insidious bug that can happen when you’re writing reactive code, and it basically comes down to whether an underlying Mono in a chain of operations was actually subscribed to, rather than merely observing a method invocation. I’ll demonstrate with an example.
