油画网站模板,怎么才能建立一个网站卖东西,网站的seo 如何优化,精准客户软件目录 一、什么是分布式系统
二、CAP理论
1.一致性Consisency
2.可用性(Availability)
3.分区容错性(Partition tolrance)
三、BASE理论
1.Basically Available(基本可用)
2.Soft state#xff08;软状态#xff09;
3.Eventually consistent#xff08;最终一致性软状态
3.Eventually consistent最终一致性
四、什么是分布式事务
1.本地事务ACID
2.分布式事务
五、分布式事务解决方案
1.二阶段提交2PC
2.三阶段提交3PC
3.TCCTry-Confirm-Cancel
4.Saga
5.基于消息的最终一致性:
6.最大努力通知
7.事务补偿机制 一、什么是分布式系统 一个系统各组件分别部署在不同服务器彼此通过网络通信和协调的系统。 可以指多个不同组件分布在网络上互相协作比如说电商网站也可以一个组件的多个副本组成集群互相协作如同一个组件比如数据存储服务中为了数据不丢失而采取的多个服务备份冗余当数据修改时也需要通信来复制数据 分布式最早出现的目地首先是解决单点问题避免单点故障然后解决了性能问题。
二、CAP理论 CAP理论说的是在一个分布式计算机系统中一致性可用性和分区容错性这三种保证无法同时得到满足最多满足两个。 1.一致性Consisency
一致性指all nodes see the same data at the same time即更新操作成功并返回客户端完成后所有节点在同一时间的数据完全一致。
2.可用性(Availability)
可用性指Reads and writes always succeed即服务一直可用而且是正常响应时间。
对于可用性的衡量标准如下 3.分区容错性(Partition tolrance)
分区容错性指the system continues to operate despite arbitrary message l ss or failure of part of the system即分布式系统在遇到某节点或网络分区故障的 时候仍然能够对外提供服务。分区容忍性分是布式系统具备的基本能力。
三、BASE理论 BASEBasically Available、Soft state、Eventual consistency是基于CAP理论逐步演化而来的核心思想是即便不能达到强一致性Strong consistency也可以根据应用特点采用适当的方式来达到最终一致性Eventual consistency的效果。 两个对冲理念ACID和BASE ACID是传统数据库常用的设计理念追求强一致性模型。BASE支持的是大型分布式系统提出通过牺牲强一致性获得高可用性。 1.Basically Available(基本可用)
基本可用本质是一种妥协也就是出现节点故障或者系统过载时通过牺牲非核心 功能的可用性保障核心功能的稳定运行。
实现基本可用的几个策略
流量削峰延迟响应异步处理体验降级过载保护熔断/限流故障隔离
2.Soft state软状态
弱状态允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延迟。
原子性是硬状态要求多个节点的数据副本都是一致的。
3.Eventually consistent最终一致性
分布式系统不能一直是软状态必须有个时间期限。在期限过后应当保证所有副本保持数据 一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时系统负载数据复制 方案设计等等因素。
四、什么是分布式事务
分布式事务是相对本地事务而言的对于本地事务利用数据库本身的事务机制 就可以保证事务的ACID特性
1.本地事务ACID
ATOMICITY
原子性一个事务中所有操作必须全部完成,要么全部不完成
CONSISTENCY
一致性在事务开始或结束时数据库应该在一致状态
ISOATION
隔离性事务与事务之间不会互相影响一个事务的中间状态不会被其他事务感知
DURABILITY
持久性一旦事务完成就不能返回事务对数据所做的变更完全保存在数据库中
2.分布式事务
在分布式环境下会涉及到多个数据库。分布式事务其实就是将对一个库事务的概念 扩大到了对多个库的事务。目的是为了保证分布式系统中的数据一致性。
分布式事务处理的关键是
需要记录事务在任何节点所做的所有动作事务进行的所有操作要么全部提交要么全部回滚
五、分布式事务解决方案
1.二阶段提交2PC 这是最传统的分布式事务协议。它分为两个阶段准备阶段和提交阶段。在准备阶段事务协调者询问所有参与节点是否准备好提交事务如果所有节点都回复“准备好”则进入提交阶段协调者命令所有节点提交事务如果有任何节点无法准备协调者命令所有节点回滚。 2PC缺点
1.性能阻塞问题
执行过程中所有参与节点都是事务阻塞性的当参与者占有公共资源时其他第三方节点访问公共资源就不得不处于阻塞状态为了数据的一致性而牺牲了可用性对性能影响较大不适合高并发高性能场景
2.可靠性问题
2PC非常依赖协调者当协调者发生故障时尤其是第二阶段那么所有的参与者就会都处于锁定事务资源的状态中而无法继续完成事务操作如果是协调者挂掉可以重新选举一个协调者但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题
3.数据一致性问题
在阶段二中当协调者向参与者发送commit请求之后发生了局部网络异常或者在发送commit请求过程中协调者发生了故障这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。
4.二阶段无法解决的问题
协调者在发出 commit 消息之后宕机而唯一接收到这条消息的参与者同时也宕机了那么即使协调者通过选举协议产生了新的协调者这条事务的状态也是不确定的没人知道事务是否被已经提交。
2.三阶段提交3PC 3PC三阶段提交协议是二阶段提交协议的改进版本。三阶段提交有两个改动点 在协调者和参与者中都引入超时机制为了解决2PC中协调者单点故障的问题3PC引入了预提交阶段 所以3PC分为3个阶段CanCommit 准备阶段、PreCommit 预提交阶段、DoCommit 提交阶段 3PC缺点
与2PC相比3PC降低了阻塞范围并且在等待超时后协调者和参与者会中断事务避免了协调者单点问题阶段三中协调者出现问题时参与者会继续提交事务。但数据不一致问题依然存在当在参与者收到 preCommit 请求后等待 doCommit 指令时此时如果协调者请求中断事务而协调者因为网络问题无法与参与者正常通信会导致参与者继续提交事务造成数据不一致。
2PC和3PC都无法保证数据绝对的一致性一般为了预防这种问题可以添加一个报警比如监控到事务异常的时候通过脚本自动补偿差异的信息。
3.TCCTry-Confirm-Cancel TCC模型将事务操作分为三个阶段Try预留资源、Confirm确认提交和Cancel取消释放。在Try阶段每个参与者尝试预留资源但不实际提交如果所有参与者都能预留成功则在Confirm阶段真正提交事务否则在Cancel阶段撤销之前的操作。 4.Saga Saga通过一系列的短事务也称为子事务来模拟长事务每个子事务都是可补偿的。如果某个子事务失败Saga会执行之前所有子事务的补偿操作从而达到事务的最终一致状态。 5.基于消息的最终一致性: 在这种模式下服务之间通过消息队列异步通信利用消息的发送与确认机制保证最终一致性。通常包括发布/订阅模型和事件驱动架构如 Saga 也可以通过这种方式实现。 6.最大努力通知 最大努力通知也称为定期校对是对MQ事务方案的进一步优化。它在事务主动方增加了消息校对的接口如果事务被动方没有接收到主动方发送的消息此时可以调用事务主动方提供的消息校对的接口主动获取。 最大努力通知事务主动方尽最大努力重试轮询....将事务发送给事务接收。被动方也可调用接口校对并消费。 7.事务补偿机制 通过业务层面的设计实现事务的补偿逻辑允许服务在失败后通过反向操作恢复到一致状态适用于对实时性要求不高的场景。
