最终一致性
所有分布式一致性模型中最弱的 。不考虑中间的任何状态,只保证经过一段时间之后,最终系统内数据正确,最大程度上保证了系统的并发能力,因此在高并发场景下,也是使用最广的一致性模型
事务
事务是可以保证一致性的方法,在集中式系统架构中可以通过ACID的方式实现,在早期分布式架构,是通过CAP/BASE理论来实现的,后来又演化出了2pc/3pc,以及Paxos、Raft等算法来保证一致性 。
事务是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元 。(概念性的东西直接略过~)
- ACID
- Atomicity原子性简单说就是一个操作序列要么全部成功执行,要么全部不执行
- Consistency一致性也就是说数据从一个一致性状态转变到另一个一致性状态,中间不能存在不一致的状态
- Isolation隔离性在并发环境下,一个事务的执行不能被其他事务所干扰,每个事务都有各自独立完整的数据空间,也就是说一个事务内部的操作以及数据的使用对其他并发的事务都是隔离的 。根据隔离性的强度分为4个级别:
- 未授权读取(读未提交)这是隔离级别最低的 。比如说事务A和事务B同时进行,事务A在整个执行的过程中,会将某个数据值从1开始做加法操作直到变成10之后提交事务,而此时事务B能够看到事务A操作这个数据的所有变化(即从1到10的变化),而这一系列中间值的读取就是未授权读取
- 授权读取(读已提交)只允许读取已经被提交的数据而且不可重复读 。比如说事务A和事务B同时进行,同样进行加法操作(从1到10),那么此时事务B是无法看到所有的中间值,只能看到最终的10.
- 可重复读取在保证事务处理的过程中,多次读取同一个数据时候,它的值和事务开始时刻是一致的,可能会出现幻影数据(即同一个事务操作,在前后两个时间段内执行对同一个数据项进行读取,可能会得到不同的结果),还是拿上面的例子,事务B在第一次事务读取的时候,始终读到的是1,但是到第二次事务读取的时候就会变成了10(因为这个时候事务A已经完成了)
- 串行化即所有的事务串行执行
- Durability持久性
- 即一个事务一旦提交,对应数据的状态变更就是永久性的
- CAP
- Consistency一致性数据在多个副本之间是否能够保持一致的特性 。
- Avaliabilty可用性指系统提供的服务必须一直处于可用的状态,对于用户的操作总能给在有限的时间内返回结果,这里要注意下是在有限的时间内哦
- Partition tolerance分区容错性即分布式系统在遇到网络分区的时候,仍然能够保证对外提供满足一致性和可用性的服务,除非整个网络发生了故障注意:分布式系统无法满足上面三个特性,但是一定要有分布容错性,即P,C和A根据需求进行衡量
- BASE
- Basically Avaliable 基本可用即分布式系统中在出现故障的时候,允许损失部分可用性,比如响应时间上的损失或者功能上的损失,例如双11的时候,可以将一些无关紧要的服务进行降级
- Soft state软状态即允许系统中的数据存在中间状态,且中间状态的存在不会影响系统的整个可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程出现延时
- Eventually consistent最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步后,最终达到一个一致的状态
即二阶段提交,绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理 。即将事务的提交过程分为了两个阶段来处理
文章插图
- 阶段一:请求/表决阶段
- 1.事务询问协调者向参与者发起事务内容,询问是否可以执行事务操作,并等待响应
- 2.执行事务各参与者执行事务操作,并将undo和redo信息记录到事务日志中
- 3.各参与者向协调者反馈事务询问的响应协调者根据所有的参与者是否都响应了yes或者no来进行表决事务是否执行或者不执行
- 阶段二:提交/执行/回滚阶段
- 情况1.执行事务提交
- 1.发起提交请求协调者向参与者发起commit请求
- 2.事务提交参与者收到commit请求后,正式执行事务提交,完成之后释放资源
- 3.反馈事务提交结果参与者完成事务之后,向协调者发送ack消息
- 五分钟9步搞定nginx正向代理配置
- 分布式数据之缓存技术,今天就一起来揭开其神秘面纱
- 电脑蓝黑屏只会重启?3种方法教你轻松搞定,不花一分钱
- 据说让你抓狂的Nginx性能调优,我却这么轻松就搞定了
- MySQL还能实现分布式锁?
- 十分钟超有效瘦身瑜伽怎么做
- 「分布式计算」什么是严格一致性和最终一致性?
- 烂大街的Nginx+Redis分布式锁+MQ+MDB架构设计
- 「分布式架构」“一切都是分布式”说最终一致性
- 图解Raft:应该是最容易理解的分布式一致性算法
推荐阅读