分布式事务专题笔记(一) 基础概念 与 CAP 理论
个人博客网:https://wushaopei.github.io/ (你想要这里多有)
一、基础概念
1、什么是事务
2、本地事务
3、分布式事务
begin transaction;
//1.本地数据库操作:张三减少金额
//2.本地数据库操作:李四增加金额
commit transation;
begin transaction;
//1.本地数据库操作:张三减少金额
//2.远程调用:让李四增加金额
commit transation;
4、分布式事务产生的场景
4.3 、多服务访问同一个数据库实例 比如:订单微服务和库存微服务即使访问同一个数据库也会产生分布式事务,原因就是跨JVM进程,两个微服务持有了不同的数据库链接进行数据库操作,此时产生分布式事务。
二、 分布式事务基础理论
1、CAP理论
1.1 理解CAP
- 商品服务请求主数据库写入商品信息(添加商品、修改商品、删除商品)
- 主数据库向商品服务响应写入成功。
- 商品服务请求从数据库读取商品信息。
一致性是指写操作后的读操作可以读取到最新的数据状态,当数据分布在多个节点上,从任意结点读取到的数据都
- 商品服务写入主数据库成功,则向从数据库查询新数据也成功。
- 商品服务写入主数据库失败,则向从数据库查询新数据也失败。
- 写入主数据库后要将数据同步到从数据库。
- 写入主数据库后,在向从数据库同步期间要将从数据库锁定,待同步完成后再释放锁,以免在新数据写入成功 后,向从数据库查询到旧的数据。
- 由于存在数据同步的过程,写操作的响应会有一定的延迟。
- 为了保证数据一致性会对资源暂时锁定,待数据同步完成释放锁定资源。
- 如果请求数据同步失败的结点则会返回错误信息,一定不会返回旧数据。
可用性是指任何事务操作都可以得到响应结果,且不会出现响应超时或响应错误。
- 从数据库接收到数据查询的请求则立即能够响应数据查询结果。
- 从数据库不允许出现响应超时或响应错误。
- 写入主数据库后要将数据同步到从数据库。
- 由于要保证从数据库的可用性,不可将从数据库中的资源进行锁定。
- 即时数据还没有同步过来,从数据库也要返回要查询的数据,哪怕是旧数据,如果连旧数据也没有则可以按照 约定返回一个默认信息,但不能返回错误或响应超时。
- 所有请求都有响应,且不会出现响应超时或响应错误。
通常分布式系统的各各结点部署在不同的子网,这就是网络分区,不可避免的会出现由于网络问题而导致结点之间通信失败,此时仍可对外提供服务,这叫分区容忍性。
- 主数据库向从数据库同步数据失败不影响读写操作。
- 其一个结点挂掉不影响另一个结点对外提供服务。
- 尽量使用异步取代同步操作,例如使用异步方式将数据从主数据库同步到从数据库,这样结点之间能有效的实现松耦合。
- 添加从数据库结点,其中一个从结点挂掉其它从结点提供服务。
- 分区容忍性分是分布式系统具备的基本能力。
2、CAP组合方式
在所有分布式事务场景中不会同时具备CAP三个特性,因为在具备了P的前提下C和A是不能共存的。
所以在生产中对分布式事务处理时要根据需求来确定满足CAP的哪两个方面。
放弃一致性,追求分区容忍性和可用性。这是很多分布式系统设计时的选择。
放弃可用性,追求一致性和分区容错性,我们的zookeeper其实就是追求的强一致,又比如跨行转账,一次转账请求要等待双方银行系统都完成整个事务才算完成。
放弃分区容忍性,即不进行分区,不考虑由于网络不通或结点挂掉的问题,则可以实现一致性和可用性。那么系统将不是一个标准的分布式系统,我们最常用的关系型数据库就满足了CA。
2、BASE 理论
CAP理论告诉我们一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容忍性(Partition tolerance)这三项中的两项,其中AP在实际应用中较多,AP即舍弃一致性,保证可用性和分区容忍性,但是在实际生产中很多场景都要实现一致性,比如前边我们举的例子主数据库向从数据库同步数据,即使不要一致性,但是最终也要将数据同步成功来保证数据一致,这种一致性和CAP中的一致性不同,CAP中的一致性要求在任何时间查询每个结点数据都必须一致,它强调的是强一致性,但是最终一致性是允许可以在一段时间内每个结点的数据不一致,但是经过一段时间每个结点的数据必须一致,它强调的是最终数据的一致性。
2.2 Base 理论介绍
BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。BASE理论是对CAP中AP的一个扩展,通过牺牲强一致性来获得可用性,当出现故障允许部分不可用但要保证核心功能可用,允许数据在一段时间内是不一致的,但最终达到一致状态。满足BASE理论的事务,我们称之为“柔性事务”。
- 基本可用:分布式系统在出现故障时,允许损失部分可用功能,保证核心功能可用。如,电商网站交易付款出现问题了,商品依然可以正常浏览。
- 软状态:由于不要求强一致性,所以BASE允许系统中存在中间状态(也叫软状态),这个状态不影响系统可用性,如订单的"支付中"、“数据同步中”等状态,待数据最终一致后状态改为“成功”状态。
- 最终一致:最终一致是指经过一段时间后,所有节点数据都将会达到一致。如订单的"支付中"状态,最终会变为“支付成功”或者"支付失败",使订单状态与实际交易结果达成一致,但需要一定时间的延迟、等待。
最新文章
- error when loading the sdk error parsing
- (spring-第20回【AOP基础篇】)Spring与事务
- LintCode ";Heapify";
- 关于jdbc收集
- hdu4632Palindrome subsequence
- CentOS 6.5 + Nginx 1.8.0 + PHP 5.6(with PHP-FPM) 负载均衡源码安装 之 (二)PHP(PHP-FPM)安装篇
- Xcode6和Xcode5获取app名字
- 给刚通过51入门的新人讲讲S12(MCS12XS128)与51的差别
- (中等) CF 311B Cats Transport,斜率优化DP。
- C#Session丢失问题的解决办法
- DOM拓展表格小练习
- CSS中层叠和CSS的7阶层叠水平(上篇)
- 【转】JAVA多线程实现的四种方式
- LCA的两种写法
- java 转义字符";\u0010"; ";\010"; ";\2";等
- Java RedisClient
- vue-router总结
- Html5——视频标签使用
- NB-IoT 的“前世今生”
- Go map中一个很重要的特性
热门文章
- 读源码之Spring 核心内容
- x86软路由虚拟化openwrt-koolshare-mod-v2.33联通双拨IPV6教程(第二篇)
- 【Hadoop离线基础总结】hive的窗口函数
- 详解 Spark 中的 Bucketing
- AOP行为日志
- search(14)- elastic4s-统计范围:global, filter,post-filter bucket
- Python-控制台实现简单的名片管理系统
- Reids的面试题
- 异步http接口调用库:httpx
- IIS网站发布不了.ttf .woff 文件 并且网站报脚本错误找不到