You can also use state machines that coordinate themselves over time, regardless of drift - although, of course, this would be eventually consistent. Check out this (unfinished) article: https://github.com/amark/gun/wiki/Conflict-Resolution-with-G... .
The idea is to let computations proceed uncoordinated, build a dependency graph, and then "fix" computations that read stale information by re-executing them (like transactions, except retry is automatic and effects are undone after re-execution).
Yep! You can trace that thread back to Lamport's work some decades back.
The thing I find really compelling about this paper is that it's not tied to a single coordination method, though -- it pulls everything back to application level invariants. Human beings have a bad track record of reasoning about invariants in distributed systems, but computers are pretty good at that sort of thing... if we can specify our invariants explicitly, and let the machine figure out how exactly to spread that work out on the cluster, I think we'll come out far ahead.
5 comments
[ 2.4 ms ] story [ 21.9 ms ] threadhttp://research.microsoft.com/pubs/211297/onward14.pdf
The idea is to let computations proceed uncoordinated, build a dependency graph, and then "fix" computations that read stale information by re-executing them (like transactions, except retry is automatic and effects are undone after re-execution).
The thing I find really compelling about this paper is that it's not tied to a single coordination method, though -- it pulls everything back to application level invariants. Human beings have a bad track record of reasoning about invariants in distributed systems, but computers are pretty good at that sort of thing... if we can specify our invariants explicitly, and let the machine figure out how exactly to spread that work out on the cluster, I think we'll come out far ahead.