the model tested here was again nothing planned to be implemented, just a model to show that WAIT is just a low-level primitive, and the real behavior of the system is determined by all the parts of the system, not WAIT per se.
Redis Cluster is not going to be a strongly consistent system, I'm not going to be tricked into designing something is not good for the Redis Community in my opinion. However Redis Cluster tries with heuristics to put bounds on how much a replica can diverge, and to pick the history that makes more sense when a slave is promoted.
Btw, about the Aphyr post, 13 days ago I wrote in the Redis mailing list the following message in reply to him:
---
About non linearizability, perhaps it does not apply to the case where
a strong coordinator exists, but in the general case one issue is that
when we read, we can't just read because a stale master could reply
with stale data, breaking linearizability. There is a trick to force
the read to be acknowledged that could work:
MULTI
INCR somecounter
GET data
EXEC
WAIT <n>
---
The fact you can't read from the master without care is a very obvious and well understood problem in distributed systems. Even a DS newbie like me was able to spot that in 5 minutes during the mailing list thread :-)
While I think the atmosphere could be a lot more co-operative and cordial, I think a lot of good work has been done anyway. The post may have attacked a straw man view that you've already discarded, but there's no denying that everyone's gotten a potentially very useful tool out of it :D
This is personal opinion, of course, but I think Redis would be better served by not striving to make formal guarantees of any sort. Instead it could continue to provide primitives while staying fast and stable. Heuristics should be acceptable and gradually improved as more approaches become feasible. This seems to be the approach being taken right now - I'm hoping you and everyone else can let that be.
the model tested here was again nothing planned to be implemented, just a model to show that WAIT is just a low-level primitive, and the real behavior of the system is determined by all the parts of the system, not WAIT per se.
Redis Cluster is not going to be a strongly consistent system, I'm not going to be tricked into designing something is not good for the Redis Community in my opinion. However Redis Cluster tries with heuristics to put bounds on how much a replica can diverge, and to pick the history that makes more sense when a slave is promoted.
Btw, about the Aphyr post, 13 days ago I wrote in the Redis mailing list the following message in reply to him:
---
About non linearizability, perhaps it does not apply to the case where a strong coordinator exists, but in the general case one issue is that when we read, we can't just read because a stale master could reply with stale data, breaking linearizability. There is a trick to force the read to be acknowledged that could work:
---The fact you can't read from the master without care is a very obvious and well understood problem in distributed systems. Even a DS newbie like me was able to spot that in 5 minutes during the mailing list thread :-)