Hello,

Redis uses asynchronous replication, in order to have a latency you expect for most use cases where Redis is used, however after the tests Aphyr performed we tried to improve what was possible to improve without transforming Redis into something completely different. Basically even with asynchronous replication and a drastic merge function (last failover wins), you can still do things to improve the real world behavior of the system, and this is what we did:

1) Improve Redis master-slave protocol in order to have asynchronous acknowledges, at least. So it is now possible, during partitions, to have a bound data loss: after some time the isolated master stops accepting writes. This is implemented both in Redis Cluster (natively) and in Redis vanilla replication (so can be used with Sentinel or other failover mechanisms).

2) Use a replication offset in order to try, during failovers, to pick the slave with the most updated state.

Currently it is just an idea but in the future for certain data types and operations, Redis Cluster may take a log of the operations that were not acknowledged by all the slaves of a given master, and when the master is turned into a slave, it would re-play the log into the new master, at least for operations which are idempotent and commutative. This would allow for safer writes. The other (more used) approach of merging values directly is not very easy to perform with Redis for a number of reasons.

That post was a bit before the new redis clustering in 3.0 (http://antirez.com/news/79 -- Redis cluster, no longer vaporware). Wonder if anything has changed.

Aside from the fact that Aphyr showed basic replication to be flawed, as far as I know Cluster isn't even designed to be consistent across partitions.

The announcement page you linked to doesn't let me copy any text on iOS, but he's basically saying that if you get a partition and resolve it, the merge algorithm used is prone to data loss.

I don't know if Redis Cluster has improved since.