Difference between revisions of "Distributed Consistency"

From MgmtWiki
Jump to: navigation, search
(Solutions)
(Problems)
Line 6: Line 6:
 
==Problems==
 
==Problems==
 
* Coordination is tricky to implements and expensive in terms of latency added.
 
* Coordination is tricky to implements and expensive in terms of latency added.
 +
* In spite of lack of coordination between system, we require that there be only a single outcome. That is that when a request for an identifier is completed, only one user will be permitted to use that identifier in a transaction.
  
 
==Solutions==
 
==Solutions==

Revision as of 15:32, 8 September 2020

Full Title or Meme

Distributed Consistency in Identity Management is required when more than one process might be assigning identifiers that are required to be unique.

Context

  • Decentralized Consistency is an easier problem when each Registration Authority is given control of a portion of a name space where it can control registration.
  • With the advent of fully distributed systems where any one machine could desire the ability to create an identifier, this problem needs a practical resolution.

Problems

  • Coordination is tricky to implements and expensive in terms of latency added.
  • In spite of lack of coordination between system, we require that there be only a single outcome. That is that when a request for an identifier is completed, only one user will be permitted to use that identifier in a transaction.

Solutions

  • THe first important way to avoid coordination is to change the architecture. If traffic is slow at in intersection, just build an overpass for one path and the problem goes away.
  • CALM[1] = Consistency As Logical Monotonicity is proven to the same as monotonicity. So if two sites chose the same identifier, only one will get to proceed to committing a transaction.
  • Google Spanner transactional database

References

  1. Joseph Hellerstein and Peter Alvaro, Keeping CALM: When Distributed Consistency is Easy (2020-09) CACM 63 no 3 pp. 72ff