Redis MemoLock - Distributed Caching with Promises
Check out my talk at NDC Oslo 2019 where I showcase the C# implementation of redis-memolock!
A MemoLock is a form of distributed caching with promises. It's like memoization, but since the cache is shared by multiple consumers, each key has a locking mechanism that ensures that multiple concurrent requests for the same resource don't cause unnecessary work.
While I claim to have come up with the name, the concept is not new (as always), here you can read about Instagram having a similar concept in their architecture, and before them many others have approached the subject via r/w-through caches and other methods.
The implementations in this repository use Redis to cache values and Redis Pub/Sub to resolve promises across the network. Since Redis can be replicated and clustered, you can take this library up to any scale.
It works across different languages A client only needs a Redis client library and knowledge of the key naming scheme in use, and is able to generate/resolve promises with any other.
No polling or other wasteful patterns, and it can scale efficiently in a clustered deployment. This is something that Redis is in a unique position to provide.
It tries to ensure that useless work doesn't happen but, being part of a distributed system, there is no strong guarantee, as it would necessarily require much more coordination and, consequently, lead to lower scalability and lower ease of use. It tries to get a good tradeoff in that regard. Read more in later sections.
likes
for kristoff
(i.e. likes:kristoff
), we look for it in Redis.likes/lock:kristoff
using SET with NX.likes/notif:kristoff
likes/notif:kristoff
.This is a high level description of what redis-memolock does for you.
In practice, to get the concurrency right, there are a few more branches involved, but it has no impact on the public interface, so you only have to care about generating the content and handling time-outs.
This repository will soon contain a few different implementations that are able to cooperate (i.e. can generate and resolve promises one from another). While I aim for all implementations to be good enough to work in production (i.e. no concurrency bugs), the main goal is to write code that is clear and terse, so that anybody sufficiently motivated can make the right adjustments for their own use-cases.
Each implementation has its own README with code examples.
Inside the csharp
directory you will find a ASP.NET Core WebApi project containing usage examples and a MemoLock implementation that uses a System.Concurrent.Dictionary
with TaskCompletionSource
(manually triggered Tasks) to handle concurrency.
Inside the go/
directory you can find a Go module. This implementation makes good use of
goroutines and channels, and uses a single goroutine to write to the subscription multiplexer,
as opposed to the C# version which has concurrent writers acquire control of a ConcurrentDictionary
.
This library is all about nimble locking for enhancing performance. It's ok to use it in combination with external systems (e.g. store the result of the computation elsewhere, like a CDN if it's a PDF report, and just save in Redis a token representing the location) but it's NOT ok to use it to lock computations that rely on mutual exclusion for correctness. This locking mechanism is about doing less work, not correct work.
A good example is locking database reads: two reads at the same time won't cause any problem and the last writer will win.
A not-so-good example is trying to upload a file to an FTP server (or CDN) with a non-unique name: what happens if two writers try to write to the same filename? Answer: in reasonable implementations one writer will fail and report an error. Fix: make sure filenames generated by different writers can't collide (e.g. use UUIDs), or catch the error if you can distinguish it from other types of error (i.e. you get a FileAlreadyExistsError, and not a GenericOpenError).
A bad example is using a MemoLock to guard a computation that might be corrupted by concurrent writers. If your mistake is bad enough, you might end up in a situation where both writes succeed and the result becomes corrupted. Don't use this lock to do distributed transactions, for example. Fix: just don't.
I'm writing this warning because distributed locking is a complex subject and it's easy to misuse tools if you expect from them greater guarantees than they actually provide. As stated previously, this library tries to be lightweight to enhance performance, not guarantee full mutual exclusion. While not providing such functionality can be seen as a limitation, the upside is that such library would not be able scale as much (because of a higher level of coordination) and would not allow you to use services that are not Redis-aware to store results, such as a CDN, for example.
Enjoy the simplicity and flexibility that springs from limiting the scope of our design.
Here the term promise is used in a fairly abstract way with only a small connection to any specific language implementation. Different implementations can interoperate because they share a Redis client and the understanding of three concepts:
<resource tag>:<resource id>
likes:kristoff
)<resource tag>/lock:<resource id>
likes/lock:kristoff
)<resource tag>/notif:<resource id>
likes/notif:kristoff
)Any client that can SET
and GET
a key, and that can use Pub/Sub, can interoperate transparently with all others.