alt Hacker NewsRedis 8.8: New array data structure, rate limiter, performance improvements
Comments
While I love Redis as a versatile tool for external data structures, it's still lacking in two areas IMHO:
One, it would be cool to be able to embed it, similar to sqlite, directly into applications.
Two, the HA story is so much more complicated than it should be. I totally acknowledge that concurrency and distributed computing is hard, but it should not require reading heaps of documentation and understanding two entirely separate multi-node approaches only to figure out there are lots of subtle strings attached that make it impractical for many applications.
Where did everyone end up on the Redis/Valkey split? Is there still a reason to use Redis after the license kerfuffle?
Are we still using Redis? License change, no more Kube operators.
There's also a separate blog post that goes into the details of why existing data structures Redis already supported, which could provide array-like behavior, weren't good enough:
https://redis.io/blog/diving-deep-into-rediss-new-array-data...
given his ds4 project, likely collaborated with DeepSeek for this release:
window counter rate limiter!
This is awesome!
And arrays look great too. Lots to play with.
[dead]
And here we see the reason for the sudden AI enthusiasm of Redis authors: array data structures are used in AI. This was clear weeks ago.
The website looks like openclaw's website.
> Rate limiting is one of the most common Redis use cases. Traditionally, users implemented rate limiters using server-side Lua scripts combined with client logic. In Redis 8.8, we introduce a window counter rate limiter (by @raffertyyu, together with the Redis team).
I had a look for this and it turns out it's slightly mis-described there - it's not a window counter, it's a "GCRA (Generic Cell Rate Algorithm)" - a leaky bucket algorithm. Code here: https://github.com/redis/redis/blob/unstable/src/gcra.c
The code comments say it was heavily influenced by https://github.com/brandur/redis-cell by Brandur Leach.
It's a neat algorithm (I just learned about it today) - it only needs to store a single integer for each rate-limited key, which is the "Theoretical Arrival Time" when the bucket would next be empty.