CAP讲解，BASE讲解

CAP:

    C:一致性，在多服务的场景下必须保障各个服务器之间的数据一致性。
    A:可用性，在分布式或者多服务场景下必须保证服务的可用性，比如需要返回成功和失败。
    P:分区容错性，必须保证分布式或者多服务场景下服务任何的错误或者数据的丢失都不能影响系统的继续运行。
  
      总结： 
         1.在系统架构的设计的一些场景中，我们只能保证CAP三个情况中的两种，比如在分布式多服务的一些场景和情况中，我们只能优先保证AP或者CP，因为是多服务或者分布式的情况下，我们必须保证P（分区容错性为前提），
            但是并不是说在分布式系统中一定会一直保持CP或者AP，在某些数据强一致性和可用性的情况下，我们可以使用AP，
            比如秒杀类的，我们可以对秒杀业务使用单服务运行，多服务备份的情况，其他服务继续使用AP或者CP原则，所以在一个系统的架构中，
            是可以躲在多个设计原则的，不同的应用场景我们可以采用不同的组合情况来实现，单服务情况下可以直接采用AC原则。
         2.CAP是忽略延迟性的理想化的模型，比如CP的理论是保证数据的一致性和服务的容错性，但是现实条件中多个服务间是存在网络延迟的，同一个机房也会存在毫秒级的数据不一致性，这种场景是无法满足CP的理论的。
         3.特殊情况下CA好CP是互补的，比如为了保住AP，服务1和服务2中服务2因为网络或者其他原因导致不可用，服务1继续接收写的请求，这时服务1需要将写入的数据通过日志或者其他方式同步给服务2，当服务2修复启用后快速恢复数据，达到数据一致性，这就是CP。
         4.在单机服务下，我们可以直接使用AP，因为单服务不存在分区容错性这个说法了。

BASE

      B（Basically Available）：基本可用性，指分布式系统出现故障的时候，比如内存不足等情况下我们可以采取保障核心系统可用，
      非核心的停用，比如在商城系统中，我们为了保障交易系统的可用，可以停掉积分、活动等系统，因为用户可以短时间看不到积分和一些推广活动，这不会影响到客户的正常下单和资金流入。
   
      A（Soft State）：软状态，就是指在短时间内可以允许不同服务之间的状态不一致，这和CP场景中因为网络传输带来的延迟导致的数据不一致性的场景差不多，也是CP的延伸。

      E：（Eventually Consistent）：最终一致性，就是你可以在短时间内状态不一致，但是最后必须要一致。

    总结：BASE其实主要是针对CP场景的一种延伸，因为没有完美情况下的CP，所以需要延伸和扩展补充。