文章分类

当前位置:首页>文章中心>行业新闻>业务中台数据一致性方案

业务中台数据一致性方案

发布时间:2021-10-12 点击数:6

引言

随着业务的发展,微服务架构逐渐成为当下业务中台的主流架构形式,它不但解决了各个应用之间的解耦问题,同时也解决了单体应用的性能问题实现可扩展可动态伸缩的能力。如下图所示,业务中台就是将平台的通用能力进行下沉,避免重复建设,形成底座平台能力,上层的各个应用服务都是基于中台能力进行快速构建。但是随着应用规模的扩大,原本在单体应用中不是问题的问题,在微服务架构中可能就是比较严重的问题,本文所要探讨的服务之间的数据一致性便是其中最具代表性的问题。本文将结合常见的电商下单场景来说明业务中台数据一致性方案。

 

数据一致性原理预备知识

在探讨业务中台数据一致性方案之前,我们先来一起回顾下数据库事务的相关内容,通过对数据库事务的分析,我们可以看出来在微服务架构中想要保证数据的一致性将会遇到什么样的问题。

 

1、本地事务

 

事务的概念对于程序猿来说一定不陌生,这里的事务指的是数据库事务。所谓数据库事务,简单来理解就是一套关于数据一致性维护的数据库机制。 我们都知道,实际业务平台大部分的业务数据还是保存在关系型数据库中,在单体应用的时代,数据库实例本身可以保证事务的有效性。

数据库事务需要满足四个基本特征:

 

(1)原子性(Atomicity):极端主义者,要么大家一起成功,有一个失败都不行

 

(2)一致性(Consistency): 数据具有一致性,不存在状态不确定的状况

 

(3)隔离性(Isolation):事务之间互相不干扰,你走你的阳关道,我走我的独木桥

 

(4)永久性(Durability):一旦事务提交后,数据就记录就会被持久化

 

都说王守义 13 香,笔者最近也下单了一部 pro 准备换掉三年前的 iphone。那么我们以下单购买 iphone13 进行举例说明,我们暂时将如下图所示,如果在一个完整事务中,存在生成订单、扣减库存、增加积分以及发放优惠券这四项业务,那么要么这四项都成功,下单够购买 13 香这个业务才算是成功,中间有一项失败就会造成业务数据的不一致,因此需要进行事务回滚,回滚到下单前的状态,以保证业务数据的一致性。

 

在线客服