现在的互联网开发中基本都会用到微服务架构，那么其中涉及的一些理论基础是必须要掌握的，这里总结下方便回顾。
cap理论：
一致性(C)：指在分布式系统中，所有节点在同一时刻存储的数值是一样的。举例：访问a节点和访问b节点都能得到一致的响应结果。
可用性(A)：指在访问服务器时能很快得到响应，但不保证数据正确性。
分区容错性(P)：节点与节点之间处于不同网络之中，一旦网络发生错误。系统任能提供服务。
分布式系统不可能同时满足数据一致性、可用性和分区容错性三个基本需求，最多只能同时满足其中的两个。分区网络故障是不能排除的，所以一般是AP和CP组合。但是注意P只是要考虑的一种情况，当没发生网络分区时，AC也是正常的。
AP组合牺牲一致性，这里说的一致性只是暂时的放弃，其实还有最终一致性。eureka采用的是ap组合，牺牲了数据一致性。
CP组合牺牲可用性，追求数据强一致性。银行转账业务就是强一致性模型。
base理论：是对cap理论的补充。
基本可用:当服务遭遇故障或大流量时保证主要的服务基本上可用。可通过四个基本手段实现。
- 延迟响应。如下游支付异常时并不报错，而是告诉你支付中，让你先等等。
- 体验降级。如某页面有问题的数据内容不展示，或者展示成默认的数据，而不是整个页面不展示。
- 当然如果想达到基本可用，那必须还的增加限流和熔断。这里限流有两层意思：1）指的对业务数据的削峰，常见就是利用mq处理。2）对接口本身的保护，比如TPS是50，超过就等待或者丢弃。
- 熔断则是调用后续服务大量失败时，不再调用后续服务的做法。就像保险丝一样。
软状态：指数据的中间状态，就像上面的支付中一样。
最终一致性：指数据虽然暂时不一致，但是最终还是会变为一致的。这个是分布式系统中保证数据一致的常见手段。因为保证强一致的话，代价太高，除非特定场景一般不用。比如订单转运单场景下，订单是一个服务，运单也是一个服务。那么除非你上分布式事务，不然不能保证两个服务的状态一致。但是这样代价太高了。所以想办法不数据同步过去最终一致即可。
