分布式事务一致性
分布式事务一致性解决的是事务ACID的问题, 而相对于单机事务一致性, 分布式事务一致性主要有两方面难点:
- 一致性的提交(ACID中的A), 即参与者要么全提交要么全回滚，题主提到的2PC、tcc、消息队列，本质上都是解决一致性提交问题的，这个问题的难点在于如何减低通信延迟和单点依赖，本质上可以抽象到paxos一类问题
- 外部一致性, 只要解决在非lock base并发隔离的场景下, 事务的可见顺序遵循外部可见的提交顺序, TrueTime、TSO就是解决而这类问题，HLC可以解决read-after-write（即提交成功后不能立即能够被读到），但是无法保证不相关事务的可见顺序（比如先后提交的两个事务T1、T2，保证同时并发执行读事务R3，禁止出现T2 R3 T1这样的时序）。这个问题本质上是多版本定法控制的问题。
多副本一致性
多副本一致性是其实翻译成“一致”并不准确，用区块链中“共识”这个词更合适一些，解决多个副本之间就一条数据持久化与否达成“共识”的问题
分布式事务一致性和共识问题的关系
简略：
- 分布式事务一致性会因为协调者单点引入可用性问题
- 为了解决可用性问题，分布式事务的节点需要在协调者故障时就新协调者选取达成共识
- 解决共识问题等价于实现一个线性一致的存储
- 解决共识问题等价于实现全序广播（total order boardcast）
- Paxos/Raft 实现了全序广播
详细：
为了保证分布式事务的一致性，分布式事务通常需要一个协调者（Coordinator）/事务管理器（Transaction Manager）来决定事务的最终提交状态。但无论2PC还是3PC，都无法应对协调者失效的问题，而且具有扩大故障的趋势。这就牺牲了可靠性、可维护性与可扩展性。为了让分布式事务真正可用，就需要在协调者挂点的时候能赶快选举出一个新的协调者来解决分歧，这就需要所有节点对谁是Boss达成共识（Consensus）。
共识意味着让几个节点就某事达成一致，可以用来确定一些互不相容的操作中，哪一个才是赢家。共识问题通常形式化如下：一个或多个节点可以提议（propose）某些值，而共识算法决定采用其中的某个值。在保证分布式事务一致性的场景中，每个节点可以投票提议，并对谁是新的协调者达成共识。
共识问题与许多问题等价，两个最典型的问题就是：
- 实现一个具有线性一致性的存储系统
- 实现全序广播（保证消息不丢失，且消息以相同的顺序传递给每个节点。）
Raft算法解决了全序广播问题。维护多副本日志间的一致性，其实就是让所有节点对同全局操作顺序达成一致，也其实就是让日志系统具有线性一致性。 因而解决了共识问题。（当然正因为共识问题与实现强一致存储问题等价，Raft的具体实现etcd 其实就是一个线性一致的分布式数据库。）
总结：
线性一致性是一个精确定义的术语，线性一致性是一种一致性模型，对分布式系统的行为作出了很强的保证。
分布式事务中的一致性则与事务ACID中的C一脉相承，并不是一个严格的术语。（因为什么叫一致，什么叫不一致其实是应用说了算。在分布式事务的场景下可以认为是：所有节点的事务状态始终保持相同）
分布式事务本身的一致性是通过协调者内部的原子操作与多阶段提交协议保证的，不需要共识；但解决分布式事务一致性带来的可用性问题需要用到共识。
参考
(10 封私信 / 84 条消息) 请问分布式事务一致性与raft或paxos协议解决的一致性问题是同一回事吗？ - 知乎