Fossil SCM
Small tweaks to the CAP Theorem doc
Commit
67a4c1d3134784dffed4ddae84a3ef55663025f6b886cb3fbdb86dc7bba018bb
Parent
ab71d95a9f32636…
1 file changed
+15
-6
+15
-6
| --- www/cap-theorem.md | ||
| +++ www/cap-theorem.md | ||
| @@ -25,11 +25,15 @@ | ||
| 25 | 25 | time. |
| 26 | 26 | |
| 27 | 27 | You may consider that going back online restores “C”, because upon sync, |
| 28 | 28 | you’re now consistent with the repo you cloned from. But, if another |
| 29 | 29 | user has gone offline in the meantime, and they’ve made commits to their |
| 30 | -disconnected repo, *you* aren’t consistent with *them.* | |
| 30 | +disconnected repo, *you* aren’t consistent with *them.* Besides which, | |
| 31 | +if another user commits to the central repo, that doesn’t push the | |
| 32 | +change down to you automatically: even if all users of a Fossil system | |
| 33 | +are online at the same instant, and they’re all using autosync, Fossil | |
| 34 | +doesn’t guarantee consistency across the network. | |
| 31 | 35 | |
| 32 | 36 | There’s no getting around the CAP theorem! |
| 33 | 37 | |
| 34 | 38 | [dvcs]: https://en.wikipedia.org/wiki/Distributed_version_control |
| 35 | 39 | |
| @@ -41,22 +45,27 @@ | ||
| 41 | 45 | |
| 42 | 46 | It means we get a system that is always consistent (C) and available (A) |
| 43 | 47 | as long as there are no partitions (P). |
| 44 | 48 | |
| 45 | 49 | That’s basically [CVS] and [Subversion][svn]: you can only continue |
| 46 | -working as long as your connection to the central repo server functions. | |
| 50 | +working with the repository itself as long as your connection to the central repo server functions. | |
| 47 | 51 | |
| 48 | -It’s rather trivial to talk about single-point-of-failure systems as | |
| 52 | +It’s rather trivial to talk about single-point-of-failure systems like | |
| 53 | +CVS or Subversion as | |
| 49 | 54 | CA-mode. Another common example used this way is a classical RDBMS, but |
| 50 | 55 | aren’t we here to talk about distributed systems? What’s a good example |
| 51 | 56 | of a *distributed* CA-mode system? |
| 52 | 57 | |
| 53 | 58 | A better example is [Kafka], which in its default configuration assumes |
| 54 | 59 | it being run on a corporate LAN in a single data center, so network |
| 55 | -partitions are exceedingly rare. In its application of CA mode, a | |
| 60 | +partitions are exceedingly rare. It therefore sacrifices partition | |
| 61 | +tolerance to get the advantages of CA-mode operation. In its particular application of | |
| 62 | +this mode, a | |
| 56 | 63 | message isn’t “committed” until all running brokers have a copy of it, |
| 57 | -at which point the message becomes visible to the client(s). | |
| 64 | +at which point the message becomes visible to the client(s). In that | |
| 65 | +way, all clients always see the same message store as long as all of the | |
| 66 | +Kafka servers are up and communicating. | |
| 58 | 67 | |
| 59 | 68 | How would that work in Fossil terms? |
| 60 | 69 | |
| 61 | 70 | If there is only one central server and I clone it on my local laptop, |
| 62 | 71 | then CA mode means I can only commit if the remote Fossil is available, |
| @@ -88,11 +97,11 @@ | ||
| 88 | 97 | say that commits must go to all of the spares as well as the active |
| 89 | 98 | servers, but a loss of one active server requires that one warm spare |
| 90 | 99 | come into active state, and all of the clients learn that the spare is |
| 91 | 100 | now considered “active.” At this point, you have a CP-mode system, not a |
| 92 | 101 | CA-mode system, because it’s now partition-tolerant (P) but it becomes |
| 93 | -unavailable, losing “A” when there aren’t enough active servers or warm | |
| 102 | +unavailable when there aren’t enough active servers or warm | |
| 94 | 103 | spares to promote to active status. |
| 95 | 104 | |
| 96 | 105 | CP is your classical [BFT] style distributed consensus system, where the |
| 97 | 106 | system is available only if the client can contact a *majority* of the |
| 98 | 107 | servers. This is a formalization of the warm spare concept above: with |
| 99 | 108 |
| --- www/cap-theorem.md | |
| +++ www/cap-theorem.md | |
| @@ -25,11 +25,15 @@ | |
| 25 | time. |
| 26 | |
| 27 | You may consider that going back online restores “C”, because upon sync, |
| 28 | you’re now consistent with the repo you cloned from. But, if another |
| 29 | user has gone offline in the meantime, and they’ve made commits to their |
| 30 | disconnected repo, *you* aren’t consistent with *them.* |
| 31 | |
| 32 | There’s no getting around the CAP theorem! |
| 33 | |
| 34 | [dvcs]: https://en.wikipedia.org/wiki/Distributed_version_control |
| 35 | |
| @@ -41,22 +45,27 @@ | |
| 41 | |
| 42 | It means we get a system that is always consistent (C) and available (A) |
| 43 | as long as there are no partitions (P). |
| 44 | |
| 45 | That’s basically [CVS] and [Subversion][svn]: you can only continue |
| 46 | working as long as your connection to the central repo server functions. |
| 47 | |
| 48 | It’s rather trivial to talk about single-point-of-failure systems as |
| 49 | CA-mode. Another common example used this way is a classical RDBMS, but |
| 50 | aren’t we here to talk about distributed systems? What’s a good example |
| 51 | of a *distributed* CA-mode system? |
| 52 | |
| 53 | A better example is [Kafka], which in its default configuration assumes |
| 54 | it being run on a corporate LAN in a single data center, so network |
| 55 | partitions are exceedingly rare. In its application of CA mode, a |
| 56 | message isn’t “committed” until all running brokers have a copy of it, |
| 57 | at which point the message becomes visible to the client(s). |
| 58 | |
| 59 | How would that work in Fossil terms? |
| 60 | |
| 61 | If there is only one central server and I clone it on my local laptop, |
| 62 | then CA mode means I can only commit if the remote Fossil is available, |
| @@ -88,11 +97,11 @@ | |
| 88 | say that commits must go to all of the spares as well as the active |
| 89 | servers, but a loss of one active server requires that one warm spare |
| 90 | come into active state, and all of the clients learn that the spare is |
| 91 | now considered “active.” At this point, you have a CP-mode system, not a |
| 92 | CA-mode system, because it’s now partition-tolerant (P) but it becomes |
| 93 | unavailable, losing “A” when there aren’t enough active servers or warm |
| 94 | spares to promote to active status. |
| 95 | |
| 96 | CP is your classical [BFT] style distributed consensus system, where the |
| 97 | system is available only if the client can contact a *majority* of the |
| 98 | servers. This is a formalization of the warm spare concept above: with |
| 99 |
| --- www/cap-theorem.md | |
| +++ www/cap-theorem.md | |
| @@ -25,11 +25,15 @@ | |
| 25 | time. |
| 26 | |
| 27 | You may consider that going back online restores “C”, because upon sync, |
| 28 | you’re now consistent with the repo you cloned from. But, if another |
| 29 | user has gone offline in the meantime, and they’ve made commits to their |
| 30 | disconnected repo, *you* aren’t consistent with *them.* Besides which, |
| 31 | if another user commits to the central repo, that doesn’t push the |
| 32 | change down to you automatically: even if all users of a Fossil system |
| 33 | are online at the same instant, and they’re all using autosync, Fossil |
| 34 | doesn’t guarantee consistency across the network. |
| 35 | |
| 36 | There’s no getting around the CAP theorem! |
| 37 | |
| 38 | [dvcs]: https://en.wikipedia.org/wiki/Distributed_version_control |
| 39 | |
| @@ -41,22 +45,27 @@ | |
| 45 | |
| 46 | It means we get a system that is always consistent (C) and available (A) |
| 47 | as long as there are no partitions (P). |
| 48 | |
| 49 | That’s basically [CVS] and [Subversion][svn]: you can only continue |
| 50 | working with the repository itself as long as your connection to the central repo server functions. |
| 51 | |
| 52 | It’s rather trivial to talk about single-point-of-failure systems like |
| 53 | CVS or Subversion as |
| 54 | CA-mode. Another common example used this way is a classical RDBMS, but |
| 55 | aren’t we here to talk about distributed systems? What’s a good example |
| 56 | of a *distributed* CA-mode system? |
| 57 | |
| 58 | A better example is [Kafka], which in its default configuration assumes |
| 59 | it being run on a corporate LAN in a single data center, so network |
| 60 | partitions are exceedingly rare. It therefore sacrifices partition |
| 61 | tolerance to get the advantages of CA-mode operation. In its particular application of |
| 62 | this mode, a |
| 63 | message isn’t “committed” until all running brokers have a copy of it, |
| 64 | at which point the message becomes visible to the client(s). In that |
| 65 | way, all clients always see the same message store as long as all of the |
| 66 | Kafka servers are up and communicating. |
| 67 | |
| 68 | How would that work in Fossil terms? |
| 69 | |
| 70 | If there is only one central server and I clone it on my local laptop, |
| 71 | then CA mode means I can only commit if the remote Fossil is available, |
| @@ -88,11 +97,11 @@ | |
| 97 | say that commits must go to all of the spares as well as the active |
| 98 | servers, but a loss of one active server requires that one warm spare |
| 99 | come into active state, and all of the clients learn that the spare is |
| 100 | now considered “active.” At this point, you have a CP-mode system, not a |
| 101 | CA-mode system, because it’s now partition-tolerant (P) but it becomes |
| 102 | unavailable when there aren’t enough active servers or warm |
| 103 | spares to promote to active status. |
| 104 | |
| 105 | CP is your classical [BFT] style distributed consensus system, where the |
| 106 | system is available only if the client can contact a *majority* of the |
| 107 | servers. This is a formalization of the warm spare concept above: with |
| 108 |