02-2 分布式一致性相关协议

一、分布式一致性协议

  • 分布式一致性协议分为:两阶段提交协议,三阶段提交协议,TCC协议

1.1、两阶段提交协议

1.1.1、流程:
1、准备阶段:
  • 协调者向参与者发起指令,参与者可以完成时写redo或undo日志,锁定资源执行操作,不提交(阻塞操作)
2、提交阶段:
  • 参与者返回成功,协调者向参与者发送提交指令,参与者提交事务释放资源。
注意:
  • 如果任何步骤失败协调者向参与者发起终止指令,参与者取消已变更事务执行undo日志释放锁定资源
1.1.2、缺点:重量级操作,实现复杂,成本较高,不灵活
1、阻塞:
  • 参与者每一步操作都处于阻塞状态,并在收到明确指令才会响应
2、单点故障:
  • 协作者宕机后参与者一直阻塞
3、脑裂:
  • 多个参与者接收同一个操作指令时部分参与者没有收到指令存在多个参与者之间不一致
1.1.3、说明
两个阶段强一致性,出现异常时需要人工干预,符合CAP协议一致性与可用性不能同时满足

1.2、三阶段提交协议

三阶段提交协议是两阶段提交协议的改进版,通过超时机制解决了阻塞问题(不会阻塞和永远锁定资源)

1.2.1、流程

1、询问阶段:
  • 协调者询问参与者是否可以完成指令,协调者只回复是或不是
2、准备阶段:
  • 询问返回是则继续完成准备操作,返回不是则终止操作
3、提交阶段:
  • 执行提交操作

1.2.2、两阶段与三阶段对比

1、询问操作可以提前发现无法执行的操作,不能发现所有的情况。
2、准备阶段后协调者和参与者增加了超时,当超时协调者和参与者继续提交事务默认成功。
3、在极端情况两阶段提交和三阶段提交都会阻塞和不一致

1.3、TCC协议

1.3.1、流程:
  • 将任务拆分成Try,Confirm,Cancel三个步骤
Try:先咨询Try,如果没问题执行Confirm
Confirm:执行异常,执行cancel
Cancel:逆操作
1.3.2、说明:
  • 1、仍然是个两段提交协议
  • 2、有自我修复能力,异常情况通过逆操作来保证一致性
  • 3、解决了量算提交的阻塞问题,没有解决脑裂和一致性问题
1.3.3、场景使用:商品秒杀
  • 1、用户下单
  • 2、查询库存,还有库存则锁定库存
  • 3、订单状态为待支付,指引用户支付
  • 4、如果支付异常系统自动将锁定商品解锁供其他用户

二、最终一致性模式

  • 为了实现最终的一致性有一些有效简单的模式

2.1、查询模式

2.1.1、实现
  • 1、任何服务操作提供一个查询接口,用与获取当前操作执行状态
  • 2、使用方通过查询接口获取服务操作执行状态,根据不同状态做操作
2.1.2、使用场景:
  • 订单查询,可以使用操作id或订单id查询
  • 1、服务功能:单笔查询操作,批量查询(批量查询需要有分页)

2.2、补偿模式

  • 通过查询得知服务异常时,需要启用补偿模式修复系统达到一致性
2.2.1、流程:
  • 1、发起方调用执行方
  • 2、执行成功则发起方也成功
  • 3、执行失败立即返回失败,调用逆向操作
2.2.2、补偿操作
1、自动恢复:
  • 系统执行Cancel进行未完成操作或回滚操作,达到一致性
2、通知运营:
  • 无法自动恢复采用手动方式补偿
3、技术运营:
  • 采用数据库变更或代码变更,尽量避免

2.3、异步确保模式

  • 用于对响应时间要求不高的场景,此方案的好处就是削峰。如:物流配送,支付计费
2.3.1、流程:
  • 1、将要执行的异步操作封装后进行持久化
  • 2、通过定时任务执行未完成任务进行补偿操作

2.4、定期校对模式

  • 定期校对主要是为了保证数据的准确性,一般用于金融系统
  • 金融系统核心在于数据准确性,社交应用在于数据量大
2.4.1、流程:
  • 1、在操作主流程的系统时进行校对操作
  • 2、异步的进行评论校对操作,如果出现不一致进行补偿操作
2.4.2、注意:
  • 定期校对的关键是系统中唯一ID,实现方式:
1、持久型:
  • 使用数据库自增或Sequence生成,机器重启会损失部分ID但是不会有问题
2、时间型:
  • 机器号,业务号,时间,单节点自增ID

2.5、可靠消息模式

  • 优先级低的操作采用异步方式执行,是为了让系统解耦,可以通过消息实现
2.5.1、消息可靠发送(将消息和消息状态持久化)
  • 方式一:消息发送前将消息保存,状态为待发送,然后发送消息,如果消息发送成功将消息改为发送成功
  • 方式二:封装出消息管理器,并将消息存放采用单独服务器。
2.5.2、消息的幂等性
  • 消息的重复发送需要保证消息的幂等性
幂等性:
  • 就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而产生了副作用
保证操作幂等性方法
  • 1、使用数据库表的唯一键继续过滤,拒绝重复的请求
  • 2、使用分布式表对请求进行过滤
  • 3、使用状态流转的方向性来过滤,通常使用数据库的行级锁来实现
  • 4、根据业务特点,实现操作幂等,如资源删除,资源增加,资源获取

2.6、缓存一致性模式

使用缓存保证一致性最佳实践
  • 1、如果性能要求不高使用分布式缓存
  • 2、写入缓存数据时,有部分数据无效不要把部分数据放入缓存
  • 3、为了提高性能缓存与数据库只需要保持弱一致性不保持强一致性,否则违背了缓存初衷
  • 4、读的数据为先读缓存再读数据库,写数据为先写数据库再写缓存
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值