请选择 进入手机版 | 继续访问电脑版
设为首页 收藏本站
开启辅助访问

新浪微博登陆

只需一步, 快速开始

QQ登录

只需一步,快速开始

切换风格 立即注册 找回密码

Java教程网

Java教程网 门户 程序人生 查看内容

分布式系统最终一致性

2018-7-5 21:41| 发布者: wenzhilanyu| 查看: 69| 评论: 0|来自: 黑客派

摘要: 前言目前的应用系统,不管是企业级应用还是互联网应用,最终数据的一致性是每个应用系统都要面临的问题,随着分布式的逐渐普及,数据一致性更加艰难,但是也很难有银弹的解决方案,也并不是引入特定的中间件或者特定 ...
前言

目前的应用系统,不管是企业级应用还是互联网应用,最终数据的一致性是每个应用系统都要面临的问题,随着分布式的逐渐普及,数据一致性更加艰难,但是也很难有银弹的解决方案,也并不是引入特定的中间件或者特定的开源框架能够解决的,更多的还是看业务场景,根据场景来给出解决方案。根据笔者最近几年的了解,总结了几个点,更多的应用系统在编码的时候,更加关注数据的一致性,这样系统才是健壮的。
基础理论相关

说起事务,目前的几个理论,ACID 事务特性,CAP 分布式理论,以及 BASE 等,ACID 在数据库事务中体现,CAP 和 BASE 则是分布式事务的理论,结合业务系统,例如订单管理,例如仓储管理等,可以借鉴这些理论,从而解决问题。
ACID 特性
A(原子性)事务的原子操作单元,对数据的修改,要么全部执行,要么全部不执行;
C(一致性)在事务开始和完成时,数据必须保持一致状态,相关的数据规则必须应用于事务的修改,以保证数据的完整性,事务结束时,所有的内部数据结构必须正确;
I(隔离性)保证事务不受外部并发操作的独立环境执行;
D(持久性)事务完成之后,对于数据的修改是永久的,即使系统出现故障也能够保持;
CAP
C(一致性)一致性是指数据的原子性,在经典的数据库中通过事务来保障,事务完成时,无论成功或回滚,数据都会处于一致的状态,在分布式环境下,一致性是指多个节点数据是否一致;
A(可用性)服务一直保持可用的状态,当用户发出一个请求,服务能在一定的时间内返回结果;
P(分区容忍性)在分布式应用中,可能因为一些分布式的原因导致系统无法运转,好的分区容忍性,使应用虽然是一个分布式系统,但是好像一个可以正常运转的整体
BASE
BA: Basic Availability 基本业务可用性;
S: Soft state 柔性状态;
E: Eventual consistency 最终一致性;
最终一致性的几种做法

单数据库情况下的事务


如果应用系统是单一的数据库,那么这个很好保证,利用数据库的事务特性来满足事务的一致性,这时候的一致性是强一致性的。对于 java 应用系统来讲,很少直接通过事务的 start 和 commit 以及 rollback 来硬编码,大多通过 spring 的事务模板或者声明式事务来保证。

基于事务型消息队列的最终一致性


借助消息队列,在处理业务逻辑的地方,发送消息,业务逻辑处理成功后,提交消息,确保消息是发送成功的,之后消息队列投递来进行处理,如果成功,则结束,如果没有成功,则重试,直到成功,不过仅仅适用业务逻辑中,第一阶段成功,第二阶段必须成功的场景。对应上图中的 C 流程。

基于消息队列 + 定时补偿机制的最终一致性


前面部分和上面基于事务型消息的队列,不同的是,第二阶段重试的地方,不再是消息中间件自身的重试逻辑了,而是单独的补偿任务机制。其实在大多数的逻辑中,第二阶段失败的概率比较小,所以单独独立补偿任务表出来,可以更加清晰,能够比较明确的直到当前多少任务是失败的。对应上图的 E 流程。

业务系统业务逻辑的 commit/rollback 机制


这一点说的话确实不难,commit 和 rollback 是数据库事务中的比较典型的概念,但是在系统分布式情况下,需要业务代码中实现这种,成功了 commit,失败了 rollback。

业务应用系统的幂等性控制


为啥要做幂等呢? 原因很简单,在系统调用没有达到期望的结果后,会重试。那重试就会面临问题,重试之后不能给业务逻辑带来影响,例如创建订单,第一次调用超时了,但是调用的系统不知道超时了是成功了还是失败了,然后他就重试,但是实际上第一次调用订单创建是成功了的,这时候重试了,显然不能再创建订单了。

查询

查询的 API,可以说是天然的幂等性,因为你查询一次和查询两次,对于系统来讲,没有任何数据的变更,所以,查询一次和查询多次一样的。

MVCC 方案

多版本并发控制,update with condition,更新带条件,这也是在系统设计的时候,合理的选择乐观锁,通过 version 或者其他条件,来做乐观锁,这样保证更新及时在并发的情况下,也不会有太大的问题。例如 update table_xxx set name=#name#,version=version+1 where version=#version# , 或者是 update table_xxx set quality=quality-#subQuality# where quality-#subQuality# >= 0 。

单独的去重表

如果涉及到的去重的地方特别多,例如 ERP 系统中有各种各样的业务单据,每一种业务单据都需要去重,这时候,可以单独搞一张去重表,在插入数据的时候,插入去重表,利用数据库的唯一索引特性,保证唯一的逻辑。

分布式锁

还是拿插入数据的例子,如果是分布是系统,构建唯一索引比较困难,例如唯一性的字段没法确定,这时候可以引入分布式锁,通过第三方的系统,在业务系统插入数据或者更新数据,获取分布式锁,然后做操作,之后释放锁,这样其实是把多线程并发的锁的思路,引入多多个系统,也就是分布式系统中得解决思路。

删除数据

删除数据,仅仅第一次删除是真正的操作数据,第二次甚至第三次删除,直接返回成功,这样保证了幂等。

插入数据的唯一索引

插入数据的唯一性,可以通过业务主键来进行约束,例如一个特定的业务场景,三个字段肯定确定唯一性,那么,可以在数据库表添加唯一索引来进行标示。

API 层面的幂等

这里有一个场景,API 层面的幂等,例如提交数据,如何控制重复提交,这里可以在提交数据的 form 表单或者客户端软件,增加一个唯一标示,然后服务端,根据这个 UUID 来进行去重,这样就能比较好的做到 API 层面的唯一标示。

状态机幂等

在设计单据相关的业务,或者是任务相关的业务,肯定会涉及到状态机,就是业务单据上面有个状态,状态在不同的情况下会发生变更,一般情况下存在有限状态机,这时候,如果状态机已经处于下一个状态,这时候来了一个上一个状态的变更,理论上是不能够变更的,这样的话,保证了有限状态机的幂等。

异步回调机制的引入


A 应用调用 B,在同步调用的返回结果中,B 返回成功给到 A,一般情况下,这时候就结束了,其实在 99.99% 的情况是没问题的,但是有时候为了确保 100%,记住最起码在系统设计中 100%,这时候 B 系统再回调 A 一下,告诉 A,你调用我的逻辑,确实成功了。其实这个逻辑,非常类似 TCP 协议中的三次握手。上图中的 B 流程。

类似 double check 机制的确认机制


还是上图中异步回调的过程,A 在同步调用 B,B 返回成功了。这次调用结束了,但是 A 为了确保,在过一段时间,这个时间可以是几秒,也可以是每天定时处理,再调用 B 一次,查询一下之前的那次调用是否成功。例如 A 调用 B 更新订单状态,这时候成功了,延迟几秒后,A 查询 B,确认一下状态是否是自己刚刚期望的。上图中的 D 流程。

总结


上面的几点总结,更多的在业务系统中体现,在超复杂的系统中,数据的一致性,不是说简单的引入啥中间件能够解决的,更多的是根据业务场景,来灵活应对。



鲜花

握手

雷人

路过

鸡蛋

最新评论

关闭

站长推荐 上一条 /1 下一条

小黑屋|手机版|Archiver|Java教程网    

GMT+8, 2018-10-24 11:08 , Processed in 0.187500 second(s), 21 queries .

Powered by Discuz X3.2

© 2001-2013 JAVA教程网

返回顶部