说明
为了保证分布式事务的一致性，分布式事务通常需要一个 事务管理器 （Transaction Manager） 来决定事务的最终提交状态。但无论是 2PC 还是 TCC 都无法应对协调者失效的问题，而且具有扩大故障的趋势。这就牺牲了可靠性、可维护性与可扩展性。为了让分布式事务真正可用，就需要在协调者挂点的时候能赶快选举出一个新的协调者来解决分歧，这就需要所有节点对谁是 Boss 达成共识（Consensus）。
因此就需要 分布式共识算法
共识意味着让几个节点就某事达成一致，可以用来确定一些互不相容的操作中，哪一个才是赢家。共识问题通常形式化如下：一个或多个节点可以提议（propose） 某些值，而共识算法决定采用其中的某个值。在保证分布式事务一致性的场景中，每个节点可以投票提议，并对谁是新的协调者达成共识。
共识问题与许多问题等价，两个最典型的问题就是：
- 实现一个具有线性一致性的存储系统
- 实现全序广播（保证消息不丢失，且消息以相同的顺序传递给每个节点。）
Raft算法解决了全序广播问题。维护多副本日志间的一致性，其实就是让所有节点对同全局操作顺序达成一致，也其实就是让日志系统具有线性一致性。 因而解决了共识问题。（当然正因为共识问题与实现强一致存储问题等价，Raft的具体实现etcd 其实就是一个线性一致的分布式数据库。）
总结
线性一致性是一个精确定义的术语，线性一致性是一种 一致性模型 ，对分布式系统的行为作出了很强的保证。
分布式事务中的一致性则与事务ACID中的C一脉相承，并不是一个严格的术语。（因为什么叫一致，什么叫不一致其实是应用说了算。在分布式事务的场景下可以认为是：所有节点的事务状态始终保持相同）
分布式事务本身的一致性是通过协调者内部的原子操作与多阶段提交协议保证的，不需要共识；但解决分布式事务一致性带来的可用性问题需要用到共识。