tcn760的博客

Raft算法中的领导者是有任期的，每个任期由单调递增的数字表示。**跟随者在等待领导者心跳信息超时后，推荐自己为候选人时，会增加自己的任期号。**比如节点 A 的当前任期编号为 0，那么在推举自己为候选人时，会将自己的任期编号增加为 1。**如果一个服务器节点，发现自己的任期编号比其他节点小，那么它会更新自己的编号到较大的编号值。

当节点A、B收到提案编号为9的准备请求的时候，因为提案编号9大于之前响应的准备请求的提案编号5，并且这两个节点已经通过了之前的提案[5,7]，接受者A、B会在准备请求的响应中，包含已经通过的最大编号的提案信息[5,7]，并承诺以后不再响应提案编号小于9，不会通过编号小于9的提案；当客户端3收到大多数的接受者的准备请求后（节点A、B和C），根据响应中提案编号最大的提案的值，来设置请求的值，即来自A、B节点的准备响应的提案[5,7]。因此就把A、B响应值7作为提案的值，发送接受请求[9,7]。

实际上，绝大部分场景对一致性要求没那么高，短暂的不一致是能接受的，另外，也基于可用性和并发性能的考虑，在开发实现分布式系统，如果不是必须，尽量不要实现事务，可以考虑采用最终一致性。首先节点A按照要么全部执行，要么全部放弃的原则，统计回复结果，由于所有的回复结果都是能够执行，所以节点A决定执行分布式事务操作X。为了实现一致性，确认操作和补偿操作必须是幂等的。TCC不依赖于数据库的事务（2pc应该是要依赖的），而是在业务中实现了分布式事务，这能减轻数据库的压力，但对业务代码的入侵性比较高，实现比较复杂。

那么燕在收到楚的作战信息的时候，会发现齐的作战信息被修改，楚已经叛变，这是燕会忽视来自楚的作战信息，最终执行齐发送的作战信息。这些都会导致自己的作战计划被扰乱，然后出现有的诸侯国在进攻，有的诸侯国在撤退的情况，而这时，秦国一定会趁机出兵，把他们逐一击破的。私钥加密，公钥解密。最终苏秦、齐、燕收到的信息都是“撤退、撤退、进攻”，按照少数服从多数的原则，执行“撤退”指令，实现了作战计划的一致性。齐、燕收到的信息列表是内容是一样的，只是顺序不一样，使用相同的排序算法，选取策略，可以保证选取的指令时一样的。