酒店预订网站开发,响应式网站 尺寸,做网站在线支付系统多少钱?,古董专家官方网站微信分布式系统数据一致性的基础知识#xff0c;传送门
1、问题的起源
在电商等业务中#xff0c;系统一般由多个独立的服务组成#xff0c;如何解决分布式调用时候数据的一致性#xff1f;
具体业务场景如下#xff0c;比如一个业务操作#xff0c;如果同时调用服务 A、B…分布式系统数据一致性的基础知识传送门
1、问题的起源
在电商等业务中系统一般由多个独立的服务组成如何解决分布式调用时候数据的一致性
具体业务场景如下比如一个业务操作如果同时调用服务 A、B、C需要满足要么同时成功要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。
在分布式系统来说如果不想牺牲一致性CAP 理论告诉我们只能放弃可用性这显然不能接受。为了便于讨论问题先简单介绍下数据一致性的基础理论。
强一致 当更新操作完成之后任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的就是用户上一次写什么下一次就保证能读到什么。根据 CAP 理论这种实现需要牺牲可用性。 弱一致性 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后不承诺立即可以读到最新写入的值也不会具体的承诺多久之后可以读到。 最终一致性 弱一致性的特定形式。系统保证在没有后续更新的前提下系统最终返回上一次更新操作的值。在没有故障发生的前提下不一致窗口的时间主要受通信延迟系统负载和复制副本的个数影响。DNS是一个典型的最终一致性系统。 2、数据一致性解决方案
在工程实践上为了保障系统的可用性互联网系统大多将强一致性需求转换成最终一致性的需求并通过系统执行幂等性的保证保证数据的最终一致性。但在电商等场景中对于数据一致性的解决方法和常见的互联网系统如 MySQL 主从同步又有一定区别主要分成以下 6 种解决方案。
2.1 规避分布式事务——业务整合
业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说则可以将服务 A、B、C 整合为一个服务 D 给业务这个服务 D 再通过转换为本地事务的方式比如服务 D 包含本地服务和服务 E而服务 E 是本地服务 A ~ C 的整合。
优点解决规避了分布式事务。
缺点显而易见把本来规划拆分好的业务又耦合到了一起业务职责不清晰不利于维护。
由于这个方法存在明显缺点通常不建议使用。
2.2 经典方案 - eBay 模式
此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景通过对账系统对事后问题的处理。
消息日志方案的核心是保证服务接口的幂等性。
考虑到网络通讯失败、数据丢包等原因如果接口不能保证幂等性数据的唯一性将很难保证。
eBay 方式的主要思路如下。
Base一种 Acid 的替代方案
此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章是一篇解释 BASE 原则或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。
如果 ACID 为分区的数据库提供一致性的选择那么如何实现可用性呢答案是
BASE (basically available, soft state, eventually consistent)
BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。下面是一个简单的例子如果将用户分区在 5 个数据库服务器上BASE 设计鼓励类似的处理方式一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法不过它确实可以带来更高的可感知的系统可用性。
文章中描述了一个最常见的场景如果产生了一笔交易需要在交易表增加记录同时还要修改用户表的金额。这两个表属于不同的远程服务所以就涉及到分布式事务一致性的问题。 文中提出了一个经典的解决方法将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题达到多次重试的幂等性增加一个更新记录表 updates_applied 来记录已经处理过的消息。 系统的执行伪代码如下 基于以上方法在第一阶段通过本地的数据库的事务保障增加了 transaction 表及消息队列 。
在第二阶段分别读出消息队列但不删除通过判断更新记录表 updates_applied 来检测相关记录是否被执行未被执行的记录会修改 user 表然后增加一条操作记录到 updates_applied事务执行成功之后再删除队列。
通过以上方法达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。
2.3 去哪儿网分布式事务方案
随着业务规模不断地扩大电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。
拆分首先要面临的是什么呢
最开始的单体应用所有功能都在一起存储也在一起。比如运营要取消某个订单那直接去更新订单表状态然后更新库存表就 ok 了。因为是单体应用库在一起这些都可以在一个事务里由关系数据库来保证一致性。
但拆分之后就不同了不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了而不是直接去操作库。这就涉及一个『分布式事务』的问题。
分布式事务有两种解决方式
2.3.1 优先使用异步消息
上文已经说过使用异步消息 Consumer 端需要实现幂等。
幂等有两种方式一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成如果当前状态是支付完成则再收到一个支付成功的消息则说明消息重复了直接作为消息成功处理。
另外一种方式如果业务逻辑无法保证幂等则要增加一个去重表或者类似的实现。对于 producer 端在业务数据库的同实例上放一个消息库发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出而是向消息库插入一条消息记录然后在事务提交的时候再异步将消息发出发送消息如果成功则将消息库里的消息删除如果遇到消息队列服务异常或网络问题消息没有成功发出那么消息就留在这里了会有另外一个服务不断地将这些消息扫出重新发送。
2.3.2 同步事务
有的业务不适合异步消息的方式事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似每个参与方的本地业务库的同实例上面放一个事务记录库。
比如 A 同步调用 BC。A 本地事务成功的时候更新本地事务记录状态B 和 C 同样。如果有一次 A 调用 B 失败了这个失败可能是 B 真的失败了也可能是调用超时实际 B 成功。则由一个中心服务对比三方的事务记录表做一个最终决定。假设现在三方的事务记录是 A 成功B 失败C 成功。那么最终决定有两种方式根据具体场景 重试 B直到 B 成功事务记录表里记录了各项调用参数等信息 执行 A 和 B 的补偿操作(一种可行的补偿方式是回滚)。
对 b 场景做一个特殊说明比如 B 是扣库存服务在第一次调用的时候因为某种原因失败了但是重试的时候库存已经变为 0无法重试成功这个时候只有回滚 A 和 C 了。
那么可能有人觉得在业务库的同实例里放消息库或事务记录库会对业务侵入业务还要关心这个库是否一个合理的设计
实际上可以依靠运维的手段来简化开发的侵入我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库通过框架层消息的客户端或事务 RPC 框架透明的在背后操作这个库业务开发人员只需要关心自己的业务逻辑不需要直接访问这个库。
总结起来其实两种方式的根本原理是类似的也就是将分布式事务转换为多个本地事务然后依靠重试等方式达到最终一致性。
2.4 蘑菇街交易创建过程中的分布式一致性方案
交易创建的一般性流程
我们把交易创建流程抽象出一系列可扩展的功能点每个功能点都可以有多个实现具体的实现之间有组合/互斥关系。把各个功能点按照一定流程串起来就完成了交易创建的过程。 面临的问题
每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢比如锁定优惠券服务调用超时了不能确定到底有没有锁券成功该如何处理再比如锁券成功了但是扣减库存失败了该如何处理
方案选型
服务依赖过多会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务9 个都执行成功了最后一个执行失败了那么是不是前面 9 个都要回滚掉这个成本还是非常高的。
所以在拆分大的流程为多个小的本地事务的前提下对于非实时、非强一致性的关联业务写入在本地事务执行成功后我们选择发消息通知、关联事务异步化执行的方案。
消息通知往往不能保证 100% 成功且消息通知后接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决后者可以选用事务消息来保证。
但是事务消息框架本身会给业务代码带来侵入性和复杂性所以我们选择基于 DB 事件变化通知到 MQ 的方式做系统间解耦通过订阅方消费 MQ 消息时的 ACK 机制保证消息一定消费成功达到最终一致性。由于消息可能会被重发消息订阅方业务逻辑处理要做好幂等保证。
所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中锁券和扣减库存是这样的两个典型场景。
要保证多个系统间数据一致乍一看必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升在电商领域绝对的强一致是过于理想化的我们可以选择准实时的最终一致性。
我们在交易创建流程中首先创建一个不可见订单然后在同步调用锁券和扣减库存时针对调用异常失败或者超时发出废单消息到MQ。如果消息发送失败本地会做时间阶梯式的异步重试优惠券系统和库存系统收到消息后会进行判断是否需要做业务回滚这样就准实时地保证了多个本地事务的最终一致性。
2.5 支付宝及蚂蚁金融云的分布式服务 DTS 方案
业界常用的还有支付宝的一种 xts 方案由支付宝在 2PC 的基础上改进而来。主要思路如下大部分信息引用自官方网站。
分布式事务服务简介
分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分前者是一个嵌入客户端应用的 JAR 包主要负责事务数据的写入和处理后者是一个独立的系统主要负责异常事务的恢复。
核心特性
传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下ACID 模型能有效保障数据的完整性但是在大规模分布式环境下一个业务往往会跨越多个数据库如何保证这多个数据库之间的数据一致性需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题但是 2PC 是反可伸缩模式也就是说在事务处理过程中参与者需要一直持有资源直到整个分布式事务结束。这样当业务规模达到千万级以上时2PC 的局限性就越来越明显系统可伸缩性会变得很差。基于此我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求其最大的特点是保证数据最终一致 (Eventually consistent)。
简单的说DTS 框架有如下特性 最终一致事务处理过程中会有短暂不一致的情况但通过恢复系统可以让事务的数据达到最终一致的目标。 协议简单DTS 定义了类似 2PC 的标准两阶段接口业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。 与 RPC 服务协议无关在 SOA 架构下一个或多个 DB 操作往往被包装成一个一个的 ServiceService 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上与底层协议无关。 与底层事务实现无关 DTS 是一个抽象的基于 Service 层的概念与底层事务实现无关也就是说在 DTS 的范围内无论是关系型数据库 MySQLOracle还是 KV 存储 MemCache或者列存数据库 HBase只要将对其的操作包装成 DTS 的参与者就可以接入到 DTS 事务范围内。
以下是分布式事务框架的流程图 实现
一个完整的业务活动由一个主业务服务与若干从业务服务组成。
主业务服务负责发起并完成整个业务活动。
从业务服务提供 TCC 型业务操作。
业务活动管理器控制业务活动的一致性它登记业务活动中的操作并在活动提交时确认所有的两阶段事务的 confirm 操作在业务活动取消时调用所有两阶段事务的 cancel 操作。”
与 2PC 协议比较
没有单独的 Prepare 阶段降低协议成本
系统故障容忍度高恢复简单
2.6 农信网数据一致性方案
2.6.1 电商业务
公司的支付部门通过接入其它第三方支付系统来提供支付服务给业务部门支付服务是一个基于 Dubbo 的 RPC 服务。
对于业务部门来说电商部门的订单支付需要调用
支付平台的支付接口来处理订单同时需要调用积分中心的接口按照业务规则给用户增加积分。
从业务规则上需要同时保证业务数据的实时性和一致性也就是支付成功必须加积分。
我们采用的方式是同步调用首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付由积分平台提供增加与回撤接口。
具体的流程是先调用积分平台增加用户积分再调用支付平台进行支付处理如果处理失败catch 方法调用积分平台的回撤方法将本次处理的积分订单回撤。
2.6.2 用户信息变更
公司的用户信息统一由用户中心维护而用户信息的变更需要同步给各业务子系统业务子系统再根据变更内容处理各自业务。用户中心作为 MQ 的 producer添加通知给 MQ。APP Server 订阅该消息同步本地数据信息再处理相关业务比如 APP 退出下线等。
我们采用异步消息通知机制目前主要使用 ActiveMQ基于 Virtual Topic 的订阅方式保证单个业务集群订阅的单次消费。
3、总结
分布式服务对衍生的配套系统要求比较多特别是我们基于消息、日志的最终一致性方案需要考虑消息的积压、消费情况、监控、报警等。
