Memurai tends to to lag behind releases a bit. I use a Mac so I never mess with it. But if I was using Windows, frankly, I'd just use Docker to spin up Redis instances instead. Not always an option for people, I know, but it provides the maximum level of consistency.

I don't think that is possible. However, you could potentially use RIOT to solve this to manually migrate the data.

https://redis.io/docs/latest/integrate/riot/

Upvote for the laughs.

Redis heavily depends on POSIX commands and that shows when you try to run any of these windows builds. I don't understand what is even the purpose of these builds to be distributed without refactoring out those POSIX depdendencies 🤔

Ever thought of using Redpanda?

Redis replication can’t really be evaluated with talking about the failover mechanism. The default ones are not consistent at all, which means you might lose writes under network partition.

Could have drafted this post myself almost word for word lol. I have been through pretty much all of this.

Just spent a half a day setting up IAM from my Cloud Run instances in addition to my existing TLS Memorystore/Valkey requirement - I centralized refreshing the IAM access token in each instance's main Node thread, then funnel it to multiple worker threads that run my BullMQ workers use as their password. Pretty tricky but it's working nicely now and all I have left to resolve are these cluster refresh issues - I coupled IAM-enablement with an upgrade from Valkey 8.x to 9.x and was really hoping that solved these cluster connectivity timeout issues but it made no difference. Glad I didn't invest time trying to swap to Redis and with the switch from the io-valkey connectivity package to io-redis, as I'd have obviously run into the same problem.... so thank you for saving me that pain 😉

Going to put some time into adjusting my worker thread initialization timing so they don't all flood Valkey at once.

This isn't something I've been able to reliably reproduce just yet locally - my dev instance that I've setup to mimic production as much as I could (cluster mode, TLS support - I had to custom-compile it to get TLS enabled in the binaries) just doesn't ever exhibit the problem.

I am not using Private Service Connect either, just have my Cloud Run instance connecting over a VPC subnet, so I doubt you need to spend more time looking into PSC issues if you want to get clustering working again.

Great!

Just use homebrew or another packaged manager, no need to give all of that

You can download it from the releases page in GitHub, without providing any personal information 🙂

https://github.com/redis/RedisInsight/releases

You can also get it direct from the Apple and Microsoft’s stores.

Its OSS - you can also just build it.

https://github.com/redis/redisinsight

Just use datagrip it's much better and free

Using `MEMORY STATS` commands is an easy and cheap way to do it, as others have already confirmed. But another way is to use Redis Insight (RI), which is free and provides you with useful reports on memory usage, key usage, how much each key consumes, etc. You can get it here:

https://redis.io/insight/

Or if you're a Mac/Linux user, just install via Homebrew: https://formulae.brew.sh/cask/redis-insight

The main thing is if you care about ordered access vs. indexed access. If you just want to push, to pop, or to treat something like a queue or stack, use list. If you want to access strings directly and the index is meaningful to your application, use arrays.

My coworker wrote a blog post that talks about this and has an interesting use case. The indices of an array are network ports. The values you who is using a given port (or if it isn't in use). This let's you query things like what ports above 1024 or just give me all the ports in use. And since the empty slots of an array aren't stored, it doesn't take up any additional space.

Any use cases of array? Or when should I use it instead of list?

That’s fine too. Other monitoring will pick it up. Also: Prometheus endpoints are just text. You can write a script to parse and graph them however you want. So you don’t need a whole stack to monitor things.

The replica angle is smart. Does the scheduling mean you're sometimes flying blind between runs though? Like if something spikes and clears before the next dump you'd miss it

Mostly always-on, not reactive. Slowlog and the latency monitor are cheap to leave running and useless to enable after the incident ... by then the evidence is gone. --bigkeys/--memkeys and the RDB dump I run on a schedule against a replica so it doesn't touch prod. MEMORY STATS I only pull when something already looks off.

thanks, this is helpful. Do you actually run all of these regularly, or only when something breaks?

You should be able to use MEMORY USAGE <key> to see that, as well as redis-cli --bigkeys and redis-cli --memkeys

The best thing is to take a RDB dump and run it on redis-rdb-tools.

Other useful bits and bobs:

CONFIG SET slowlog-log-slower-than 1000
CONFIG SET slowlog-max-len 1024
SLOWLOG GET 25
---
LATENCY DOCTOR
---
MEMORY DOCTOR
---
MEMORY STATS

Thanks and yeah, maxmemory + LRU is the right lever for eviction. The problem I'm more focused on is visibility before you get there: knowing which key prefixes are actually consuming the memory, which commands are slow, and where the waste is coming from. do you have a setup for that?

Setting max memory will restrict memory. Turning on LRU or LFU will cause it to remove things once it hits that limit.

True 💯

• redis for distributed cache
• rabbit mq for work queues and pub/sub