LCR算法是基于环的经典 Leader Election 算法。这个算法可以用来在一堆集群节点中推举出一个老大，推举依据可以是“随便哪个都行”，也可以是在某种规则下“最好”的那个节点，比如接收的订单数最多等等。
算法本身不要求进程总数N对于每个节点已知。但对我的实际需求而言这一点可以放宽
算法的前提：
1) 最多存在N个节点，存活的节点顺时针构成一个逻辑的环。每个节点都知道自己在环上的初始位置号id(0到N-1)
2) 节点可能失效。失效的节点将完全停机。节点id失效后，将从逻辑环中剔除之，并顺时针重构逻辑环
3) 任意两个节点之间都存在至少两条完全独立的通信链路，且通信链路不存在双点以上的故障，因此任意两个节点之间总是连通的。
4) 每个节点有一个唯一的UID，UID只要求互不相同。UID不一定就是节点在环上的初始位置号id，但就实用而言，我建议用 id 加上比如 “接收的订单数”，组合成一个唯一的UID。这样的 UID越大，就越”好“。
就算法的细节而言有很多版本或变体。就我的实际需求而言，我需要一个能够在全体存活节点中推选出最好节点的版本。因此算法是这样的（算法中的 leader_id, my_id 指的都是 UID, 而 UID 里面可以截取出节点号 id )
在此版本下，算法的启动是由少数已发现当前 LEADER 失效的节点通过超时发起的，但最终全部存活节点都会参与选举。
LCR算法比起 LeLann 最早的算法要容易理解得多，后者的原始论文看起来是一个噩梦，亏计算机科学家们居然将其整理成了容易理解的伪代码形式！
如果在选举过程中没有任何节点失效，那么算法的正确性是很容易看出来的。
节点失效有两个后果：节点不能继续执行上述逻辑，和丢失节点收到但尚未来得及发出的信息。
1） 若失效的节点集合里面不包括本来最好的节点M
1.1) 若M发出的信息没有因失效节点而丢弃
M选举成功，未受到影响
1.2) 若M发出的信息被失效节点丢弃
M虽然最好但暂时不能被选上；因为M的存在其他节点也不可能被选上；必须由M节点的超时机制触发下一次 TOKEN发送，最后仍然可以选上M
2) 若失效的节点集合里面包括本来最好的节点M。存活节点里面最好的节点是N
2.1) 若M发出的信息没有被失效节点丢弃
这个TOKEN可以遍历全部节点，但无法碰到发出方M，因此将一直循环，
N发出的TOKEN如果在M完蛋前碰到过M，则N也不能被选上，也没有其他存活节点可以选上（因为他们比N差），最终超时机制将触发下一次选举，使得N选上
N发出的TOKEN 如果在M完蛋前没有碰到过M，则本次N就可以选上
2.2) 若M发出的信息已经被失效节点丢弃
N发出的TOKEN如果在M完蛋前碰到过M，则N也不能被选上，也没有其他存活节点可以选上（因为他们比N差），最终超时机制将触发下一次选举，使得N选上
N发出的TOKEN 如果在M完蛋前没有碰到过M，则本次N就可以选上
因此在 fail-and-stop 的失效模式，以及双网的前提下，本算法是可靠的。
如果之前主节点备份了充分多的从节点，则可以抗击2点乃至多点的节点故障。
指出这一点的文章非常少，因此在这里写出来。