如何保障-数据一致性

一、概述:

在日常的工作场景,经常遇到数据一致性相关的问题,各路大神在应对各类问题时,也开发出了各种优秀的技术组件,接下来汇总一下,希望对大家学习有帮助.

 
二、单机环境下,多线程并发:

在单机多线程并发情况下,如何保障对共享数据的安全访问?相信有经验的开发人员,应该都能回答出来,多线程并发涉及的知识点Synchronized,ReentrantLock,CAS操作通过获取对象锁修饰代码块或者方法,来确保对共享变量的安全访问,来保障逻辑上的一致性。


三、数据库事务:

以mysql为例,MySQL XA 是基于Open Group 的<<Distributed Transaction Processing:The XA Specification>> 标准实现的,支持分布式事务,允许多个数据库实例参与一个全局的事务。MySQl XA 从MySQL 5.0 开始引入,众多的存储引擎当中,仅innodb存储引擎支持MySQL XA事务。
1、事务的特征ACID
      A 原子性
      C 一致性
      I 隔离性
      D 持久化
2、事务的隔离级别
    Read Uncommitted(读取未提交内容)
    Read Committed(读取提交内容)
    Repeatable Read(可重读)
    Serializable(可串行化)
3、事务的传播特性
    七种事务的传播特性


四、CAP理论:

C表示一致性,各个副本节点上,数据需要保持一致性;
A可用性;
P分区容错性,分布式环境下,当有网络,环境等等问题,必须得让系统持续对外提供服务保障;


五、BASE理论:

    BA  表示基本可用
    S   表示Soft  status  ,可以容忍中间状态的存在;
    E   表示最终一致性;
    相对传统的事务强调强一致性,互联网分布式事务,更多的采用柔性事务,例如电商下单,同时发放优惠券,发放优惠券的动作,可以采用异步的方式,例如存放工单表,后台定时任务扫描工单表,负责处理发放优惠劵的动作。

    再例如Zookeeper  主从节点数据同步,采用超过一半确认,就可以提交的方式,也是采用柔性事务,只要达成事务最终一致性就OK。


六、分布式锁: 

     分布式锁,相对单例模式下并发线程的锁,当需要控制多个实例上面的线程操作某个共享变量时,分布式锁显得尤为重要,当获取锁,才可以业务操作,否则等待。可以采用curator、redis等相关中间件,实现分布式锁。


七、分布式事务:

      当事务控制多个数据库实例时,需要有个事务管理器TM管理多个资源管理器RM,通过XID标识同一个事务,分布式事务的实现方案有以下两种:

     1、2PC:

         两阶段提交又称2PC(two-phase commit protocol),2pc是一个非常经典的强一致、中心化的原子提交协议。这里所说的中心化是指协议中有两类节点:一个是中心化协调者节点(coordinator)N个参与者节点(partcipant)

     2、3PC,

       三阶段提交(Three-phase commit),也叫三阶段提交协议(Three-phase commit protocol),是二阶段提交(2PC)的改进版本。

与两阶段提交不同的是,三阶段提交有两个改动点。

  1. 引入超时机制。同时在协调者和参与者中都引入超时机制。
  2. 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

也就是说,除了引入超时机制之外,3PC把2PC的准备阶段再次一分为二,这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

2PC与3PC的区别

相对于2PC,3PC主要解决的单点故障问题,并减少阻塞,因为一旦参与者无法及时收到来自协调者的消息后,会默认执行commit操作,而不会一直让事务处于阻塞状态。但是也有可能会造成数据不一致。例如:当一部分机器收不到协调者信息,这时候协调者发送的abort信息,这样的话,一部分机器commit,一部分rollback,就会导致数据不一致。

3、TCC

TCC分别对应Try,Confirm和Cancel三种操作,三个操作业务含义如下:

Try:预留业务资源

Confirm:确认执行业务操作

Canal:取消执行业务操作

与关系型数据库事务的三个操作作对比:DML、Commit,Rollback

操作TCC关系型数据库事务
Try/DML预留业务资源锁定数据库记录行
Confirm/Commit确认后,使用预留资源对锁定记录航进行操作
Cancel/Rollback没有全部成功就回滚没有全部成功就回滚

TCC和两阶段分布式事务处理的区别

当讨论2PC时,我们只专注事务处理阶段,因而只讨论prepare和commit,所以,可能很多人都忘了,使用2PC事务管理机制也是有业务逻辑阶段的。正是因为业务逻辑的执行,发起了全局事务,这才有其后的事务处理阶段。所以,实际上,使用2PC机制时,以提交为例:

一个完整的事务周期:

begin–>业务逻辑–>prepare–>commit。

再看TCC,也不外如是:要发起全局事务,同样也必须通过业务逻辑来实现。该业务逻辑一来通过执行触发TCC全局事务的创建;二来也需要执行部分数据写操作;此外还要通过执行想TCC全局事务注册自己,以便后续TCC全局事务commit/rollback时回调其相应的confirm/canal业务逻辑。所以,使用TCC机制时,以提交为例:

一个完整的生命周期:

begin–>业务逻辑(Try业务)–>commit(confirm业务)。

综上所述:将两个机制做对应:

1、2PC机制的业务阶段 === TCC机制的try业务阶段

2、2PC机制的提交阶段(prepare & commit) ==== TCC机制的提交阶段(confirm)

3、2PC机制的回滚阶段(rollback) === TCC机制的回滚阶段(cancel)

 

八、幂等:

       所谓幂等,就是当客户端发起功能重试时,N次操作,都跟第一次操作结果相同,例如查询就是天生的幂等;下单,如果客人重复提交下单,这时系统不能生成很多重复的订单,这就需要幂等的判断处理。

       可以根据请求的入参组装起来求取hashcode ,如果值跟现有库中数据相同,表示已经有相同的请求,系统则自动返回,不会再重复生成一条订单。

 

 

 

 

 

©️2020 CSDN 皮肤主题: 书香水墨 设计师:CSDN官方博客 返回首页