前言
随着业务的拓展，功能越来越多。把所有的功能都放在同一个服务下，代码混合交错，造成维护困难，也容易造成某一小bug导致整个服务不可用。因此我们会按业务功能会拆分成多个不同的服务（微服务的形成），多个服务组成的系统，有个响亮的名字：分布式系统；而系统中的服务状态我们该怎么去管理，有什么相关的理论呢？
- 分布式和集群
- 数据库事务
- 分布式事务
- 分布式数据一致性
- CAP 理论
- BASE理论
关注公众号，一起交流，微信搜一搜: 潜行前行
分布式和集群
- 分布式是指通过网络连接的多个服务或组件，通过交换信息协作而形成的系统
- 集群是指同一种服务组件的多个实例二形成的整体
- 这两个概念并不完全冲突，分布式系统也可以是一个集群。zookeeper集群也是一种分布式系统，它的服务之间会互相通信协作
- 是集群不是分布式系统的情况，比如多个经过负载均衡的HTTP服务器，它们之间不会互相通信，如果不带上负载均衡的部分的话，则不能称作分布式系统
数据库事务
- 事务是基于数据进行操作，需要保证事务的数据通常存储在数据库中，所以介绍到事务，就不得不介绍数据库事务的 ACID 特性
- 原子性（Atomicity），整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节
- 一致性（Consistency），在事务开始之前和事务结束以后，数据库数据的一致性约束没有被破坏
- 隔离性（Isolation），隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致
- 持久性（Durability），事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失
分布式事务
- 分布式系统一般由多个独立的子系统组成，多个子系统通过网络通信互相协作配合完成各个功能；这个协作过程需要保证各个系统的数据一致性，我们称这种跨系统的事务为分布式事务
- 上面的场景会存在多种情况；库存服务和订单服务全部成功。或者库存服务和订单服务部分成功，而传统的单机事务理论不再适用
分布式事务的难点
- 原子性：事务操作跨不同节点，当多个节点某一节点操作失败时，需要保证多节点操作的要么什么都不做，要么都做
- 一致性：当发生网络传输故障或者节点故障，节点间数据复制通道中断，在进行事务操作时需要保证数据一致性
- 隔离性：在分布式事务控制中，可能会出现提交不同步的现象，会出现“部分已经提交”的事务
分布式数据一致性
- ACID并不适合分布式事务，而分布式事务的难点涉及的问题，最终影响是导致数据出现不一致，因此在分布式系统会着重关注保证系统的一致性。
CAP理论
- 前面介绍到的分布式事务的难点涉及的问题，最终影响是导致数据出现不一致，下面对分布式系统的一致性问题进行理论分析，后面将基于这些理论进行分布式方案的介绍(可用性和一致性的冲突:CAP理论)
- 一致性（Consistence）: 所有节点访问最新相同的数据副本
- 可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）
- 分区容错性（Partition tolerance）: 分布式系统出现网络分区的时候，仍然能够对外提供服务
当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的
为啥无同时保证 CA 呢？
若系统出现“分区”，系统中的某个节点在进行写操作。为了保证一致性C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了；如果为了保证A，其他节点的读写操作正常的话，那就无法保证数据一致性，和C冲突
CAP 实际应用案例
- ZooKeeper保证的是CP。 任何时刻对ZooKeeper的读请求都能得到一致性的结果，但是ZooKeeper不保证每次请求的可用性比如在Leader选举过程中或者半数以上的机器不可用的时候服务就是不可用的
- Eureka保证的则是AP。 Eureka在设计的时候就是优先保证A（可用性）。在 Eureka中不存在什么Leader节点，每个节点都是一样的、平等的。因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的
BASE理论
- BASE是Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性）。BASE理论是对CAP中一致性?和可用性(A)权衡的结果
- 最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态
基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性；那什么又是允许损失部分可用性呢？
- 响应时间上的损失: 正常情况下，处理用户请求需要0.5s返回结果，但是由于系统出现故障，处理用户请求的时间变为3s
- 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用
软状态
- 软状态指允许系统中的数据存在中间状态（CAP理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
最终一致性
- 最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性
欢迎指正文中错误
参考文章
