数据一致性架构

数据一致性分为多副本数据一致性和分布式事务数据一致性，两者的差别在于，多副本下不同节点之间的数据内容是一样的，而分布式事务下不同节点之间的数据内容是不一样的。数据多副本一般用于容灾及高可用，副本之间通过**同步复制(强一致性)或者异步复制(最终一致性)**的方式达到数据一致。

事务提供了一种机制，将一个活动涉及的所有操作纳入一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下才能提交，其中任一操作执行失败，都将导致整个事务的回滚。按参与方的个数和性质，事务分为本地事务和分布式事务。

本地事务指数据库单机的事务处理，优点是支持严格的ACID特性：高效、可靠、状态可以只在资源管理器中维护、应用编程模型简单。但是本地事务不具备分布式事务的处理能力，隔离的最小单位受限于资源管理器。一般的关系型数据库可以较好实现本地事务的ACID特性。

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点上。简单来说，就是一次大的操作由不同的小操作组成，这些小操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性，常见方案 2PC、3PC、TCC。

事务的参与方可能不仅是数据库，还包括消息队列、缓存、对象存储等其他异构的数据源，当事务由全局事务管理器进行全局管理时成为全局事务，事务管理器负责管理全局的事务状态和参与的资源，协同资源的一致提交回滚。

在强一致性的分布式环境下，一次交易请求对多个数据源的数据执行完整性以及一致性的操作，满足事务的特性，要么全部成功，要么全部失败，保证原子性以及可见性。强一致性通过锁定资源的方式确保分布式并发下数据不会产生脏读脏写的情况，但以牺牲性能为代价。一般来说，强一致性的分布式事务会比单机的本地事务性能下降一个数量级左右，因此在实际应用场景中使用时，需要谨慎评估业务上是否一定要求强一致性事务，可否在业务上做一些取舍和折中，或者改为性能更强一点的最终一致性方案。

所谓强一致性，即复制是同步的；弱一致性，即复制是异步的。弱一致性主要针对数据读取而言，为了提升系统的数据吞吐量，允许一定程度上的数据“脏读”。某个进程更新了副本的数据，但是系统不能保证后续进程能够读取到最新的值。典型场景是读写分离，例如对于一主一备异步复制的关系型数据库，如果读的是备库（或者只读库），就可能无法读取主库已经更新过的数据，所以是弱一致性。

最终一致性不追求任意时刻系统都能满足数据完整且一致的要求，系统本身具有一定的“自愈”能力，通过一段业务上可接受的时间之后，系统能够达到数据完整且一致的目标。最终一致性有很多解决方案，如通过消息队列实现分布式订阅处理、数据复制、数据订阅、事务消息、尝试-确认-取消（Try-Confirm- Cancel，TCC）事务补偿等不同的方案。

著作权归作者所有：来自51CTO博客作者key_3_feng的原创作品，请联系作者获取转载授权，否则将追究法律责任
数据一致性解决方案概述
https://blog.51cto.com/key3feng/5286284