Hacker News new | past | comments | ask | show | jobs | submit login
Redis 2.8.0 stable is out (groups.google.com)
180 points by antirez on Nov 22, 2013 | hide | past | web | favorite | 58 comments

Redis is one of the few examples we have of truly beautiful software: A simple and elegant rock-solid performer that just works like water.

The updates over the years have been useful and has tastefully kept with the true spirit of Redis - thanks for all your hard work Salvatore!

I agree. There are a few other pieces of software I'd put in the same class... here's two examples I can think of now:

* Varnish (the "Notes from the architect" are a great read: https://www.varnish-cache.org/trac/wiki/ArchitectNotes)

* QEMU (actually, pretty much anything Fabrice Bellard has touched)

Great example! Wish I'd included it in my original list.

Tcl[1], which @antirez has also held up as incredibly lucid code.

[1] http://core.tcl.tk/tcl/timeline?y=ci

haproxy probably qualifies too.


zlib, lua & luajit


Thanks for the kind words mythz! And for your important role in the Redis community.

Couldn't agree more.

Redis code base is like a best-practice document.

The details on the Sentinel rewrite are very little as it is not strictly part of the 2.8 release, however here is a small summary of changes:

* Gossip is used as previously to detect if an instance is down.

* The Raft algorithm leader election step is performed to get elected to perform the failover.

* The Raft epoch of the election is used as a version of the new configuration.

* New configs are always broadcasted via Pub/Sub in the master and all the known slaves. So every Sentinel is listening for configs with an epoch that is greater than the current config, to update its view of the cluster.

* Now Sentinels try to force the cluster to have the setup of the latest config in memory (but with some delay to try to receive updates). So for instance slaves replicating with a wrong ip/port are reconfigured and so forth.

* Finally Sentinels persist their state on disk at every configuration update, or every time a new slave or sentinel is added to a master, so the system model is much more reasonable. Redis instances when reconfigured are sent a "CONFIG REWRITE" as well. TLDR: process restart friendly.

In general the code is now much simpler. The state, as you understand from the above description, is eventually consistent with a last-config-win semantics (where last means the configuration with the greater epoch).

oh -- so you _are_ going RAFT ? You initially dismissed it as too difficult... _very_ interesting (cool) choice.

I'm from ruby community where people, that made a gem, often feel like rockstar. I have known Antirez few months ago, he's a top hacker and great person

Most of the new updates in recent Redis releases are related to cluster and replication, I would like to see new commands and structure types.. I like the SCAN and MATCH...thanks for all hard work..love Redis..

Hello zerop, it is possible that eventually the API will get more open to improvements again. The idea at this stage is that we need more "maturity" features before to raise the complexity of the API.

However built in support for bloom filters and range queries in sorted sets are two random examples of things that could get implemented in the future.

Still Waiting for Cluster.

End of year for a beta. It is already working in all its parts, there is just to improve the details, and to document it, for a better user experience. Then we release the first RC and in the first Q of 2014 make sure the RC reaches production readiness.

I am grateful that you are your team are taking time to make sure the feature is production-ready, I would much rather wait for the feature to be solid than for you to release something half-done. Thanks for all you've done with Redis!

Thank you untothebreach, you are indeed completely right on not forcing the release schedule just for marketing or to stay on the edge, I'll follow your advice. The end-of-year move is just to provide a good end user experience to people willing to test the code in development environments, however before a stable release some more time will be needed, and "on the field" tests where I'll try to get Cluster working well in real world companies with non trivial Redis deployments. After this, the code will be released as production ready. Thanks!

For EOYear, will we get some more SDR love? A sequel to dump1090, perhaps? ;)

Would love to have the time! I look at my SDR hardware near my desk and would love to hack... After Redis 3.0 release I'll take something like a few weeks of break if possible to do some random hacking...

Just waiting? It is an open source project, you could always get in there and help it get done faster. In the meantime, why post a comment like this, ignoring all the amazing work that @antirez and the rest of the Redis team has done, just to whine about the one feature you want that they haven't finished yet?

"ignoring all the amazing work" "just to whine"

That is just how you put it. No where did i whine nor ignore the work the Redis Team did. Cluster being the one features that Redis will truly take off. As it currently isn't as popular as it should be.

Cluster support is mentioned in TFA so your comment is, at best, superfluous.

Just because it's open-source doesn't mean everyone has the skills and domain knowledge to contribute, I sure has hell couldn't. Otherwise I agree with your comment.

Yea, I realize that, but comments like the GP bring out the snark in me.

I'm terribly sorry in advance if this sounds dense, but what exactly do you use Redis for? I've been trying to work it out for some time... pointers to documentation would be fine :-)

A Cache, Session Store, Message Queue (RedisMQ), Distributed Pub/Sub Messaging, Locking (i.e. between AppServers), Rate Limiting, Analytics, Timings, etc.

Basically a swiss-army knife that you don't want to be without when developing high performance systems.

I saw a great picture from a slide deck. It had a picture of Batman labeled, "Your Application".

Then on the next slide, it added an arrow pointing at Batman's utility belt, and labeled it "Redis".

Mostly for the sweet spot between fast and pure-memory (e.g. Memcached) versus slower and high-integrity (e.g. MySQL). It works great for something like a page counter, where you want to write a lot, but don't care too much if you lost a few writes.

I know other people use it as their primary database or, on the other end of the spectrum, as an in-memory replacement...it can be configured optimally for those settings too.

You can pretty well use it for anything you want to use it for. It's persistent, networked shared memory.

It's powerful and flexible enough that I've used it as a primary datastore for the back-end to a web/multi-platform app/service. I don't necessarily recommend that, but it does work and is blazing fast and extremely reliable.

It's definitely some-assembly-required, though -- transactions aren't free, you have to do a little work yourself[1] (on the upside, you always know what it's doing).

Also, it is intended to be used with the entire dataset in RAM. You can let it swap to some extent, but... don't. If your dataset is huge, you need something else.

[1] Actually, this is less true post-2.6 with lua scripts. I should play with those more, the bulk of the code I wrote that uses Redis was built in the 2.0-2.2 timeframe.

Pretty much for anything that I want to store to a database but is too costly do to write every time I update. For example, I use Redis store counters for things and then batch process them storing to Postgres.

As a corollary, for what should I avoid using Redis?

I've heard wonderful things, but I've also heard that you can easily abuse Redis for things that aren't appropriate.

Data too large to fit in memory; anything that you're going to want to query relationally (as opposed to just key/value) in the future.

Not entirely true. Redis sets are quite powerful.

When you find yourself doing things too often you should be doing in a relational db (i.e. lots of foreign key relations).

Dashboards and aggregate data are a great use case for redis. Usually you have expensive calculations in these interfaces. Caching in redis is easy and really fast.

I use it as the only database in most of the projects I've work at my company, using Ohm [1] as our ORM. Usually we don't have use cases with ad hoc queries like `name LIKE '%Smith'`, so it serves our purposes very well. When we need something like that, we integrate with something like Elasticsearch.

[1] https://ohm.keyvalue.org/

Are you sure "ohm" web site is trustworthy?

I just got this

SSL connection error Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have.

It's not a certificate problem, I think somebody's misconfigured the server. It's listening on port 443, but not actually responding appropriately to TLS traffic.

I have this link handy when I want to get a very quick and general idea about all the different ones:


I use it for server-side sessions. Fits that use case well, especially on the performance side.

we used it to replace rabbitmq for our django->celery communication. rabbitmq had given us some configuration challenges, while redis just dropped in and worked out of the box.

One nice thing, too, is that you can keep the celery queue on a separate redis database in the same instance(s) -- to keep it separate from your other cache data. I like to keep my databases separate -- one for task queues, another for sessions, and another for truly persistent data. This makes some workflows very easy, like needing to invalidate all sessions or needing to purge transient cache data after deploying new code. Simply flush those databases.

Use it for handling high volume voting.

We use it for the job queue that our distributed workers interface with.

I used to use redis as a queue, but then I switched to beanstalkd:


That said I continue to use redis extensively, for storing data for dynamic websites (in preference to MySQL etc) and as a persistent cache for spam-testing, etc.

Seconded. I've used both for queuing, and once you start using beanstalkd, it feels like it's built for queuing. Redis can be given this role, but it's a bit more work (and back and forth).

This may have changed with Lua scripting in Redis since now more advanced operations are scriptable, but until I see some good examples, it's beanstalkd for me =].

short-term memory.

Keyspace change Notifications will be super useful. Sounds like a very promising feature. Also glad that they are working on Sentinel, I hope they release a stable version of that soon.

Indeed, I have been waiting for notifications upon key expiration for a while now, this looks awesome.

Thank you! Is there documentation related to using sentinel?

SCAN looks awesome!

A description of SCAN with the MATCH option (and related commands: HSCAN, SSCAN and ZSCAN): http://antirez.com/news/63

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact