本文转载自微信公众号《潜行》，作者cscw。转载本文请联系SneakUp公众号。前言随着业务的扩大，功能也越来越多。把所有的功能都放在同一个服务下，代码混杂、交错，维护难度大，很容易出现一个小bug导致整个服务不可用。因此，我们会根据业务功能拆分成多个不同的服务（形成微服务），多个服务组成的系统有个响亮的名字：分布式系统；以及我们应该如何管理系统中的服务状态，相关的理论是什么？分布式和集群数据库事务分布式事务分布式数据一致性CAP理论BASE理论分布式和集群分布式是指多个服务或组件通过网络连接，通过交换信息和协作形成系统集群是指由同一服务的多个实例组成的整体成分。这两个概念并不完全冲突，分布式系统也可以是集群。zookeeper集群也是一个分布式系统，它的服务之间会相互通信。如果协作集群不是分布式系统，比如多个负载均衡的HTTP服务器，它们之间是不会通信的。如果不带负载均衡的话，就不能称之为分布式系统数据库事务。交易基于数据。有必要确保交易数据通常存储在数据库中。所以我们在介绍事务的时候，就不得不介绍数据库事务的ACID特性。原子性（Atomicity），整个事务中的所有操作要么全部完成，要么没有完成，不可能停滞在中间的某个环节一致性（Consistency），事务开始前和事务结束后，数据库数据的一致性约束没有被打破和隔离隔离，隔离可以防止多个事务并发执行时，由于交叉执行导致数据不一致（持久性）。事务处理完成后，对数据的修改是永久性的，即使系统出现故障，分配也不会丢失。一个事务分布式系统一般由多个独立的子系统组成，多个子系统通过网络通信相互协作完成各种功能；这个协作过程需要保证各个系统的数据一致性，我们把这个跨系统的事务称为分布式，在正式事务的上述场景中会有很多情况；库存服务和订单服务都成功了。或者库存服务和订单服务部分成功，传统的单机事务理论不再适用于分布式事务的困难。Donothing,ordoallconsistency：当发生网络传输故障或节点故障时，节点间的数据复制通道中断，事务操作时必须保证数据的一致性和隔离性：在分布式事务控制中，可能存在如果提交不同步，就会出现“partiallycommitted”事务。分布式数据一致性ACID不适用于分布式事务，分布式事务难点涉及的问题最终会影响到数据不一致性。因此，在分布式系统中会重点保证系统的一致性。CAP理论中引入的分布式事务困难所涉及的问题，最终的影响是造成数据不一致，下面是对分布式系统一致性的理论分析，以及基于这些理论引入的分布式解决方案（availabilityConflictwithConsistency:CAPTheory)一致性：所有节点访问相同的最新数据副本可用性：非故障节点在合理的时间内返回合理的响应（不是错误或超时响应）分区容忍度：当分布式系统存在网络分区时，它仍然可以对外提供服务。当发生网络分区时，如果我们还想继续服务，那么强一致性和可用性只能二选一。也就是说，网络分区之后，P是前提，只有P确定了，才能在C和A之间进行选择。也就是说，我们要实现Partitiontolerance。为什么不能同时保证CA？如果系统出现“分区”，说明系统中的某个节点正在执行写操作。为了保证一致性C，需要禁止其他节点的读写操作，与A冲突；如果为了保证A其他节点的读写操作都正常，那么数据的一致性就得不到保证，与CCAP实际应用案例ZooKeeper保证CP。对ZooKeeper的读请求可以随时得到一致的结果，但ZooKeeper不保证每个请求的可用性。比如Leader选举过程中，或者超过半数机器不可用时，服务不可用。Eureka保证它是AP。.Eureka在设计上优先考虑A（availability）。Eureka中没有Leader节点，每个节点都是一样的，平等的。因此，Eureka不会像ZooKeeper那样在选举过程中或者超过半数机器不可用时不可用。Eureka保证即使大部分节点挂掉，也不会影响正常提供服务，只要有一个节点可用即可。只是这个节点上的数据可能不是最新的BASE理论。BASE有BasiclyAvailable（基本可用）、Soft-state（软状态）和EventuallyConsistent（最终一致性）。BASE理论是CAP中一致性（C）和可用性（A）之间权衡的结果。最终一致性是弱一致性的一个特例。系统会保证在一定时间内，达到数据一致的状态。Basicavailability基本可用。意思是当一个分布式系统发生不可预知的故障时，允许其失去部分可用性；那么部分可用性的允许损失是多少？响应时间损失：正常情况下，处理用户请求需要0.5s返回结果，但由于系统故障，处理用户请求的时间变为3s系统功能损失：正常情况下，用户可以使用系统的所有功能，但由于系统访问量的突然增加，系统的一些非核心功能不能使用软状态允许系统中的数据有中间状态（CAP中的数据不一致理论），并且认为这种中间状态的存在不会影响系统整体的可用性，即让系统在不同节点的数据副本之间同步数据的过程有延迟。FinalConsistency最终一致性强调的是系统中的所有数据副本经过一段时间的同步后，最终能够达到一致的状态。所以，最终一致性的本质是系统需要保证最终的数据能够一致，而不需要实时保证系统数据的强一致性。文章中的CAP和BASE理论你看懂了吗？能否结合实际案例谈谈？分布式和集群有什么区别？[1]数据一致性问题[2]
