Redis as atomic distributed cache system

In a high available high throughput distributed system, atomicity of any of the CRUD operation is extremely critical. Any inconsistency could easily propagate and extremely difficult to trace when we are talking about 1m transactions per second.

While it is hard to imagine a single server can handle 1m transactions per second, it is not so hard when it comes to highly clustered microservices. Then the question arise how do we maintain awareness between each microservices. Ideally a microservice should be independent to another instance of itself, but there are edge cases whereby there is a need for all instances to be aware or share information to one another.

This sharing can be achieved using database, or MQ, or Redis. In this post I will be talking about Redis and how the Transaction in Redis works, and provide example of high throughput concurrent test that Redis manage to handle easily

Redis Transction

Transaction is rather unique in Redis and takes time to understand, Redis guarantees atomicity for all comamnds running in between MULTI and EXEC, but it doesn't give any output. Output is returned only after EXEC is run. Therefore when handling transaction in Redis, we will need to think about how to and when to execute commands differently, for example below is a POP function for HASH, since redis does not return values while in transaction, we need to GET and then DELETE to emulate a POP.


The Concurrency Test

The concurrency test is rather simple, 2 Spring Boot application looping 10,000 times sending a request of fakeId between fakeId0 to fakeId10. Once received in the server, the server will store the fakeId and its count of occurences in redis HASH.


After the loop, the test will sleep for 30s to give time for each other (2 Spring Boot apps) to complete their iterations before calling processRequest() which will POP the HASH set.


The Result


As we can see below, the result from both apps, one of them will print exactly 20000 entries while the other will have nothing. The most important take away here is that since both apps are executing the for loop at roughly the same time and as fast as the CPU can go, it creates a heaven like environment for concurrency problem. The fact that the final output is still 20000 instead of some other number suggested that Redis is extremely resillient when it comes to concurrency handling






Source code: https://github.com/overtakerx/redistransactiondemo

Comments

Post a Comment

Popular posts from this blog

Spring Boot 2: Parallelism with Spring WebFlux

Image
Spring Boot 2: Parallelism with Spring WebFlux Parallelism is rather unusual in Spring application, however when we encounter the need of HITLOL (HIgh Throughput LOw Latency), we need ways to make async calls. With Spring Boot 1, in high level definition, we can declare async on all the functions that are meant to be parallel and return Futures from there. Here is more detailed info:  https://medium.com/sipios/how-to-make-parallel-calls-in-java-springboot-application-and-how-to-test-them-dcc27318a0cf For Spring Boot 2, we shall employ Spring WebFlux libraries to accomplish parallelism. Mainly focused on functions: Mono.zipDelayError(), Mono.subscribeOn() and Mono.onErrorResume() The main function that drives the parallelism is zipDelayError(), the purpose of zipDelayError() as supposed to using zip() is to enable the other Monos to run to completion even if one Mono failed. AllDtos allDtos = Mono. zipDelayError (Arrays. asList (firstDto , secondDto , (Mono&l
Read more
Image
Implementing gRPC Using Spring Boot and Gradle Background GRPC (gRPC) is a RPC framework pioneered by google later on made public and open source. GRPC has not been officially supported by Spring Framework, so far there are few community libraries that can work seamlessly with Spring Boot. In this article, I will use the lognet's grpc-spring-boot-starter. Project Structure Ideally, the proto files for gRPC is located in another directory, which will then be accessed by the gradle plugin to auto generate the required files.   Gradle Script The heart of gRPC enablement lies on the grpc boot starter, which includes few other tasks outlined as below. https://github.com/overtakerx/grpcbootdemo/blob/main/build.gradle Few important note: first you have to run gradlew compileJava for the auto generation to generate the files from the proto file, then you will need to rebuild the project for Intellij to recognise the auto-generated files. Full demo: https://github.com/overtakerx/grpcbootdem
Read more

Cucumber + Junit5 + Localstack

Background What are the options to test an Amazon lambda that interacts with Dynamo DB locally? To be honest, there are several options, such as using Mockito, using stubs, swapping Dynamo DB with Mongo DB, however none of these truly replicate the amazon lambda and dynamo db ecosystem. Enter Localstack  ( https://github.com/localstack/localstack ), open source project that aims to emulate a local AWS cloud stack. With its docker version, we could spin up localstack and push our lambda and create our table in the dynamodb. To further increase its testing prowess, Localstack comes up with utils to integrate with Junit 4 and 5. Now we have the tools to create a BDD test using Cucumber, JUnit5 and Localstack as you can see below. Do note that due to the open source nature of localstack, it has several bugs that we manage to get around Prereq: Docker images: localstack/localstack:0.9.1 Note that the latest version of localstack docker image has bugs with the service port nu
Read more