【分布式事件】怎么解决分布式场景下数据一致性题目
分布式事件的由来拿充值订单举个栗子吧，假设：原本订单模块和账户模块是放在一起的，现在需要做服务拆分，拆分成订单服务，账户余额服务。原本收到充值回调后，可以将修改订单状态和扣减余额放在一个mysql事件中完成的，但是呢，由于服务拆分了，就面对着需要调和2个服务才气完成这个事件，所以我们怎么解决分布式场景下数据一致性题目呢？
当地事件、分布式事件
如果说当地事件是解决单个数据源上的数据操作的一致性题目的话，那么分布式事件则是为了解决跨越多个数据源上数据操作的一致性题目。
弱一致性
数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。
最终一致性就属于弱一致性。
强一致性
系统中某个数据被更新后，后续任何对该数据的读取操作都能得到该更新后的值。在任意时刻，全部节点中的数据都是一致的。
2PC
XA是X/Open CAE Specification (Distributed Transaction Processing)模型中界说的TM（Transaction Manager）与RM（Resource Manager）之间进行通讯的接口。
在XA规范中，数据库充当RM脚色，应用需要充当TM的脚色，即生玉成局的txId，调用XAResource接口，把多个当地事件调和为全局统一的分布式事件。
二阶段提交是XA的标准实现。它将分布式事件的提交拆分为2个阶段：prepare和commit/rollback。
2PC模型中，在prepare阶段需要等待全部参与子事件的反馈，因此可能造成数据库资源锁定时间过长，不得当并发高以及子事件生命周长较长的业务场景 。两阶段提交这种解决方案属于捐躯了一部分可用性来换取的一致性。
优缺点：
优点：实现简单，使用数据库本身的事件实现
缺点：需要数据库本身支持事件
TCC（补偿事件）
TCC 其实就是接纳的补偿机制，其焦颔首脑是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。TCC模型是把锁的粒度完全交给业务处理。它分为三个阶段：
1、Try 阶段主要是对业务系统做检测及资源预留
2、Confirm 阶段主要是对业务系统做确认提交，Try阶段执行乐成并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try乐成，Confirm一定乐成。
3、Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源开释
优缺点：
优点：可支持非事件数据库（redis），由业务自己编码实现
缺点：代码侵入性强
事件消息（半消息）
事件消息作为一种异步确保型事件， 将两个事件分支通过MQ进行异步解耦，事件消息的计划流程同样鉴戒了两阶段提交理论，整体交互流程如下图所示：https://i-blog.csdnimg.cn/direct/e0c3c6695fa34bc795f36a59b5ae57a7.jpeg
1、事件发起方首先发送prepare消息到MQ。
2、在发送prepare消息乐成后执行当地事件。
3、根据当地事件执行效果返回commit或者是rollback。
4、如果消息是rollback，MQ将删除该prepare消息不进行下发，如果是commit消息，MQ将会把这个消息发送给consumer端。
5、如果执行当地事件过程中，执行端挂掉，或者超时，MQ将会不停的扣问其同组的其它producer来获取状态。
Consumer端的消耗乐成机制有MQ包管。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]