50 years later, is two-phase locking the best we can do?
I'm a beginner in this topic and I find this topic interesting. I really want there to be an easy-to-deploy consistency solution.<p>If I have a distributed microservice architecture and I want to keep multiple datastores in synchronization or "consistent" what's the industry best practice?<p>A few days ago I was trying to solve the inconsistency problem with "settled timestamps" which is a kind of multiversioning idea except that timestamps elapsed with the absence of reported error represent a valid save/commit. Kind of like two phase commit with the second phase being time. The idea is that we watch the clocks of other servers and if they don't update then we know we cannot trust their settled timestamps. (My intent was to allow scaling consistency across many servers, because we don't need to wait for response for every update, we only need to wait for the next timestamp interval)<p>Here's my Multithreaded multiprocessing Python code to test indeterminancy. 10 threads all send eachother random updates. They also broadcast their own timestamp and the timestamps of their own perspective of the timestamps every other server.<p><a href="https://replit.com/@Chronological/InconsistencySimulation#main.py">https://replit.com/@Chronological/InconsistencySimulation#ma...</a>
(click Run and watch the output, you'll have to wait 10 seconds)<p>A read in this simulation is the MIN of all timestamps of all servers reported timestamps.<p>10 seconds into the simulation, we ask every thread for its own perspective of what the counter value is. Sometimes they will all report the same value, a lot of the time they shall be split brained.<p>I am aware that wall clock timestamps are not suitable for ordering in a distributed system and that logical or vector clocks should be used for ordering.<p>If you can get the simulation to all report the same number at any point in time, then that would be great :-)<p>Ordering in distributed systems is significant, as the eventual consistency of the simulation means that some values can arrive late but affect the value, meaning it is not linearizable. Bloomlang tries to solve this.<p>I'm specifically interested in scaling WITH consistency but I think this is quite difficult.