微服务架构：利用事件驱动实现最终一致性

 事宜同等性

起首，我们往返首一下ACID原则：

• Atomicity：原子性，改变数据状态要么是一路完成，要么一路失败
• Consistency：同等性，数据的状态是完备同等的
• Isolation：断绝线，纵然有并发事宜，相互之间也不影响
• Durability：耐久性， 一旦事宜提交，不行取消

在单体应用中，我们可以操作相关型数据库的特征去完成事宜同等性，可是一旦应用往微处事成长，按照营业拆分成不消的模块，并且每个模块的数据库已经分分开了，这时辰，我们要面临的就是漫衍式事宜了，必要本身在代码里头完成ACID了。较量风行的办理方案有：两阶段提交、赔偿机制、当地动静表(操作当地事宜和MQ)、MQ的事宜动静(RocketMQ)。

CAP定理

1998年，加州大学的计较机科学家 Eric Brewer 提出，漫衍式体系有三个指标。

• Consistency：同等性
• Availability：可用性
• Partition tolerance：分区容错

Eric Brewer 说，这三个指标不行能同时做到。这个结论就叫做 CAP 定理。

微处事中，差异模块之间行使的数据库是差异的，差异模块之间陈设的处事去也有也许是不消的，那么分区容错是无法停止的，由于处事之间的挪用不能担保百分百的没题目，以是体系计划必需思量这种环境。因此，我们可以以为CAP的P老是创立的，剩下的C和A无法同时做到。

现实上按照漫衍式体系中CAP原则，当P(分区容忍)产生的时辰，强行追求C(同等性)，会导致(A)可用性、吞吐量降落，此时我们一样平常用最终同等性来担保我们体系的AP手段。虽然不是放弃C，而是放弃强同等性，并且在一样平常环境下CAP都能担保，只是在产生分区容错的环境下，我们可以通过最终同等性来担保数据同等。

变乱驱动实现最终同等性

变乱驱动架构在规模工具之间通过异步的动静来同步状态，有些动静也可以同时宣布给多个处事，在动静引起了一个处事的同步后也许会引起其它动静，变乱会扩散开。严酷意义上的变乱驱动是没有同法式用的。

例子：

在电商内里，用户下单必需按照库存来确定订单是否成交。

项目架构：SpringBoot2+Mybatis+tk-Mybatis+ActiveMQ【由于小例子，不做成Spring Cloud架构】

起首，我们来看看正常的处事之间挪用：

代码：

@Override 
@Transactional(rollbackFor = Exception.class) 
public Result placeOrder(OrderQuery query) { 
 Result result = new Result(); 
 // 先长途挪用Stock-Service去镌汰库存 
 RestTemplate restTemplate = new RestTemplate(); 
 //哀求头 
 HttpHeaders headers = new HttpHeaders(); 
 headers.setContentType(MediaType.APPLICATION_JSON); 
 //封装成一个哀求工具 
 HttpEntity entity = new HttpEntity(query, headers); 
 // 同法式用库存处事的接口 
 Result stockResult = restTemplate.postForObject("http://127.0.0.1:8081/stock/reduceStock",entity,Result.class); 
 if (stockResult.getCode() == Result.ResultConstants.SUCCESS){ 
 Order order = new Order(); 
 BeanUtils.copyProperties(query,order); 
 order.setOrderStatus(1); 
 Integer insertCount = orderMapper.insertSelective(order); 
 if (insertCount == 1){ 
 result.setMsg("下单乐成"); 
 }else { 
 result.setMsg("下单失败"); 
 } 
 }else { 
 result.setCode(Result.ResultConstants.FAIL); 
 result.setMsg("下单失败："+stockResult.getMsg()); 
 } 
 return result; 
} 

我们可以看到，这样的处事挪用的破绽多多：

1、订单处事需同步守候库存处事的返回功效，接口功效返回拖延。2、订单处事直接依靠于库存处事，只要库存处事崩了，订单处事不能再正常运行。3、订单处事需思量并发题目，库存最后也许为负。

下面开始操作变乱驱动实现最终同等性

1、在订单处事新增订单后，订单的状态是“已开启”，然后宣布一个Order Created变乱到动静行列上

代码：

@Transactional(rollbackFor = Exception.class) 
public Result placeOrderByMQ(OrderQuery query) { 
 Result result = new Result(); 
 // 先建设订单，状态为下单0 
 Order order = new Order(); 
 BeanUtils.copyProperties(query,order); 
 order.setOrderStatus(0); 
 Integer insertCount = orderMapper.insertSelective(order); 
 if (insertCount == 1){ 
 // 发送 订单动静 
 MqOrderMsg mqOrderMsg = new MqOrderMsg(); 
 mqOrderMsg.setId(order.getId()); 
 mqOrderMsg.setGoodCount(query.getGoodCount()); 
 mqOrderMsg.setGoodName(query.getGoodName()); 
 mqOrderMsg.setStockId(query.getStockId()); 
 jmsProducer.sendOrderCreatedMsg(mqOrderMsg); 
 // 此时的订单只是开启状态 
 result.setMsg("下单乐成"); 
 } 
 return result; 
} 

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!