Using the etcd Raft to Build Your First Cluster

<p>I sat down trying to learn the Raft algorithm and to implement it in the most basic and easy form as possible. Hopefully it might be interesting and helpful for someone else. <a href="http://otm.github.io/2015/05/raft-a-first-implementation/">http://otm.github.io/2015/05/raft-a-first-implementation/</a></p> <hr/>**评论：**<br/><br/>rco8786: <pre><p>Reading through, some initial comments:</p> <p>1) Show your includes! In this case it&#39;s probably pretty easy to figure out, but when you start using code from an external library but don&#39;t show what the library is it makes it quite hard to follow along.</p> <p>2) Along the same vein, toss a comment in when you&#39;re using a variable defined somewhere else. For instance, I have absolutely no idea what &#34;hb&#34; is(except that it&#39;s probably an integer) in the first code snippet.</p></pre>MrJamesCole: <pre><p>Thanks for your feedback. I have added includes and some comments. I thought something like &#34;hb&#34; would be OK, as it was defined in the same example code block and just a couple of lines before the first time it was used. </p> <p>The way I structured the code examples might not have been brilliant, I was trying to remove everything that was not essential in the code block in the blog post. and keeping the full code on Github. The reason was not to try to distract the reader while reading. However, it makes it hard to &#34;copy/paste&#34; code while reading, and it&#39;s easy to remove to much.</p></pre>c0p: <pre><p>You have context, so something like &#34;hb&#34; seems reasonable and straightforward. But to someone without context it means nothing. Code is read more often than it is written so choosing appropriate variable names is crucial to ensure that those reading do not need to spend extra mental cycles mapping short variable names. </p> <p>I haven&#39;t read your code yet, but I&#39;m guessing that something like &#34;heartbeat&#34; would&#39;ve been a better name choice. It&#39;s straightforward and conveys what is being stored in it. Plus all modern code editors do name completion, so there&#39;s no need to use short variables under the guise of saving key strokes :)</p></pre>conekt: <pre><p>Agreed. I don&#39;t even want to read it.</p></pre>akarl: <pre><p>FYI, your page layout on an iPad in landscape keeps recalculating the widths of the sidebar and content columns, making it impossible to read that way. In portrait the content column is so narrow as to make even your punch card-friendly code wrap, so the code becomes hard to read. Reader view doesn&#39;t even help, as the code comments are low contrast enough that reader view makes them white on white.</p></pre>MrJamesCole: <pre><p>Thanks for the heads up, I had not updated my theme in a while.</p></pre>michaelbironneau: <pre><p>Great article, really enjoyed reading it, thanks. One question: at the end, you access the node&#39;s pstore to verify that the entry has been committed. Can you do this without knowing about the underlying storage? eg. if I am a user of the system and I want some sort of acknowledgement that the message I <code>Propose()</code> has been committed (at least to the leader&#39;s journal), is that possible through the raft API? Or if not, how does one implement retry logic?</p></pre>MrJamesCole: <pre><p>You can generating a random ID and add it to the message that you want to propose to the cluster, and then wait until that ID is applied. Once the ID is applied on the node proposing the change you can assume it has been applied to the cluster. </p> <p>The random ID is never stored in the persistent storage just in the log. </p></pre>michaelbironneau: <pre><p>OK, thanks.</p></pre>