[deleted]
The End of the Redis Adventure
261–270 of 308 posts
Re: The End of the Redis Adventure
#262Ok, so many thank you here, thanks! It's very nice to read the comments here. But I hope to interact more on HN, since basically the idea is to write more blog posts, write more OSS software too. Just totally random :D I'll just do whatever every morning I want to do for a long time. Then maybe I'll find a new long term interest.
Thanks for putting so much effort into Redis! The software itself is awesome (I've been using it one way or another over the span of nearly a decade now), and in my opinion anyway you've handled the project and yourself in an exemplary way. You're the only programmer I can really say I think of as a personal hero. Best of luck in the future!
Re: The End of the Redis Adventure
#263Ok, so many thank you here, thanks! It's very nice to read the comments here. But I hope to interact more on HN, since basically the idea is to write more blog posts, write more OSS software too. Just totally random :D I'll just do whatever every morning I want to do for a long time. Then maybe I'll find a new long term interest.
I became a sponsor of yours on Github today just to say, "thanks." I know it's not much, but I really do appreciate your work. Hopefully, my small donation will add up some worthwhile coffee overtime!
Re: The End of the Redis Adventure
#264Earlier quoted context omitted.
It didn't really start as a volatile cache, it started as an in memory data structures server. It's useful for all kinds of stuff memcached isn't (and has been since day 1).
It started as a memcached with persistence to disk for fast startup.
No, it was always about data structures.
Lists, hashes, sets and such that you have available in your programming language, but available as a networked server so any language/app/process can access the same data using the same useful structures.
Re: The End of the Redis Adventure
#265Earlier quoted context omitted.
> but I've now seen it also used as a message bus It works excellent as a message bus, though. And you can add HSET/HDEL to your list as the fourth way.
Strongly, strongly, disagree that Redis works well as a message bus. Lots of reasons why but here is just one because I'm short on time: all of these (four) ways of doing a message bus with Redis offer either a work queue mode or publish/subscribe - but not both (perhaps excepting streams which I've forgotten some of the details of). I have yet to see many real world messaging scenarios where you don't end up using b…
Name of the hash is a topic. Keys are nanosecond timestamps, values are the packets. You put in the data, you send a pub notify to the listener, listener goes and drains the queue. It acts as a direct exchange queue, recovers fine from a restart and it works wonderfully. For fanout, you can simply use pub sub. For topical, you can keep a list of direct exchange queue hashes. I haven't needed it.
Re: The End of the Redis Adventure
#266Ok, so many thank you here, thanks! It's very nice to read the comments here. But I hope to interact more on HN, since basically the idea is to write more blog posts, write more OSS software too. Just totally random :D I'll just do whatever every morning I want to do for a long time. Then maybe I'll find a new long term interest.
Thank you antirez! I've used your remote dictionary server from the earliest days and it has been a staple of my tool chest ever since. Three cheers and enjoy your time doing whatever it is you want to do!
Re: The End of the Redis Adventure
#267Earlier quoted context omitted.
I think its website need a fast cache.
Actually the web site uses Redis as the only store. And Redis is using 0.1% of CPU. The problem is that Ruby sucks at doing anything scalable. It's just a Ruby/Sinatra app. If you do that in PHP, it will work out of the box with many concurrent accesses. With Ruby not the case. There are ways to deploy it better, but it should be fast as default, which is not the case.
NGINX supports Lua scripting. Many years ago I worked on a system which ran a full website on NGINX + Lua + Redis.
Re: The End of the Redis Adventure
#268Earlier quoted context omitted.
Hello Salvatore, I normally don't write about what I come across during my work, but in aggregate I can tell you that Redis, Linux and MySQL are the most common recurring elements across 150+ jobs looking at different companies, and using it rarely if ever leads to trouble. So even if I don't use it myself directly quite a few of the companies we have invested in do, and an indirect 'thank you so much' is well deserv…
As someone who was in ops, I really disagree with MySQL in that category. Saw it multiple times at multiple jobs just break on its own. Most memorable one was a bug where certain pattern of data caused mysql think data is encrypted, crash and refused to start until data was restored from backup. It took quite time to fix it because it happened randomly and initially we assumed it was broken hardware.
MySQL used to be pretty bad in that respect but lately has come of age and I was mostly commenting on how frequently it was used.
Re: The End of the Redis Adventure
#269Thank you for your amazing work. Redis has been by far the most dependable component of my tech stack and it's opened up a whole new way of thinking about data.
Best of luck in your future endeavors!
Re: The End of the Redis Adventure
#270Earlier quoted context omitted.
> but I've now seen it also used as a message bus It works excellent as a message bus, though. And you can add HSET/HDEL to your list as the fourth way.
Strongly, strongly, disagree that Redis works well as a message bus. Lots of reasons why but here is just one because I'm short on time: all of these (four) ways of doing a message bus with Redis offer either a work queue mode or publish/subscribe - but not both (perhaps excepting streams which I've forgotten some of the details of). I have yet to see many real world messaging scenarios where you don't end up using b…
There's a wide field of messaging from distributed logs to queuing systems to event sourcing to complex service buses. Kafka, Pulsar, NATS, RabbitMQ, Tibco, NServiceBus, ActiveMQ, Solace, AMPS, and dozens more. What's "proper" depends on your needs.
Redis Streams actually does exactly what you describe and is basically a single-node fast Kafka replacement with multiple independent consumer groups, per-message acknowledgements, and queue semantics. We use it successfully in many high-load scenarios.