Rebuild

output/abstractions.html

@@ -60,7 +60,7 @@ <h1 style="color: white; background: #D82545; display: inline-block; padding: 6p
     <div id="main">
       <div id="content" class="post">
 <h1 id="-chapter_number-up-and-down-the-level-of-abstraction">2. Up and down the level of abstraction</h1>
-<p>In this chapter, we&#39;ll travel up and down the level of abstraction; look at some impossibility results (CAP and FLP) and then travel back down for the sake of performance.</p>
+<p>In this chapter, we&#39;ll travel up and down the level of abstraction, look at some impossibility results (CAP and FLP), and then travel back down for the sake of performance.</p>
 <p>If you&#39;ve done any programming, the idea of levels of abstraction is probably familiar to you. You&#39;ll always work at some level of abstraction, interface with a lower level layer through some API, and probably provide some higher-level API or user interface to your users. The seven-layer <a href="http://en.wikipedia.org/wiki/OSI_model">OSI model of computer networking</a> is a good example of this.</p>
 <p>Distributed programming is, I&#39;d assert, in large part dealing with consequences of distribution (duh!). That is, there is a tension between the reality that there are many nodes and with our desire for systems that &quot;work like a single system&quot;. That means finding a good abstraction that balances what is possible with what is understandable and performant.</p>
 <p>What do we mean when say X is more abstract than Y? First, that X does not introduce anything new or fundamentally different from Y. In fact, X may remove some aspects of Y or present them in a way that makes them more manageable.
@@ -191,7 +191,7 @@ <h2 id="the-cap-theorem">The CAP theorem</h2>
 <p>How can we work around this? By strengthening the assumptions (assume no partitions) or by weakening the guarantees. Consistency can be traded off against availability (and the related capabilities of offline accessibility and low latency). If &quot;consistency&quot; is defined as something less than &quot;all nodes see the same data at the same time&quot; then we can have both availability and some (weaker) consistency guarantee.</p>
 <p>Third, that <em>there is a tension between strong consistency and performance in normal operation</em>.</p>
 <p>Strong consistency / single-copy consistency requires that nodes communicate and agree on every operation. This results in high latency during normal operation.</p>
-<p>If you can live with a consistency model other than the classic one; a consistency model that allows replicas to lag or to diverge, then you can reduce latency during normal operation and maintain availability in the presence of partitions.</p>
+<p>If you can live with a consistency model other than the classic one, a consistency model that allows replicas to lag or to diverge, then you can reduce latency during normal operation and maintain availability in the presence of partitions.</p>
 <p>When fewer messages and fewer nodes are involved, an operation can complete faster. But the only way to accomplish that is to relax the guarantees: let some of the nodes be contacted less frequently, which means that nodes can contain old data.</p>
 <p>This also makes it possible for anomalies to occur. You are no longer guaranteed to get the most recent value. Depending on what kinds of guarantees are made, you might read a value that is older than expected, or even lose some updates.</p>
 <p>Fourth - and somewhat indirectly - that <em>if we do not want to give up availability during a network partition, then we need to explore whether consistency models other than strong consistency are workable for our purposes</em>.</p>

output/appendix.html

@@ -59,7 +59,7 @@ <h1 style="color: white; background: #D82545; display: inline-block; padding: 6p
 
     <div id="main">
       <div id="content" class="post">
-<h1 id="-chapter_number-further-reading-and-appendix">7. Further reading and appendix</h1>
+<h1 id="-chapter_number-further-reading-and-appendix">6. Further reading and appendix</h1>
 <p>If you&#39;ve made it this far, thank you.</p>
 <p>If you liked the book, follow me on <a href="https://github.com/mixu/">Github</a> (or <a href="http://twitter.com/mikitotakada">Twitter</a>). I love seeing that I&#39;ve had some kind of positive impact. &quot;Create more value than you capture&quot; and all that.</p>
 <p>Many many thanks to: logpath, alexras, globalcitizen, graue, frankshearar, roryokane, jpfuentes2, eeror, cmeiklejohn, stevenproctor eos2102 and steveloughran for their help! Of course, any mistakes and omissions that remain are my fault!</p>
@@ -99,7 +99,7 @@ <h3 id="systems">Systems</h3>
 <li><a href="http://scholar.google.com/scholar?q=Dynamo%3A+Amazon&#39;s+Highly+Available+Key-value+Store">Dynamo: Amazon’s Highly Available Key-value Store</a> - DeCandia et al.</li>
 <li><a href="http://research.google.com/archive/bigtable.html">Bigtable: A Distributed Storage System for Structured Data</a> - Chang et al.</li>
 <li><a href="http://research.google.com/archive/chubby.html">The Chubby Lock Service for Loosely-Coupled Distributed Systems</a> - Burrows</li>
-<li><a href="http://research.yahoo.com/pub/3280">ZooKeeper: Wait-free coordination for Internet-scale systems</a></li>
+<li><a href="http://www.usenix.org/event/usenix10/tech/full_papers/Hunt.pdf">ZooKeeper: Wait-free coordination for Internet-scale systems</a> - Hunt, Konar, Junqueira, Reed, 2010</li>
 </ul>
 
         </div>