分布式系统CAP理论到BASE理论落地

说明：转载本人掘金文章

CAP理论

1.Partition tolerance指的是一个分布式系统不能因为多个网段的其中一个网段出现问题，而导致整个分布式的一致性和可用性得不到保证，也就是支持分区容错是一个分布式系统的前提和基础，否则不被称为分布式系统。保证分区容错的言外之意就是，如果你的系统是个分布式系统，那么你的服务节点一定是多副本并且副本节点分布在任意网段的，这是作为一个分布式系统的基本要求。

2.Availability指的是分布式系统对于一个任意用户请求，需要在用户预期内得到系统的响应。这里如果没有及时响应，并不是说的是单点故障造成的，p理论已经说明了这一点，分布式系统不存在单点故障问题。这里可用性指的是由于整个分布式系统处理能力已经达到上限，导致的服务卡顿超时。

3.Consistency指的是分布式系统中，不同类型服务数据一致性问题。假设一个订单系统，拆分为订单和库存系统，那么现在这个在分布式系统中已经是处在不同节点中，那么数据一致性问题就比较难于得到保证了。

Availability和Consistency其实是会相互制约的。因为保证一致性性能其实会受到影响，会拖慢系统，影响系统吞吐量（数据库XA和seta不被广泛使用原因）。

现实中分布式系统

1.Partition tolerance：我们看到是支持P理论的，在阿里云购买多地的机器，并且都部署了多个副本，就算北京或者上海机房出现问题，依然可以保证服务的可用性和一致性，满足了分布式系统的大前提。支持p理论，我们只要继续在阿里云上买机器，就可以不断满足我们分布式系统的无限扩展的特性了。

2.Availability：正常情况下单，我们系统都是能够正常处理订单的，但是当系统达到了处理极限，比如大促销，那么订单服务可能会发生延迟。我之前在的公司为了满足a理论，每个微服务都集成hystris（setinel）,进行服务的降级和熔断，一般是保持基本可用，核心功能还是尽最大努力正常提供服务。

3.Consistency：订单下单后，其实是要同时生成订单和完成扣款的，否则就不满足c了。现实中，笔者之前采用两种方案来解决，TCC和消息队列，其实这是个典型的分布式事务问题。一般有两种类型分布式事务方案，一个是这里的c(强一致性)，还有就是Base理论的e(最终一致性)。强一致性一般有数据库本身支持的XA,还是开源项目seta;最终一致性就是笔者使用的TCC和消息队列方案。

BASE理论

1.BASE理论是基于CAP理论提出的，是对CAP理论补充。就是为了解决C和A冲突问题提出的。

2.Basically Available（BA）,针对的是CAP中的A,指的是基本可用，也就是保证业务系统核心服务可用，其它不重要服务可用进行限流降级熔断。一般落地方案有hystrix和sentinel

3.Soft State（S） 和 Eventual Consistency(E),针对的是CAP中的C,也就是要退而求其次，为了不影响系统A,而放弃强一致性，只需要最新一致性即可。一般落地方案TCC和消息队列。

总结

实际项目中，落地方案都是结合CAP和BASE理论落地的，解决可用性使用hystrix或者setinel;解决一致性使用seta或者TCC和消息队列；解决分区容错结合springcloud或者dubbo的注册中心(zk,eureka，consul,nacos)服务发现远程调用(feign,dubbo)